Re: [Java-gnome-developer] OptionMenu events etc..

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

Hi,
 Before you do anything, please add a bug entry for this to
sourceforge.net - we seem to have lots of little unfinished bits like
this, but aren't tracking them very well. Also, add reports for anything
else you find :)
 
On Thu, Oct 02, 2003 at 02:41:42PM +0300, Jonas Berlin wrote:
>  - what is autogenerated and whatnot
Everyting was initially autogenerated. In the latest automatic
generation, some jni/c code was autogenerated and java files were
generated containing the native methods. Everything else has been added
by hand. This is basically almost everything in the java files apart
from the bottom few lines and either nothing in jni files, or a few
functions at the top of the files, or in some cases entire jni files.

Adding an event for an option menu will probably be possible without
changing any c code. (We try to do as little c work as possible since it
is far easier to debug java and it usually works better that way)

Three things are needed for an event:

events/eventnameEvent.java
e.g. ButtonEvent
Each event has a static nested Type class. This allows us to have
varients of an event handled by the same methods. This should extend
GtkEventType and the static final fields of it have a unique identifier
and a name. This part should be easy to construct. (Option menu will
probably only have one type - CHANGE)
The rest of the class can be basically copied

events/eventnameListener.java
This is the listener which the user's code must implement. Should be
kept as simple as possible. We tend to prefer a single method for a
group of related events rather than lots of methods which probably won't
all get implemented. 
Any objections to what events go in which methods can be discussed in
the mailing lists.

The widget. Take Button.java as an example:
We can have multiple objects listening for an event, so need:
private Vector buttonListeners = null;
We then have methods for adding and removing events:
public void addListener(ButtonListener listener) {
public void removeListener(ButtonListener listener) {

We then have a convenience function for calling the methods of the
objects which are listening:
protected void fireButtonEvent(ButtonEvent event) {

Everything so far can be more or less copied (changing the Event and
listener class names.

The next stage is to actually receive notification of the events from
the native layer. This is done through the addEvents method. The jni
code is done in other parts of java-gnome, so for things like Buttons
and OptionMenus, it's just a case of adding:
protected static void addEvents(EventMap anEvtMap) {
		Widget.addEvents(anEvtMap);
		anEvtMap.addEvent("clicked", "handleClick", ButtonEvent.Type.CLICK, ButtonListener.class);
activate is the name of the gtk signal. handleActivate is a method in
this class:		
private void handleClick() {
	fireButtonEvent(new ButtonEvent(this, ButtonEvent.Type.CLICK));
}

Copying code like this should be fairly straight forward (for simple
widgets at least). We will of course review any patches to look out for
problems.

> I could then try to implement the stuff needed in OptionMenu (and maybe 
> send a patch).. and maybe later other components as well.
I look forward to seeing it.
Note that many of the signals have not been implemented for a good
reason; we are trying not to copy the deprecated or internal parts of
gtk (option menu changing does not come into this category).

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