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

[java-gnome-hackers] java-gnome 4.0.18 released

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

The 'mainline' branch now identifies itself as 4.0.19-dev.

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] Release imminent

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

On Wed, 2010-12-22 at 12:25 +0100, Guillaume Mazoyer wrote:
> > People should have a look at the RSVG stuff.
> Here is a patch to fix the RSVG dependency check on configure.

Merged to 'mainline', thanks.

AfC
Sydney

Re: [java-gnome-hackers] Release imminent

[Guillaume M. <res...@gm...>]

> People should have a look at the RSVG stuff.
Here is a patch to fix the RSVG dependency check on configure.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] Release imminent

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

That bugs was extraordinarily serious, so as I mentioned to a few people
on IRC we'll be doing a release with the fix immediately. If there's
anything you want in, please speak up ASAP. And of course, if you could
make sure your code is still sane...

People should have a look at the RSVG stuff.

I've cut 4.0.18-rc1 in case you need a tarball to test with.

AfC
Sydney

-- 
Andrew Frederick Cowie
#java-gnome on irc.gimp.net

Re: [java-gnome-hackers] Duplicating assertion `GDK_IS_WINDOW (window)' failed crash

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

On Tue, 2010-12-21 at 19:14 +1100, Andrew Cowie wrote:
> On Tue, 2010-12-21 at 01:02 +1100, Andrew Cowie wrote:
> > On Tue, 2010-12-21 at 00:05 +1100, Andrew Cowie wrote:
> > > I still don't have any insight into what's going on with
> > 
> > Ok, I've made some progress.
> 
> Problem located 

Fix merged to 'mainline' revno 776:

  Fix coding mistake leading to crashes from:
  
  Gdk-CRITICAL "assertion `GDK_IS_WINDOW (window)' failed
  
  The leading indicator of trouble was:
  
  Gdk-WARNING "losing last reference to undestroyed window"
  
  but we were not seeing that since it was arising during the Java VM's
  Finalizer thread, and the VM is specified to swollow and discard
  Exceptions which occur in finalizers. Damn.
  
  Traced the problem through to Widget's getWindow(). We had written an
  Override to implement this method since at the time there was not
  accesor function. Our manually written code was eronously not calling
  bindings_java_memory_cleanup() [which is a terrible name] which has
  the effect of taking a Ref so that bindings_java_memory_ref() can
  discard it after creating the ToggleRef.
  
  Though we could have corrected the manually written code, a strong
  gtk_widget_get_window() now exists, so replace the override with data
  in GtkWidget.defs and call generated code instead.

++

We really need to do something about this Exceptions being swollowed in
Finalizers thing.

And, bindings_java_memory_cleanup() needs to GO AWAY. Pissing me off. I
haven't been down in these layers of java-gnome for > 3 years. Now that
we know what we're doing a little better I'm thinking of merging that
function and bindings_java_memory_ref(). But that can wait.

AfC
Sydney

Re: [java-gnome-hackers] Duplicating assertion `GDK_IS_WINDOW (window)' failed crash

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

On Tue, 2010-12-21 at 01:02 +1100, Andrew Cowie wrote:
> On Tue, 2010-12-21 at 00:05 +1100, Andrew Cowie wrote:
> > I still don't have any insight into what's going on with
> 
> Ok, I've made some progress.

Problem located (I think):

Our implementation for Widget's getWindow() did not take a Ref.

++

Turn on debugging:
Debug.MEMORY_MANAGEMENT = true
and
#define DEBUG_MEMORY_MANAGEMENT TRUE

Our GObject memory management code assumes (and requires) that when we
go to make a ToggleRef, we have one (and only one) normal Ref that we
own. The addToggleRef() code drops that normal Ref.

Meanwhile, our override for getWindow() just returned a the address.
Comparing to generated code, I realized our Override doesn't have a call
to bindings_java_memory_cleanup() [which I must admit never much liked
the name of].

Adding a g_object_ref() there appears to fix the problem.

Replacing the Override with some .defs to get normal generated code for
gtk_widget_get_window() [now that it exists; it didn't a few years ago]
also appears to work [since it generates the call to
bindings_java_memory_cleanup()]

++

Hm.

So while that will be a "fix", I'd like to rethink some of the code in
src/jni/bindings_java_memory.c. If we can consolidate
bindings_java_memory_cleanup() into bindings_java_memory_ref() I think
we'll be on the right track.

What worries me is that this is a general class of bug that we could be
exposed to all over the place whenever we've done an override. So the
problem needs to be engineered out.

If anyone working on this could confirm that the GdkWindows are still
getting finalized without crashing that'd be outstanding. The trick is
*is the GObject still being finalized*? It's easy to "add a
g_object_ref()" call anywhere, but if that means the Ref count never
drops to zero then you'll never get objects free()d and that wouldn't do
us any good, would it? :)

AfC
Sydney

Re: [java-gnome-hackers] Duplicating assertion `GDK_IS_WINDOW (window)' failed crash

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

On Tue, 2010-12-21 at 00:05 +1100, Andrew Cowie wrote:
> I still don't have any insight into what's going on with

Ok, I've made some progress. Attached to that bug is a short test
program which demonstrates the problem.

The insight from speeing up the GC was that it was pressing Ins that
triggered it. Weird; what's a popup menu got to do with disappearing
TextViews?

And then I realized that there aren't many places in my program, Quill,
which actually create Proxy objects for GdkWindows. the call which does
that is Widget's getWindow() and the context menu code in Quill is the
only place that happens.

This afternoon I spent a couple hours trying to write a multithreaded
program which would demonstrate the crash, but unsuccessfully. Tonight,
with Guillaume's help, I narrowed it down to a simple program.

The catch is you need something which creates org.gnome.gdk.Window proxy
for something other than the top level Window; many GtkWidgets actually
draw on that top level GtkWindow's GdkWindow [the whole
'client-side-windows' branch that was merged to GTK about 2.18].

So, if you create a [org.gnome.gdk] Window that can be finalized
seperately from the top level, the program will crash.

See https://bugzilla.gnome.org/show_bug.cgi?id=637132#c6 or
http://paste.pocoo.org/show/307378/

So. The question is: what the hell is wrong with our GdkWindow proxies?

AfC

P.S. Interesting different WARNINGs if you do this:

        assert (underlying != parent.getWindow());

[java-gnome-hackers] Duplicating assertion `GDK_IS_WINDOW (window)' failed crash

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

I still don't have any insight into what's going on with
https://bugzilla.gnome.org/show_bug.cgi?id=637132#c2 but I have come up
with three useful diagnostics:

1) manually print a message when an object gets finalized

We have a fair bit of printf infrastructure for debugging memory
management; in this case I think all you really need is a message when a
GObject Proxy is getting finalized:

=== modified file 'src/bindings/org/gnome/glib/Object.java'
--- src/bindings/org/gnome/glib/Object.java	2010-01-06 05:24:40 +0000
+++ src/bindings/org/gnome/glib/Object.java	2010-12-20 10:59:56 +0000
@@ -111,7 +111,7 @@
      * continue to exist quite happily.</i>
      */
     protected final void release() {
-        if (Debug.MEMORY_MANAGEMENT) {
+        if (true) {
             System.err.println("Object.release()\t\t" + this.toString());
             System.err.flush();
         }


2) ensure WARNINGs in finalizer thread aren't missed out on

Since exceptions thrown in finalizers are suppressed, we're missing out
on the errors occurring during from GC. It is almost tempting to call
ExceptionDescribe() here, although if we did that you'd see two stack
traces for any normal (heh) CRITICAL.

=== modified file 'src/jni/bindings_java_util.c'
--- src/jni/bindings_java_util.c	2010-01-06 07:07:08 +0000
+++ src/jni/bindings_java_util.c	2010-12-20 11:25:56 +0000
@@ -396,6 +396,9 @@
 	
 	msg = g_strdup_printf("%s-%s\n%s", log_domain, level, message);
 
+	g_printerr("DANGER %s\n", msg);
+	fflush(stderr);
+
 	bindings_java_throwByName(env, "org/gnome/glib/FatalError", msg);
 
 	g_free(msg);

3) do crazy amounts of GC

I wrote up a thread to do nothing but invoke the garbage collector ... frequently. :)

=== modified file 'src/quill/ui/UserInterface.java'
--- src/quill/ui/UserInterface.java	2010-11-05 13:05:45 +0000
+++ src/quill/ui/UserInterface.java	2010-12-20 12:59:19 +0000
@@ -68,7 +68,25 @@
     }
 
     private void setupWindows() {
+        final Thread t;
+
         primaries = new HashSet<PrimaryWindow>(3);
+
+        t = new Thread() {
+            public void run() {
+                while (true) {
+                    try {
+                        Thread.sleep(1000);
+                    } catch (InterruptedException e) {
+                        // TODO Auto-generated catch block
+                        e.printStackTrace();
+                    }
+                    System.gc();
+                }
+            };
+        };
+        t.setDaemon(true);
+        t.start();
     }
 

hahah...

Anyway, the result is that instead of it taking a whole lot of
operations and 10s of minutes of typing, with Quill I can trigger the
crash *immediately*.

Just press Ins and try and insert a segment.

AfC
Sydney

[java-gnome-hackers] Cairo Surface's setMimeData() at last

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

I've merged a branch with coverage of Cairo Surface's setMimeData() to
'mainline'.

This is useful so that instead of the decoded and rastered bitmap image,
the original [ie jpeg, or to a lesser extent png] image can be attached
to a vector backend target instead. So JPEGs stay JPEGs instead of
turning into 12 MB bitmaps. Yeay.

Thanks to Adrian Johnson, Cairo PDF hacker extraordinaire for his
guidance in #cairo. I've been waiting about 2 years for this one to
appear in Cairo 1.10 and for us to  have a chance to use it :)

I documented it as follows here:
http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/cairo/Surface.html#setMimeData(org.freedesktop.cairo.MimeType,%20byte[])

AfC
Sydney

-- 
Andrew Frederick Cowie
#java-gnome on irc.gimp.net

[java-gnome-hackers] Rendering SVGs

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

I merged my 'rsvg' branch to 'mainline', exposing preliminary coverage
of the librsvg SVG loader. Allows you to draw an SVG image to Cairo.
Neato - and more to the point, better than loading with gdk-pixbuf which
rasterizes the graphic first.

I've had this one kicking around for ages, but hopefully it'll pass
muster now.

If anyone can think of a better way to test it, I'd welcome comments;
see org.gnome.rsvg.ValidateVectorIllustrations's testHandleRendering()

Also, it doesn't seem like the call to Rsvg.init() is actually
necessary; I included it because the library documentation says it
should be there. Hm.

There's an example, see cairo.ExampleDrawingPenguins though it doesn't
do anything that special. You could fix that, heh.

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: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Profiling to improve performance

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

On Mon, 2010-12-06 at 22:32 +0200, Serkan Kaba wrote:
>  can you ... report known
> bottlenecks/hotspots

Yeah, I've got a few things on my shit-list.

ClassLoading takes a long time. One of the things that is challenging is
telling the difference between time the JVM was going to take anyway,
and time taken because of the burden of the way we implemented things.

Pango has some speed issues too. I know that the underlying native
library has been in need of some performance love for a long time, but
it's entirely possible we're using Layout sub-optimally.

A bigger concern is memory pressure resulting from long-delayed
finalization, as we discussed in January. People will need to form their
own opinions about that.

Those are my concerns from before!

AfC
Sydney

Re: [java-gnome-hackers] Profiling to improve performance

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04-12-2010 06:57, Andrew Cowie wrote:
>
As I discussed with you on IRC, can you and any downstream report known
bottlenecks/hotspots for further investigation.

- -- 
Regards,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz9SGAACgkQRh6X64ivZaIc/wCdFPtfqes9gvVGEOMLdvBEarLU
ZRwAn0/GHHvAp2IBYogd2PF+A9be92y+
=UFWl
-----END PGP SIGNATURE-----

[java-gnome-hackers] Profiling to improve performance

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

Some of you may be aware that we've used the YourKit Java Profiler in
the past to help improve the performance of the java-gnome user
interface library.

YourKit is proprietary software, but they offer complimentary licences
to developers working on open source software as one of they ways they
give back to the community. I hadn't profiled java-gnome in some time,
and so recently requested a renewed licence for their current release,
version 9.5.

I was pleasantly surprised when Vladimir not only responded
affirmatively, but also send me a licence which anyone actively
contributing to the project could use!

So if you have been working on java-gnome recently (Bazaar knows who you
are, and thence so does Ohloh [1] :)) or are expecting to in the weeks,
months, and years to come, then don't hesitate to contact me on IRC and
I'll pass you the licence key & some tips for using it effectively.

Obviously no one uses a UI library in isolation, but I should think if
you're hacking on your own application built on top of java-gnome then
profiling that app will likely turn up information about java-gnome as
well which will hopefully benefit us all. So if you're not actively
contributing to java-gnome itself but are heavily using it without
really telling me, I'd also welcome hearing from you; profiling is best
when done with real-world loads.

Thanks again to YourKit for their support!

AfC
Sydney

[1] http://www.ohloh.net/p/java-gnome/contributors

-- 
Andrew Frederick Cowie
#java-gnome on irc.gimp.net

[java-gnome-hackers] java-gnome 4.0.17 released

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

The 'mainline' branch now identifies itself as 4.0.18-dev.

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] libnotify 0.7.0 Re: Useful lists

[Serkan K. <se...@ge...>]

As immediate intervation we should restrict libnotify version in our
configure script to < 0.7.0 and deprecate the removed methods. Then I
may introduce a branch that does the opposite and removes the
deprecated methods.

2010/11/16 Alexander Boström <ab...@ro...>:
> lör 2010-10-30 klockan 19:55 +0200 skrev Andrew Cowie:
>> Just a passing comment: as major API changes are happening in GTK
>> towards 3.0, useful mailing lists to be subscribed to are:
>
> Yup, this already happened with the Fedora package in rawhide (the
> future F15 release) as libnotify was updated to 0.7.0 and java-gnome
> won't build with that. (So I need a snapshot, rc or release which does.)
>
> Possibly I can provide a patch myself, as the changes seem rather
> trivial but it needs to be done in a way that'll still work with older
> libnotify releases.
>
> Is it ok to change the API exposed to the Java side? IIRC java-gnome
> isn't declare API stable but it'd be weird to have different APIs
> depending on which libnotify version it was compiled with.
>
> I guess the simplest solution is to change the API for all java-gnome
> users regardless of which libnotify it was compiled with...
>
>
>> From: Matthias Clasen <mc...@re...>
>> Datum: Mon, 01 Nov 2010 21:12:47 -0400
>
>> Here is an overview of the api changes:
>>
>> notify_notification_new_with_status_icon   is gone
>> notify_notification_attach_to_status_icon  is gone
>> notify_notification_attach_to_widget       is gone
>> notify_notification_set_geometry_hints     is gone
>> notify_notification_new                    has lost its widget argument
>>
>> A typical patch will look like this one:
>> https://bugzilla.gnome.org/review?bug=632327&attachment=172525
>>
>> For some background on these changes, see
>> http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
>
>
> /Alexander
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>

Re: [java-gnome-hackers] More about named icons

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

On Tue, 2010-11-16 at 08:35 +0100, Guillaume Mazoyer wrote:
> Well, I'm ok with that too.
> I think that Icon should stay in org.freedesktop.icons then.

Ok, done.

Pushed revnos 764 and 765 to 'mainline'. NEWS entry on website updated,
and java-gnome 4.0.17-rc4 uploaded

AfC
Sydney

[java-gnome-hackers] libnotify 0.7.0 Re: Useful lists

[Alexander B. <ab...@ro...>]

lör 2010-10-30 klockan 19:55 +0200 skrev Andrew Cowie: 
> Just a passing comment: as major API changes are happening in GTK
> towards 3.0, useful mailing lists to be subscribed to are:

Yup, this already happened with the Fedora package in rawhide (the
future F15 release) as libnotify was updated to 0.7.0 and java-gnome
won't build with that. (So I need a snapshot, rc or release which does.)

Possibly I can provide a patch myself, as the changes seem rather
trivial but it needs to be done in a way that'll still work with older
libnotify releases.

Is it ok to change the API exposed to the Java side? IIRC java-gnome
isn't declare API stable but it'd be weird to have different APIs
depending on which libnotify version it was compiled with.

I guess the simplest solution is to change the API for all java-gnome
users regardless of which libnotify it was compiled with...


> From: Matthias Clasen <mc...@re...>
> Datum: Mon, 01 Nov 2010 21:12:47 -0400

> Here is an overview of the api changes:
> 
> notify_notification_new_with_status_icon   is gone
> notify_notification_attach_to_status_icon  is gone
> notify_notification_attach_to_widget       is gone
> notify_notification_set_geometry_hints     is gone
> notify_notification_new                    has lost its widget argument
> 
> A typical patch will look like this one:
> https://bugzilla.gnome.org/review?bug=632327&attachment=172525
> 
> For some background on these changes, see
> http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility


/Alexander

Re: [java-gnome-hackers] More about named icons

[Guillaume M. <res...@gm...>]

Well, I'm ok with that too.
I think that Icon should stay in org.freedesktop.icons then.


-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] More about named icons

[Guillaume M. <res...@gm...>]

Well, I'm ok with that too.
I think that Icon should stay in org.freedesktop.icons then.


-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] More about named icons

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

On Mon, 2010-11-15 at 20:10 +0100, Guillaume Mazoyer wrote:
> 
> The available icons are extracted from the gnome-icon-theme 2.30. 

Yeah.

So it seems all these categories and names come from a FreeDesktop spec,
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

So after thinking about it for a while I've done up a patch that moves
org.gnome.gtk.Icon to org.freedesktop.icons.Icon This unfortunately
requires the creation of a helper class to get around visibility issues.
Perhaps this is more complexity than necessary, but we've prided
ourselves on not exposing internals and at least this keeps internals
out of the Icon class's completion space.

I also fixed up the test case a bit.

Attached.

I don't know if we should do this, but I'm inclined toward it. Opinions?

AfC
Sydney

Re: [java-gnome-hackers] More about named icons

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

On Mon, 2010-11-15 at 20:10 +0100, Guillaume Mazoyer wrote:
> As we discussed on IRC, here is the patch you ask me to do.
> It was pretty long but I think it is now better.

Very nice. Now just to decide if they're in the right package.

AfC
Sydney

Re: [java-gnome-hackers] More about named icons

[Guillaume M. <res...@gm...>]

As we discussed on IRC, here is the patch you ask me to do.
It was pretty long but I think it is now better.

The available icons are extracted from the gnome-icon-theme 2.30.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] More about named icons

[Guillaume M. <res...@gm...>]

> 3. Too many constants
> ----------------------------------
> 
> This is really bugging me. As it stands right now, there are about 300
> objects getting instantiated and put into the reverse lookup map. These
> are strongly referenced and even though an app might only use one or
> two, we have to maintain references to them for the lifetime of the
> program. There's nothing we can do about the in general, but
> specifically it's a bit silly to have all those objects loaded when
> you're not needing them.
Agreed on that. I'm not happy to see too many constants. It's pretty
lame to spend more than 30 seconds to find the right constant for
something.

> So, for Icon, I had the following idea:
> 
> Icon
> ├ ApplciationIcon
> ├ EmblemIcon
> ├ FaceIcon
> ├ MimeIcon
> └ ApplciationIcon
>   ...
> 
> and so on. If we get it right, then we can group them (more or less) by
> the same categories as found on disk, and more to the point, group them
> in related clumps. As it stands right now, you read through the Icon
> class in file order or alphabetically and it makes no sense because of
> things like this:
> 
>     public static Icon TEXT_X_SCRIPT;
>     public static Icon X_OFFICE_SPREADSHEET;
>     public static Icon X_OFFICE_DOCUMENT;
>     public static Icon APPLICATION_X_EXECUTABLE;
> 
> I've done about half of it; patch attached. What do you think?
I like that idea. Yes we will till have a lot of constants but classify
them is a good thing to use them easily.

> 4. Does it belong in org.gnome.gtk?
> ------------------------------------------------------
> 
> Finally, I'm not convinced any of this belongs in the GTK package. Part
> of me wants to put all this in org.gnome.icons; but the icon naming spec
> is a Free Desktop one; so perhaps org.freedesktop.icons is the right
> place for it.
> 
> Admittedly, messing with this would require some magic to enable
> getName() to be visible without making it public.
> 
> This would screw up (2) above, so perhaps we should just leave it alone.
I don't know... Maybe it would be better in org.freedesktop.icons. Where
does the user except to find those icons?

> I'm otherwise ready to release 4.0.17
I'm ready to package it ;)

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] More about named icons

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

I've been doing another pre-release API review, and I'm still not quite
happy about our named icons coverage.

1. Methods not using Icons
----------------------------------------

Now that Icon was introduced, lots of methods were kicking around that
took Strings (or that didn't work at all). I took care of this
'mainline' revno 762.

2. Code identical to Stock
--------------------------------------

The Icon parent class has the same map and name lookup code as Stock (I
believe it was cloned from there). Icon and Stock are essentially the
same thing - strongly typed wrappers around strings - so really they
should have a common [java-gnome] base class.

I spoke with Guillaume about this, he seemed to agree. This would be an
internal change, so we can make it next cycle.

3. Too many constants
----------------------------------

This is really bugging me. As it stands right now, there are about 300
objects getting instantiated and put into the reverse lookup map. These
are strongly referenced and even though an app might only use one or
two, we have to maintain references to them for the lifetime of the
program. There's nothing we can do about the in general, but
specifically it's a bit silly to have all those objects loaded when
you're not needing them.

In some other, unrelated, work I've been doing, I've spent a lot of time
pawing through /usr/share/icons/hicolor/48x48 and I've learned something
of the freedesktop naming spec. Along the way I've noticed the way icons
are put into subdirectories by category.

That gave me the idea to do what I did with Keyval for Icon.

Keyval
└ KeypadKeyval

In Keyval, I created a subclass KeypadKeyval for all the key pad
constants. They're perfectly available, but they don't mess up the
completion space when just using a few Keyvals, and if you don't use
them at all they don't get loaded.

So, for Icon, I had the following idea:

Icon
├ ApplciationIcon
├ EmblemIcon
├ FaceIcon
├ MimeIcon
└ ApplciationIcon
  ...

and so on. If we get it right, then we can group them (more or less) by
the same categories as found on disk, and more to the point, group them
in related clumps. As it stands right now, you read through the Icon
class in file order or alphabetically and it makes no sense because of
things like this:

    public static Icon TEXT_X_SCRIPT;
    public static Icon X_OFFICE_SPREADSHEET;
    public static Icon X_OFFICE_DOCUMENT;
    public static Icon APPLICATION_X_EXECUTABLE;

I've done about half of it; patch attached. What do you think?


4. Does it belong in org.gnome.gtk?
------------------------------------------------------

Finally, I'm not convinced any of this belongs in the GTK package. Part
of me wants to put all this in org.gnome.icons; but the icon naming spec
is a Free Desktop one; so perhaps org.freedesktop.icons is the right
place for it.

Admittedly, messing with this would require some magic to enable
getName() to be visible without making it public.

This would screw up (2) above, so perhaps we should just leave it alone.

Comments? ASAP please; I'm otherwise ready to release 4.0.17

AfC
Sydney

[java-gnome-hackers] Useful lists

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

Just a passing comment: as major API changes are happening in GTK
towards 3.0, useful mailing lists to be subscribed to are:

http://mail.gnome.org/mailman/listinfo/gtk-devel-list
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

A recent email on gtk-devel-list pointed to
http://library.gnome.org/devel/gtk/unstable/gtk-migrating-2-to-3.html

which I hadn't known about until now.

Cheers,

AfC
Granada