java-gnome-hackers

[java-gnome-hackers] Event Handling proposal

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

Hi,
sorry for not suggesting this earlier - I was still learning how
Java-gnome worked back then.=20

I don't like the way event type checking is done:
if (event.getId() =3D=3D KeyEvent.PRESSED){
I think this would be better done something like:
if (event.isOfType(KeyEvent.Type.PRESSED) ){

This:
- ensures a type is used, not any arbitrary integer
- is immediately obvious to the developer
- is readable
- has better toString support (see below)


I have created the following sources to show how I propose it should be
done:

GtkEvent.java:
public class GtkEvent implements Serializable {
  protected GtkEventType type;
  protected Object source;

  public GtkEvent(Object source, GtkEventType type) {
    if (null =3D=3D source)
       throw new IllegalArgumentException("null source");
    this.source =3D source;
    this.type =3D type;
  }
  public Object getSource() {
    return source;
  }
  public int getType() {
    return type;
  }
  public String toString() {
   return getClass().getName() + "[source=3D" + source + ",id=3D" +
type.getName() + "]";
  }
}

GtkEventType.java:
public class GtkEventType{
  private int id;
  private String name;
  protected int getID(){
    return id;
  }
  protected String getName(){
    return name;
  }
  protected GtkEventType(int typeID, String typeName){
    id =3D typeID;
    name =3D typeName;
  }
}

Sample Event (ButtonEvent.java):
public class ButtonEvent extends GtkEvent {=09
  public static class Type extends GtkEventType{
    public static final ButtonEventType ACTIVATE =3D new ButtonEvent(1,
"ACTIVATE");
    public static final ButtonEventType CLICK =3D new ButtonEvent(2,
"CLICK");
    public static final ButtonEventType ENTER =3D new ButtonEvent(3,
"ENTER");
    public static final ButtonEventType LEAVE =3D new ButtonEvent(4,
"Leave");
    public static final ButtonEventType PRESS =3D new ButtonEvent(5,
"PRESS");
    public static final ButtonEventType RELEASE =3D new ButtonEvent(6,
"RELEASE");
   // the strings were defined separately using the old method.
  }
  public interface Listener{
    public void buttonEvent(ButtonEvent event );
  }
  public ButtonEvent(Object source, ButtonEvent.Type type) {
    super(source, type);
  }
  public boolean ofType(ButtonEvent.Type type){
    return ( id =3D=3D type.getID());
  }
}

I have not done extensive testing of this (as it would require changing
all the events and methods which use them), but I see no reason why it
shouldn't work - we are still dealing with exactly the same data.=20

I think this should be done for the simple reason that=20
event.isOfType( ButtonEvent.Type.CLICK )
is far more obvious to the developer (and it is readable)

The question of Type and Listener being done as inner classes is
debatable. Perhaps listener should be separate.

I am prepared to make the necessary changes to all the currently
implemented events and classes which use these.=20

Let me know your thoughts.
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

Re: [java-gnome-hackers] Event Handling proposal

[Philip A. C. <pc...@td...>]

I agree that GtkEvent should not allow arbitrary integers.  My
suggestion would be to use org.gnu.glib.Enum.  That way it does not
allow arbitrary values and it's use is consistant with the way things
are done elsewhere in GTK.  Honestly, in my mind, I *thought* GtkEvent
extended Enum; but I see now that it doesn't.

On Tue, 2002-09-03 at 12:31, Mark Howard wrote:
> Hi,
> sorry for not suggesting this earlier - I was still learning how
> Java-gnome worked back then.=20
>=20
> I don't like the way event type checking is done:
> if (event.getId() =3D=3D KeyEvent.PRESSED){
> I think this would be better done something like:
> if (event.isOfType(KeyEvent.Type.PRESSED) ){
>=20
> This:
> - ensures a type is used, not any arbitrary integer
> - is immediately obvious to the developer
> - is readable
> - has better toString support (see below)
>=20
>=20
> I have created the following sources to show how I propose it should be
> done:
>=20
> GtkEvent.java:
> public class GtkEvent implements Serializable {
>   protected GtkEventType type;
>   protected Object source;
>=20
>   public GtkEvent(Object source, GtkEventType type) {
>     if (null =3D=3D source)
>        throw new IllegalArgumentException("null source");
>     this.source =3D source;
>     this.type =3D type;
>   }
>   public Object getSource() {
>     return source;
>   }
>   public int getType() {
>     return type;
>   }
>   public String toString() {
>    return getClass().getName() + "[source=3D" + source + ",id=3D" +
> type.getName() + "]";
>   }
> }
>=20
> GtkEventType.java:
> public class GtkEventType{
>   private int id;
>   private String name;
>   protected int getID(){
>     return id;
>   }
>   protected String getName(){
>     return name;
>   }
>   protected GtkEventType(int typeID, String typeName){
>     id =3D typeID;
>     name =3D typeName;
>   }
> }
>=20
> Sample Event (ButtonEvent.java):
> public class ButtonEvent extends GtkEvent {=09
>   public static class Type extends GtkEventType{
>     public static final ButtonEventType ACTIVATE =3D new ButtonEvent(1,
> "ACTIVATE");
>     public static final ButtonEventType CLICK =3D new ButtonEvent(2,
> "CLICK");
>     public static final ButtonEventType ENTER =3D new ButtonEvent(3,
> "ENTER");
>     public static final ButtonEventType LEAVE =3D new ButtonEvent(4,
> "Leave");
>     public static final ButtonEventType PRESS =3D new ButtonEvent(5,
> "PRESS");
>     public static final ButtonEventType RELEASE =3D new ButtonEvent(6,
> "RELEASE");
>    // the strings were defined separately using the old method.
>   }
>   public interface Listener{
>     public void buttonEvent(ButtonEvent event );
>   }
>   public ButtonEvent(Object source, ButtonEvent.Type type) {
>     super(source, type);
>   }
>   public boolean ofType(ButtonEvent.Type type){
>     return ( id =3D=3D type.getID());
>   }
> }
>=20
> I have not done extensive testing of this (as it would require changing
> all the events and methods which use them), but I see no reason why it
> shouldn't work - we are still dealing with exactly the same data.=20
>=20
> I think this should be done for the simple reason that=20
> event.isOfType( ButtonEvent.Type.CLICK )
> is far more obvious to the developer (and it is readable)
>=20
> The question of Type and Listener being done as inner classes is
> debatable. Perhaps listener should be separate.
>=20
> I am prepared to make the necessary changes to all the currently
> implemented events and classes which use these.=20
>=20
> Let me know your thoughts.
> --=20
>=20
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Event Handling proposal

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

On Tue, 2002-09-03 at 20:43, Philip A. Chapman wrote:
> I agree that GtkEvent should not allow arbitrary integers.  My
> suggestion would be to use org.gnu.glib.Enum.  That way it does not
> allow arbitrary values and it's use is consistant with the way things
> are done elsewhere in GTK.  Honestly, in my mind, I *thought* GtkEvent
> extended Enum; but I see now that it doesn't.

Event can't extend enum - it is created at the time the gtk signal is
made, including references to the source widget and possibly other data
(depending on the event).=20

The EventType class I used in the example contains both an integer value
and a String for each type. The integer is the ID and the string is used
in the GtkEvent.toString method (useful for debugging applications).
Hence, EventType classes would be best extending the EventType class I
defined in that example.=20

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+