Gtk constants in Java

Sat Jul 15 11:06:00 GMT 2000

Oskar Liljeblad <osk@hem.passagen.se> writes:
> Java-Gnome takes another approach though. For each flag- or enumeration-set,
> (introduced by 'define-flags' or 'define-enums' in the .defs file), a
> separate class is created. Not only this, each constant is also a separate
> object. ...
> Something the author of Java-Gnome probably didn't think of is that
> flags may need to be OR'ed. The above wouldn't work if GtkArrowType's
> could be combined. In my opinion this makes this alternative unusable.

Another serious flaw: enum "objects" don't get inlined by the compiler,
unless the compiler is unusally smart.
> As I see it, there are only three viable alternatives:
>> 1. All constants are kept in a "static" class called Gtk
> (Gtk.ARROW_UP, Gtk.ARROW_DOWN, ..). This is probably the
> most "economic" solution.

The problem with this is that it isn't extensible to user-supplied widgets.
However, I notice that most gtk enums are defined in a single global file:
gtkenums.h. (I don't know about the "defs" version.) It is tempting to
put all of these enums in a single interface:
public interface GtkEnums
{
 // GtkArrowType:
 public final static int ARROW_UP = 0;
 public final static int ARROW_DOWN = 1;
 ...
 // GtkAttachOptions:
 public final static int EXPAND = 1 << 0;
 public final static int SHRINK = 1 << 1;
 ...
}
This has the advantage that it is convenient to use (just have client
classes implement GtkEnum, and they can just use the enum names),
as well as efficient. One disadvantage is that you don't have any
connection between the enum value and the enum "type". Of course in
Java you don't get that anyway (unless you use aproach that Java-Gnome
takes). The other disadvantage is that new widget types would be
handled differently from standard ones. (The former wodl have to use
new classes/interfaces, the latter uses a common shared interface).
This approach is as you note probably the lowest-overhead one, easy for
users, and it seems very compatible with existing Gnome practice, so
it is quite tempting.
> 2. One "static" class for each flag/enum-set, with int-constants as
> the first alternative above (GtkArrowType.UP, GtkArrowType.DOWN,
> ..). This is the nicest solution IMHO.

I agree this makes a lot of sense, though using an interface instead
of a class (as suggested) is probably better.
> It is also efficient if
> the run-time needn't keep the classes in memory. (Is this true?)

Yes. If GtkArrowType is not accessed *except* for the final static
int constants, then the class will not get initialized at run-time,
since the final static int constants get expanded at compile-time.
> 3. Constants are kept in the object class which they belong to.
> I.e. GTK_BUTTON_IGNORED from the GtkButtonAction flag-set would
> be GtkButton.IGNORED in Java. This would not work for all
> enumerations, because they are used in more than one gtk
> widget. An example is the GtkMatchType enumeration (there is no
> GtkMatch). This could be solved by putting these ambiguous constants
> in a class Gtk (like alt. 2), or putting then in all classes they
> apply to.

For enumeration types that "clearly" belong to a specific class, it
is reasonable to merge the Java classes for the data with that for the
enum, giving a single class. For other enumeration types, that doesn't
work as you point out.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/~per/