Re: [java-gnome-hackers] Annotation-based glade parsing patch

[FL B. <fl_...@ya...>]

Hello!

This is my first post to the list.
During the last few weeks I have been working on an application for the 
gnome desktop written in Java, with the java-gnome bindings as the GUI 
toolkit. In order to make the windows and dialogs designing easier, 
instead of building them programatically, I used the Glade designer, and 
accessed them via libglade and two simple libraries I developed to make 
gnome developing faster. One of them, is a set of annotations which 
binds the glade files and the ui code.

Now this annotations  (and the app itself) are pretty stable and usable, 
I thought  It would be a good idea to release this tiny library under a 
GPL. But then I noticed there was a post in this list were some 
annotations with similar functionality (an even names) were proposed and 
implemented two months before.

However, I still would like to share them, because they have some 
features that could be found useful.

This are the features similar to the yet existing annotations:

*annotate widget attributes as @Widget,  in order to retrieve them from 
the glade file with an EJB fashion. If no name is specified, the 
attribute name is used to get them from the glade XML.
*annotate methods as @Handler, for defining signal handlers which listen 
to certain signals from certain widgets
*Classes wich want to use them must extends a Connector abstract class.
*annotations can be applied to private fileds

And this is are the extra features:

*signal handlers are methods instead of inner classes, which makes the 
code cleaner. The handler classes are generated at runtime. This methods 
are quite flexible in what return and parameter types refer.
*there is no jni code to access private fileds, is pure java.
*The need to extend a certain class could be a problem in Java (because 
of the lack of multiple inheritance), so the Conncetor class offers 
static methods which let any class to use this annotations even if they 
extend another class.
*offer a flexible error handling mechanism, which I believe is the most 
important feature. Normally, if an unhecked exception is thrown in a 
common singal handling  method, the gtk thread dies and the app crashes. 
This is really awful, because apps should at least inform about he bug, 
let the user sava his or her work, and quit normally. There are several 
ways to avoid this by hand: surrounding all methods with try-catch 
blocks or dispatching events in a separate thread.
Because of that, annotated methods have error handlers and associated. 
Depending on an optional attribute in @Handler annotations, you can set 
an ErrorHanndling Policy which logs, displays messages or performs 
custom code -using a third annotation @ErrorHandler - when unhandled 
exceptions are thrown. Obviously, this behaviour can be disabled if you 
prefer.

If you are interested in this library, write me, please. I would be glad 
of contributing to the java-gnome project.