java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] org.gnome.gdk.EventButton.getX()/getY(): double vs int

[Srichand P. <sri...@gm...>]

On Mon, Oct 6, 2008 at 2:14 PM, Stefan Prelle <st...@pr...> wrote:

> Hi all,
>

Hi Stefan,

I just stumbled upon the not yet exposed methods getX() and getY()
> in org.gnome.gdk.EventButton and Andrew's comment:
>
> * I'm not exposing these yet; why on earth are they double? If there's
> * no good reason or it's legacy crap, we're going to change the return
> * signature to int.
>
> I agree that I don't see a point in not having integers here. So, if
> noone is coming with a good example why to use doubles here, I suggest
> that we expose them as ints.
>
> Any comments?
>
> Stefan
>
>
There certainly are useful applications where doubles rather than ints would
be useful. I've been working on some research on pen strokes on touchscreen
surfaces, such as tablet PCs, external USB tablets (Wacom style stuff) and
handheld devices. For a lot of the algorithms, subpixel accuracy is
certainly useful. By constraining values to ints, you're losing (possibly)
valuable bits of information. Instead of deciding which pixel to select (by
truncating the numbers after the decimal), sometimes its useful to let the
application/algorithm decide what it wants to do.

Just my 2c.

Srichand
-- 
Srichand Pendyala
http://srichand.net.in/

Re: [java-gnome-hackers] org.gnome.gdk.EventButton.getX()/getY(): double vs int

[Owen T. <ot...@re...>]

On Mon, 2008-10-06 at 20:14 +0200, Stefan Prelle wrote:
> Hi all,
> 
> I just stumbled upon the not yet exposed methods getX() and getY()
> in org.gnome.gdk.EventButton and Andrew's comment:
> 
> * I'm not exposing these yet; why on earth are they double? If there's
> * no good reason or it's legacy crap, we're going to change the return
> * signature to int.
> 
> I agree that I don't see a point in not having integers here. So, if
> noone is coming with a good example why to use doubles here, I suggest
> that we expose them as ints.
> 
> Any comments?

They are double because in some cases sub-pixel positioning is
available... for example, when tablet support is enabled. This is
important for, among things, painting programs.

Any questions?

- Owen

Re: [java-gnome-hackers] org.gnome.gdk.EventButton.getX()/getY(): double vs int

[Andrew C. <an...@op...>]

On Mon, 2008-10-06 at 20:14 +0200, Stefan Prelle wrote:
> I just stumbled upon the not yet exposed methods getX() and getY()
...
> I agree that I don't see a point in not having integers here.

Great.

As it happens, I actually ran into needing these a few weeks ago and so
went ahead and did this. See revision
an...@op...-20080924020725-15qyh3lc7y8rwavh which was
merged to 'mainline' at revno 565.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] org.gnome.gdk.EventButton.getX()/getY(): double vs int

[Stefan P. <st...@pr...>]

Hi,

Am Montag, den 06.10.2008, 15:33 -0400 schrieb Gerald Butler:
> Is it possible to have fractional mouse locations reported under
> various coordinate transformation matrixes? Perhaps when things like
> "Multi-Touch" become wide-spread? What does the underlying GTK API
> have to say about this?

Nearly nothing.

gdouble x; the x coordinate of the pointer relative to the window.

is all I can find in the API docs for that type. 

Regarding transformation: The only way that I can imagine coordinate
transformation leading to non-integer values is for example when a kind
of magnifying glass follows the mouse cursor so that the screen pixels
may not match application pixels. (Just a quick thought - might prove
false when you think closer about it.) But even dropping the fractional
part or rounding it seems ok.

Plus: We avoid confusion for application developers.

Cheers,
  Stefan

[java-gnome-hackers] org.gnome.gdk.EventButton.getX()/getY(): double vs int

[Stefan P. <st...@pr...>]

Hi all,

I just stumbled upon the not yet exposed methods getX() and getY()
in org.gnome.gdk.EventButton and Andrew's comment:

* I'm not exposing these yet; why on earth are they double? If there's
* no good reason or it's legacy crap, we're going to change the return
* signature to int.

I agree that I don't see a point in not having integers here. So, if
noone is coming with a good example why to use doubles here, I suggest
that we expose them as ints.

Any comments?

Stefan

Re: [java-gnome-hackers] Layout size related methods

[Andrew C. <an...@op...>]

On Tue, 2008-09-16 at 11:46 -0400, Owen Taylor wrote:

> Without looking at your code, it's hard for me to say where you are
> getting confused. Some points that may be helpful.

I replied quickly to Owen thanking him for his input. Furthermore this
background info was fantastic and really helpful.

Before delving into the specifics, I just wanted to quickly write the
part that was implicit in the work that Vreixo and I have been doing,
but perhaps missing from this thread.

The path we've been following is the following:

      * Drawing is done with Cairo (and indeed the only drawing API
        we're interested in).
      * While there is a "toy" font API in Cairo, real text rendering in
        GNOME is done with Pango, of course (and so, again that's what
        we have chosen to expose for when you need to write text when
        doing manual drawing).

From there, someone made the observation that when you're busy drawing
away with Cairo in an Widget.ExposeEvent handler, it seemed *really*
awkward to have to keep switching from the doubles that you're working
in with Cairo the the huge fixed point ints that you have to feed Pango
functions.

So, it wasn't a huge leap for suggest that we normalize the Pango
methods to be in the same units as the rest of one's Cairo drawing. I
liked that idea very much, and it certainly made the test code I was
trying all this out with look *WAY* nicer. So, {shrug} away we went.

Owen wrote,
> How does this map to Java? It's partly a question about how much you are
> deviating from the Pango API. If you want to stick close...

So, really, it wasn't about sticking to the underlying API (which we
otherwise do rather rigorously modulo the stylistic things we have
adopted to make completion spaces better, type safety, etc) as it was
trying to make the overall drawing experience a bit more coherent. 

I think I'll stop there; if people want to bitch they can, but that's
the direction we were heading. It seemed to make good sense. Meanwhile
I'm going to re-read what Owen wrote and see how that information
illuminates what we were doing.

People who are actually using java-gnome (and especially doing any
drawing) are welcome to chime in.

AfC
Sydney

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Stefan P. <st...@pr...>]

Hi Andrew,

Am Dienstag, den 16.09.2008, 10:51 +1000 schrieb Andrew Cowie:
> It would really help if you wrote a tinsy Example or Snapshot which
> demonstrates the problem and added it to the branch and sent it along to
> us... then we could see what you're trying to do.

Patch against "hackers/andrew/treeview/"

It is an attempt to store TreeModels in cells. I am aware that I have
not taken care of selecting the column of the enclosed TreeModel to
display, but currently my problem is at an earlier stage. :(

Regards,
  Stefan

Re: [java-gnome-hackers] Layout size related methods

[Owen T. <ot...@re...>]

On Wed, 2008-09-17 at 00:15 +1000, Andrew Cowie wrote:
> Vreixo,
> 
> I've been working on the 'pango' branch. I'd like to include it in 4.0.9
> as it nicely complements the 'textview' work.
> 
> I'm a bit concerned about the size related methods in Layout. I've taken
> an number of different cracks at it, and now I've got it to:
> 
>         getSizeWidth()
>         getSizeHeight()
> 
> and
> 
>         getPixelWidth()
>         getPixelHeight()
> 
> which seems to be a fairly decent stab at regularizing the completion
> space. Still, I'm not 100% about it.
> 
> Part of my doubt is that now that we've got these normalized, these
> methods now seem to return the same thing - just the sort of thing to
> make me somewhat unconvinced that we actually need both pairs. That
> said, it is probably best we leave both sets there - there is return
> type to be considered.
>
> The real issue, of course, is *explaining* what the difference is, and
> that's where I got a bit vague. I have a hunch that it is the whole
> points vs device units vs pixels thing that I'm getting confused by.

Without looking at your code, it's hard for me to say where you are
getting confused. Some points that may be helpful.

 * All functions to get size and metrics in Pango work in the same 
   coordinate space. This coordinate space is  equivalent to the cairo
   user space. If you haven't made any transformations, then this
   coordinate space has units of pixels.

 * Lengths are usually in fixed point 22.10 format. (Called "pango
   units.) In C, you interconvert

    pixel_length = PANGO_PIXELS(length) // also PANGO_PIXELS_FLOOR/CEIL
    length = pixel_length * PANGO_SCALE

 * It's a frequent operation to want extents *in integer pixels*;
   doing the rounding properly round a fixed point rectangle to the
   small enclosing integer pixels is slightly tricky, and something
   you commonly want todo so there are functions like
   pango_extents_to_pixels() pango_layout_get_pixel_extents()
   pango_layout_get_pixel_size()

   E.g., if you have a rectangle with x = 0.9 width = 5.2, the pixel
   width is not 5 (rounded) or 6 (ceiling), it's 7.

How does this map to Java? It's partly a question about how much you are
deviating from the Pango API. If you want to stick close, all you need
is break get_extents() into:

  Rectangle getInkRectangle()
  Rectangle getLogicalRectangle()

And on Rectangle have:

  Rectangle toPixels()
  int getX()/getY()/getWidth()/getHeight()

That's complete in terms of mapping all of 
pango_layout_get_[size/pixel_size/extents/pixel_extents]. Beyond that, 
you might want to add for layout:

 getPixelWidth()/getPixelHeight()

As convenience functions. I'm not sure that getSizeWidth()/getSizeHeight() 
are necessary. Ugly names...

- Owen

[java-gnome-hackers] Layout size related methods

[Andrew C. <an...@op...>]

Vreixo,

I've been working on the 'pango' branch. I'd like to include it in 4.0.9
as it nicely complements the 'textview' work.

I'm a bit concerned about the size related methods in Layout. I've taken
an number of different cracks at it, and now I've got it to:

        getSizeWidth()
        getSizeHeight()

and

        getPixelWidth()
        getPixelHeight()

which seems to be a fairly decent stab at regularizing the completion
space. Still, I'm not 100% about it.

Part of my doubt is that now that we've got these normalized, these
methods now seem to return the same thing - just the sort of thing to
make me somewhat unconvinced that we actually need both pairs. That
said, it is probably best we leave both sets there - there is return
type to be considered.

The real issue, of course, is *explaining* what the difference is, and
that's where I got a bit vague. I have a hunch that it is the whole
points vs device units vs pixels thing that I'm getting confused by.

And, of course, just to spice things up, none of these have anything to
do with Layout's setWidth() but its probably best to leave that one
alone too [I am tempted by setWrapWidth()]. For now I added some extra
emphasis to its documentation in an attempt to make things clear.

My work (building on yours) is at 'hackers/andrew/pango'.

AfC
Sydney

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Andrew C. <an...@op...>]

On Sun, 2008-09-14 at 00:36 +0200, Stefan Prelle wrote:
> org.gnome.glib.FatalError: Gtk-CRITICAL
> gtk_cell_renderer_combo_set_property: assertion `GTK_IS_TREE_MODEL
> (object)' failed

So one quick thought (I'm not sure if this helps) is that GtkTreeModel
is [natively in GLib terms] an interface, not an object.

Ordinarily a bunch of crazy casting takes care of this, but in the case
of working with GValues and GTypes, I'm not sure.

> So that means there is currently no simple workaround to get the
> CellRendererCombo working?

I don't think the problem is insurmountable. Worst case scenario we just
do an override code path for this (though if we keep doing that sort of
thing will aggregate cruft, which is why I discussed a possible code
generator solution in the previous email).

Ping me on IRC and we can talk more about it.

It would really help if you wrote a tinsy Example or Snapshot which
demonstrates the problem and added it to the branch and sent it along to
us... then we could see what you're trying to do.

AfC
Sydney

[java-gnome-hackers] Embedding the library path

[Andrew C. <an...@op...>]

        [We do 'way too much on IRC, and I realized this list is looking
        a little dead. That's a shame. We'll try and correct that]

One of the constant pain points of using java-gnome is having to specify
-Djava.library.path=whatever to the VM every time you attempt to run
something.

While the problem goes away if using a copy of java-gnome installed to
the system prefix (ie, /usr) via a distro package, there is the
attendant problem that if you have java-gnome installed and meanwhile
try to run something in a checkout and forget the to do
-Djava.library.path=tmp or whatever you'll end up picking up the wrong
native code [we now catch that problem, but still]. And worst of all,
even if installed, if you're on Gentoo the gentoo-java team installs its
native components to a non standard location
(/usr/share/java-gnome-4.0/lib in our case) meaning that you've still
got to define java.library.path. What a pain in the ass.

I was talking about this with Kenneth Prugh the other day, and we
realized that in a Linux environment the target libdir location is a
*known* commodity. We know, as of configure time, exactly where to find
the library. So why not just look there?

I spent a while trying to fudge this location into java.library.path at
runtime, but that's not possible - in the Open Java implementation
anyway, the value of java.library.path is cached really early on, before
user code can get to it. So changing that property doesn't have any
effect.

But it turns out there is an alternate way to load native libraries from
Java code, and that's System.load(). Unlike System.loadLibrary() [which
searches (only) java.library.path for the .so you're attempting to load]
you specify the exact absolute path of the file you want to load. Well,
shit, we have that. So, yeay!

I've done essentially this on a branch. See
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/native-library-loading/ 

Having it load the library as it will be installed was easy. The tricky
part was arranging things so that if you're using java-gnome in-place as
built (but not yet installed) that it would still work. This is very
important for people who are simultaneously hacking an app and hacking
on java-gnome at the same time. That fall back case involves some fairly
voodoo code (you have to find out the URL of the code (ie gtk-4.0.jar)
came from. Not easy).

I'm happy we've covered off all the corner cases, but testing by you
would be appreciated before I merge it to 'mainline'.

This is actually a pretty momentous improvement, and assuming it holds
up, I'd like to do a release with it ASAP.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Submission for mainline

[Andrew C. <an...@op...>]

On Sat, 2008-09-13 at 20:36 +0200, Stefan Prelle wrote:

> it has been some time since I wrote. Due to the fact that I started
> building a house I am a bit distracted nowadays.
> 
> Anyway I recently had some time to get up to date with my additions to
> java-gnome which should be all assembled in the attached patch.

Merged to 'mainline'. Thanks!

++

> I stumbled over GtkTreePath.getIndices(..) returning a null

I did some testing and ran into the same thing. I updated the comment
there.


> // translate return value to JNI type
> _result = (jintArray) NULL;

I seem to remember us talking about this a few months ago. Maybe Vreixo
can have a look.

> I remember that I already had a similiar problem, but I don't recall
> which class and function it was. Since I am not familiar with the code
> generator to fix this

We'll have to change that one of these days :) but no problem.

> , I provided some java replacement for this method.

Good initiative. Ordinarily I'd frown on that sort of thing (I generally
prefer fixing the real problem) but I also believe in rewarding people
for putting hard work in. So well done, and we'll see about reverting
the workaround when we fix the bug.
 
AfC
Sydney

[java-gnome-hackers] Errant Window being realized in test suite

[Andrew C. <an...@op...>]

There's an errant test fixture which is briefly creating a Window and
then hiding it. Our test suite isn't headless (it will requires the
user's DISPLAY be valid until we hack some Xvfb love in there) but it
shouldn't be popping Windows onto the screen. Ick.

I raised a bug at http://bugzilla.gnome.org/show_bug.cgi?id=552338 so we
don't forget, but if anyone else notices this as they run `make test`,
please let me know. Better yet, figure out what's up :)

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] GtkCellRendererCombo - help appreciated

[Stefan P. <st...@pr...>]

Hi all,

I was revisiting my attempts to implement a CellRendererCombo.
This time I was trying to implement a "DataColumnTreeModel" to give the
CellRendererCombo a column to pick its model from.

public final class DataColumnTreeModel extends DataColumn {
    public DataColumnTreeModel() {
        super(TreeModel.class);
    }
}

I ran into the problem that there is no mapping from TreeModel to a
GType:

org.freedesktop.bindings.FatalError: Don't know how to map
org.gnome.gtk.TreeModel into a GType

So I tried modifying src/jni/bindings_java_type.[c|h] to add some
mappings:

	} else if (g_str_equal(fqcn, "org.gnome.gtk.TreeStore")) {
		return GTK_TYPE_TREE_STORE;
	} else if (g_str_equal(fqcn, "org.gnome.gtk.ListStore")) {
		return GTK_TYPE_LIST_STORE;
	} else if (g_str_equal(fqcn, "org.gnome.gtk.TreeModel")) {
		return GTK_TYPE_TREE_MODEL;

While this got me a bit further, I now seem to have problems with an
assertion in the native GTK code:

org.gnome.glib.FatalError: Gtk-CRITICAL
gtk_cell_renderer_combo_set_property: assertion `GTK_IS_TREE_MODEL
(object)' failed

which propably leads to the line in gtk/gtktreemodel.h
#define GTK_IS_TREE_MODEL(obj)  (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
GTK_TYPE_TREE_MODEL))

So from my understanding GTK has problems identifying e.g. a
org.gnome.gtk.ListStore (which is an implementation of the abstract
org.gnome.gtk.TreeModel) as of being of a native GtkTreeModel.
Correct?

Am Mittwoch, den 14.05.2008, 15:22 +1000 schrieb Andrew Cowie:
> It _might_ be the same class of problem that we recently ran into with
> GValues holding enums: for some reason GValue gets grumpy when asked to
> hold abstract types. See 'textview' revno 508.

Possibly. Honestly I feel a bit overwhelmed by the whole Plumbing,
GValue, GType and generally deep and dirty mapping stuff.

> [..]
> What a pain. I hate GValues.
> 
> In fact, I'd be happy if they went away entirely. That would mean making
> GObject.setProperty(), GtkTreeView.setValue()  and anything else that
> uses GValue have a native overload for every type combination [in a
> hand written Override]. That *is* doable, but at present we have all
> those code paths concentrated through the Value code paths.
> 
> Well, whatever. Something for the future.

So that means there is currently no simple workaround to get the
CellRendererCombo working?

Regards,
 Stefan

Re: [java-gnome-hackers] java-gnome memory management issues

[Vreixo F. L. <met...@ya...>]

Hi!

> Wrong implementation CairoContext getSource() does not
> break now, but it can cause a memory leak if it is called
> more than once. The problem is hard to fix without an
> override. I'll take a look at it today.
> 

Is there any good reason to have Cairo Entity extend Proxy instead of Pointer? It seems not needed at all, and the problem is automatically fixed without that.

Cheers
Vreixo


      Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses

Re: [java-gnome-hackers] java-gnome memory management issues

[Vreixo F. L. <met...@ya...>]

Hi!

I've pushed to my memmanag branch 

http://research.operationaldynamics.com/bzr/java-gnome/hackers/vreixo/memmanag/

several changes related to this thread:

- I've created a Pointer class. The C ptr is stored as a long there. It defines an abstract release() and its finalize() takes care of calling release().

- Proxy now extends Pointer, and only holds the responsibility of maintaining the proxy map.

- Boxed implements release() by taking care about owner flag. It defines an abstract free() function that each subtype implements, and where they should call underlying C free/unref function.

- Value now extends Pointer instead of Proxy, there is no need to keep them stored in the map. I think we can do the same with Boxed, storing Boxeds in a map makes no sense, as denaturation will happen with boxeds anyway, because they have no ref. count system and the proxy is always garbage collected when it goes out of scope on java. Moreover, all boxeds should be final, so we have no denaturation problem at all (btw, why TreeIter is not final? it seems a bug).

This branch fixes memory leaks on Cairo code, and improves memory usage with Values. It seems to work ok, all test cases pass. Conceptually it is more correct than current code. 

Wrong implementation CairoContext getSource() does not break now, but it can cause a memory leak if it is called more than once. The problem is hard to fix without an override. I'll take a look at it today.

On the other side, I can't find any leak on GValue or gtk_list_store_set_value() as IRC subject suggest. Its usage seems correct, and it is correct on my system.

Cheers
Vreixo



      Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses

Re: [java-gnome-hackers] java-gnome memory management issues

[Andrew C. <an...@op...>]

On Tue, 2008-08-26 at 21:18 +1000, Vreixo Formoso wrote:
> However, when the Entity is garbage collected, the release() method is
> never called.

So, immediately, the problem is that someone (ahem) forgot to put a
finalize() placeholder in Entity. That's easily fixed.

> ...
> Obviously, if release() is defined in Proxy, a better design would be
> having this piece of code there.

> I think, however, that the code
> 
> 	if (owner) {
>             release();
>             owner = false;
>         }
>         super.finalize();

THAT can go into Proxy's finalize() placeholder [or rather, Pointer's].
Let's leave the actual release() method abstract there.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] java-gnome memory management issues

[Vreixo F. <met...@ya...>]

Hi Andrew!

I've started just now to review the Value issue, and that lead me to
find another memory management problem.

Entity subclasses (Context, Pattern, Surface) implement abstract
Proxy.release() method, and they free there underlying C resources.
However, when the Entity is garbage collected, the release() method is
never called. 

The problem is the wrong design of that part. Proxy defines and abstract
release() method, but its finalize() is not responsible for calling it.
Instead, Proxy subclasses override the finalize() method with something
like this:


    protected void finalize() {
        release();
        super.finalize();
    }

Obviously, if release() is defined in Proxy, a better design would be
having this piece of code there.

However, Boxeds are a problem, as they're release only if owner == true.
I think, however, that the code

	if (owner) {
            release();
            owner = false;
        }
        super.finalize();

present in Boxed.finalize() should be really present in Boxed.release(),
and define an abstract method in Boxed (free(), for example) that each
Boxed subclass should implement.

On the other side, I will also create a Proxy superclass (Pointer,
maybe?) where the release() function will be defined, leaving on Proxy
only the responsibility of handling the Proxy map.

Values, for example, will inherit from Pointer instead of Proxy. I think
that Boxeds may also inherit from Pointer instead of Proxy, but I need
to think a bit more about it... we will see.

Cheers
Vreixo

Re: [java-gnome-hackers] Preliminary Slackware support

[Andrew C. <an...@op...>]

On Sat, 2008-08-23 at 23:32 -0500, Scott J. Harmon wrote:
> Here is a patch that adds Slackware support to configure.

Merged to 'mainline'

AfC
Sydney

Re: [java-gnome-hackers] Slackware JUnit Test patch

[Andrew C. <an...@op...>]

On Sat, 2008-08-23 at 23:54 -0500, Scott J. Harmon wrote:
> This makes the JUnit tests work properly on Slackware.

Yes, this is better. Will merge. Thanks.

AfC
Sydney

[java-gnome-hackers] java-gnome 4.0.8 released

[Andrew C. <an...@op...>]

I am pleased to announce the latest release of the java-gnome user interface
library.

Tarballs of 4.0.8 can be downloaded from:
http://ftp.gnome.org/pub/GNOME/sources/java-gnome/4.0/ 

Release notes are, as usual, in the NEWS file:
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.8

AfC
Sydney

--
Maintainer,
java-gnome
The ideal user interface library for Java!

Partner,
Operational Dynamics
IT operations, open source engineering, and crisis management

[java-gnome-hackers] java-gnome 4.0.8 imminent

[Andrew C. <an...@op...>]

java-gnome 4.0.8-rc2 is up (it's current 'mainline', duh). If anyone has
any show-stopping release critical complaints, now is the time.

On Wed, 2008-08-13 at 15:00 +0000, Vreixo Formoso Lopes wrote:
> Then we both agree, great! Next week I will have time to update my
> Pango work with this idea. Can you delay 4.0.8 a pair of weeks? Or do
> you prefer a release now?

No, it is not appropriate to be integrating (and having to test) such a
major piece of new functionality 2 days before a release.

The branch is already a good start (you did pull my work on top of it,
right?) and it'll be nice to have this added to our library.

But adding new API at this scale is something we need to review
carefully as we have to live with public signatures for a long time once
they make it into a release.

AfC
Sydney

[java-gnome-hackers] Reviewing "patch for RGBA windows and misc. Cairo functionality"

[Andrew C. <an...@op...>]

On Tue, 2008-08-12 at 17:09 +1000, Zak Fenton wrote:
> [patch]

Welcome Zak!

> @authors

Unfortunately Ken misguided you slightly; @author tags are welcome, but
they don't fit into the "schema" (sic) of JavaDoc; they're not valid on
methods, only classes.

As

        $ make doc

would have told you this, I have a fairly strong indication that you
didn't run it. Ahem. Doing so would help you fix another doc bug you
introduced as well. Please preview your API documentation work before
submitting contributions which expose new public API.

Also, we tend to use @link tags in proper sentences in preference to
@see tags. It's more conversational, and there's rarely a need to
distract someone with the full signature of a method when linking to it.
Most importantly, though is the fact that you can then write:

        "see also Thermostat's {@link Thermostat#setTemperature(int)
        setTemperature()} because that method will really warm things
        up, as opposed to this one which only makes you <i>think</i> it
        is warmer."

as opposed to:

        @see Thermostat.setTemperature(int)

which really doesn't help a developer very much.

> === AUTHORS

[Just FYI, traditionally in Open Source projects it is the maintainer(s)
who arbitrate people being added to the AUTHORS file. As it happens I
have been pretty generous about this, and your contribution is (assuming
it is polished up to the point of being accepted, which I'm sure you're
going to do) almost certainly would have moved me to add you there. But
beware that in a different Open Source community you could potentially
annoy people who might perceive it as presumptuous. Just a tinsy
etiquette point, but some people get rabid about this sort of thing]

> [Formatting]

It would probably be a good idea if you ran:

        $ make format

before committing - or at least before submitting a bundle - assuming
you are not working in Eclipse.

I blogged about this the other day, see
http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/eclipse-code-format-from-command-line.html ]
and if you *are* hacking in Eclipse, then run the formatter already! :)


> // Thread that updates count 20 times per second and redraws the window

Comments that describe the next step of an algorithm or procedures
should be multi line, ie

/*
 * Thread that updates count 20 times per second and
 * redraws the window.
 */

It encourages us to be a bit more verbose and not to fight to be so
terse as to fit onto a single line at the cost of not actually
explaining what we're up to. Especially in our Examples, full
explanations are to be sought after.

(ie, All the descriptive comments in your ExposeEvent handler should be
multi-line, thanks)

Comments that are there to *quickly* explain something weird or
not-obvious about the vagaries of a particular call or usage then yes,
an // immediately before that call is appropriate.


> final Thread anim = ...

I'd prefer it if you would pre-declare variables.


> +       // Animation frame counter
> +       static long count; 

If it's important enough to explain what a field is, then it should be
JavaDoc. [in this case I'm not really sure that it is, but that's up to
you. Examples have the burden that most people are going to read them
top to bottom. That, of course, is not the best way to study real Java
code, but examples that are online kinda have to be pushed into a
slightly different mold.


> +                               System.exit(0);

You should not call System.exit() after Gtk.mainQuit(). Let the signal
handler return.

[call it after Gtk.main() if you really need to, which, generally, you
don't]


> /**
>       * Get the default Colormap associated with this Screen.
>       */
> -    Colormap getDefaultColormap() {
> +    public Colormap getDefaultColormap() {
>          return GdkScreen.getDefaultColormap(this);
>      }
> +    
> +    /**
> +     * Get the RGBA Colormap associated with this Screen. This is useful for
> +     * per-pixel translucency in top level windows.
> +     *

So now we're getting on to the heart of your patch.

It's not clear to me what the difference between the "default" colormap
and the "rgba" one is. Why would you call one, or the other?

        [incidentally, does the answer to this question (whatever it is)
        explain why ExampleDrawingOffscreen never worked right?]

What *is* Colormap, anyway?

These are the kinds of thing that needs explaining - the fact that I
wasn't able to answer such questions on my own is why that particular
method isn't yet public. 

Actually, the overarching question is always "do we actually need to
expose this?", and I ask it here. In this case, I can't help but wonder
(despite your otherwise excellent writing for Widget's setColormap()]
whether this isn't in the category of "[should] Just Work"

        [that's partly a GTK/GDK/Cairo question, and partly a
        if-there's-
        -really-only-one-way-this-should-be-used-then-really-it-doesn't-
        need-exposing-in-java-gnome type question.

        Quite frequently there have been things that "really, there are
        just one of" at which point we can honestly consider whether we
        need a setter / whether we need that parameter to a signature /
        etc. [An similar example would be the numerous places where we
        have used Java method overloads rather than arbitrarily
        different method names - necessary in C name space but not
        necessary in Java name space where overloads are possible]

        ... but when the "default" of something is the *only* of
        something, and the only reason you need to get the something is
        to immediately pass it to the next method call that you always
        call next... well, you can see that at that point there is room
        to put our on our thinking caps. There has been a fair bit of
        this going on in the 'textview' branch, incidentally]


> +     * @since 4.0.8

As it happens we're *right* on the boundary of closing 4.0.8, but if we
can clean this patch up quickly then I think we can get it in. But yes,
I do encourage people to put @since tags in with the assumption that
their work is going to be in the next release, so these are great,
thanks.

> +    public Colormap getRgbaColormap() {

Hmm. Looking around at other places where "r g b [a]" and other such
acronyms have shown up, we have gone with all caps [Context's
setSourceRGBA() and FileChooser's getURI() come immediately to mind].

So the right signature (assuming we expose this property) for the
accessor and mutator would seem to be:

        getRGBAColormap()

*BUT* the one place where we dramatically fiddle underlying signatures
is when we can improve Java completion space. So it may well be that:

        getColormapRGBA() and
        getColormapDefault()

will be best - assuming (referring to the previous discussion) we
actually need both.

> [Cairo methods]

Srichand, you were doing some work close to here. Can you comment on
these methods and/or their descriptions?


> public static final Operator DEFAULT = OVER;

Hm.

So is such an alias the right thing, or should we just help teach people
that OVER is the default mode?


++

> I'll probably be experimenting with some SVG stuff in the coming
> weeks, so I'll probably fill in more gaps in the Cairo bindings as I
> go.

Super.

AfC
Sydney

Re: [java-gnome-hackers] Major API change in signal interface naming

[Kenneth P. <ken...@gm...>]

On Wed, 30 Jul 2008 11:08:48 +1000
Andrew Cowie <an...@op...> wrote:
> <snip>

Just converted my small project to the new style and I have to say I'm
really liking it.

+1 from me.

Re: [java-gnome-hackers] Major API change in signal interface naming

[Srichand P. <sri...@gm...>]

<snip>

I tried out the new signature in a couple of little apps and I think I
quite like it. Its got closer semblance to GTK+ than before and that
seems to make me comfortable I guess.

Gets a +1 from me.

Srichand
-- 
Srichand Pendyala <sri...@gm...>