[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