distinguishing userinterface events from others

Engines, Libraries and Tools Xith3D Forums
#1

Currently I see no way of distinguishing userinterface events from events on the canvas. In most apps the UIEventAdapter will catch all events. It uses them for dragging UIWindows or hands it over to the appropriate JComponent. On its way the event itself is not changed, besides its coordinates are translated relative to the UIWindow it occured in. Usually an app has a second event handler (for instance for handling picking). However this event handler has no chance to detect if the event occured in a UIWindow or not (correct me, if I’m wrong here).

Simple example: User clicks somewhere on a UIWindow without triggering a specific action. Usually this should not lead to any reaction within the scene, because the user often doesn’t even know what object he clicked on within the scene.

I have added a simple one-line-patch (see below) to the UIWindowManager, which sets the source of a mouse event to the UIWindow the event occured in. This allows the app to find out if the event occured in a UIWindow and which UIWindow it occured in. This works for me.

How is this supposed to work in Xith3D? In case you had the problem: How did you handle it?


// if we get here, but we have not consumed the mouse message then
// determine if the mouse event should be sent
if (!eventConsumed) {
  if (w != null) {
    Object o = (Object) w.getOverlay();

    if (o instanceof UIWindow) {
      me.translatePoint(-(int) w.getRectangle().getX(),
                              -(int) w.getRectangle().getY());
      me.setSource((UIWindow)o);
      ((UIWindow) o).dispatchEvent(me);
    }
  }
}

(code always looks ugly in this forum)

#2

The translation of the coordinates causes additional problems. Let’s say you get an event and determine it comes from a certain UIWindow (which is possible with the small patch above). You have two scenarios:

The first is you decide you don’t need the event (in most cases this will be true) and drop it. The second is that you decide you need the event and want to something with it. An example of the second case is dragging around an image (which is a UIWindow with only one transparent JPanel) with the mouse. The image is near to the cursor. It’s possible to move the cursor onto the image. Now you get wrong coordinates for the mouse event, because they are now relative to upper left corner of the image. The consequence is that the image appears somewhere in the upper left corner of the screen, because I think the cursor is there.

To make a long story short I think the userinterface event handling can be improved. In my opinion you should be able to 1.) find out if the event occured on a UIWindow or not and 2.) be able to get the canvas coordinates of the mouse event. The question is how this can be added to Xith3D. It’s not trivial.

If my explanation is not clear, please ask.

If you know a better way to drag around an image in the scene, please tell me. Dragging around a UIWindow is a performance killer. :slight_smile:

#3

bump

Is it possible that at least the coordinates of the mouse events are not modified or the event is changed, so that it can be distinguished from non-userinterface events?

#4

I will take care of this, but it will require that the event be copied in order to protect the event from corruption.

#5

That sounds like a good idea. One copy is used to handle all the userinterface internal stuff and the app will only “see” the copy with the unmodified x-y-position.

Currently I use the simple patch above to set the source of the mouse event to the UIWindow the event occured on, but I don’t know if this is generally a good idea. I see two ways for an app to find out which UIWindow an event occured on:

  1. Use a helper method which takes a point as an argument and returns a UIOverlayInterface.
  2. Modify the event itself.
    Sometimes you will want that to use an event for picking behind a UIWindow (for instance if you have a simple translucent overlay, which just displays text somewhere on the screen), but in most cases you will want to ignore events which occured on a UIWindow.
#6

bump