[java-gnome-hackers] Re: [Java-gnome-checkins] CVS: java-gnome/gtk/src/java/org/gnu/gtk BindingSet.java,1.3,1.4 ColorSelectionDialog.java,1.7,1.8

[Mark H. <mh...@ca...>]

Hi,
  Thanks for adding the javadoc.

On Mon, Dec 29, 2003 at 06:45:35PM -0800, Luca De Rugeriis wrote:
> + 	 * @param keyval The key value for the BindingSet. It must be a member of {@link org.gnu.gdk.KeySymbol}
>   	public boolean activateBindings(int keyval, ModifierType modifier) {

This seems wrong. We should not be passing around integers for things
like this - it is not very good Java style. Instead, we should pass
KeySymbol objects, from which the integers can be obtained. This means
changing the KeySymbol class into an Enum subclass (it should be
possible to do this quickly with a little automation - let me know if
you want me to do it); and also modifying these methods to take
KeySymbols instead of integers, passing keySymbol.getValue() to the
native method.
This is what we do for most similar parts of java-gnome, for example
ModifierType.


Luca, for your other comments about not knowing when a class may be
instantiated - 
Perhaps it would have been better to wait until we knew these things
before writing the java-gnome api for the class. 
When we write public API, it is very difficult to change after people
start using it. Therefore, it is best if we can get it done right first
time. I am worried that we may find ourselves in the situation that e.g.
gtk (or, even worse, swing) is in - they have api that they designed a
long time ago that is now deprecated (they have found better ways of
doing it, or just don't like the feel of the old api), but they cannot
change it since so many applications are using it. 

The Java-Gnome project does not have the aim to simply bind the
gtk/gnome libraries. If we did, we could probably do this automatically.
Instead, we are trying to write an intuitive object-orientated api for a
flat library. To make things worse, these libraries include api for
functions which are useful to the end user and also many functions which
are either only useful internally by the library, or were written in the
hope that they would be useful, but in reality are not useful.
Deciphering between these is not easy - so we don't want to make
java-gnome users have to do this; we will just provide useful methods.
The main way we do this is to think of situations where each method we
write may be used. If we cannot think of such a situation for a method,
then perhaps it should not be included in java-gnome - at this point we
ask for other opinions on the mailing lists, or just don't include it in
the public api, preferably giving an explanation in a comment in the
source file.


Your work on that is done now - I'm sure it will be useful at some point
and certainly is much appreciated. Those comments above were supposed to
be just helpful hints - sorry if they come across wrong, I'm not the
best person at writing that sort of thing. 

Your work on java-gnome is very impressive - I think it took me quite a
bit longer to get to the stage you're at now. I look forward to seeing
many more cvs commits :)

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca...