A Different Approach To TabletManager

[Jason]

One of the big issues that has been bugging me (especially with trying
to get the mouse working) is the whole TabletManager class hierarchy.
It needs a rethink IMO.

It is difficult to get two seperate TabletManager classes working
together. The code just wasn't designed with it in mind, but we're
forced to work around the issue since we'd like to have the
MouseTabletManager act as a backup source of TabletEvents.

I've been thinking about this for a while now, and I think the best
solution would be a division of responsibility. Instead of having the
TabletManager class try to do everything from communicating with the
native library to notifying observers, there could be a "TabletDriver"
class (which only communicates with the native library) and a
"TabletManager" class (which filters events from the TabletDrivers and
delivers them to observers).

In my mind, you could have the following concrete classes:
* TabletManager
* MouseDriver
* ScreenMouseDriver
* CocoaDriver
* WinTabDriver
* XInputDriver
* WacomWebDriver
* JPenDriver
* SomeOtherDriver

TabletManager would use reflection to dynamically create an instance
of as many drivers as it can (like TabletManagerImpl). Next, JTablet
would call the start() method on each driver so that they can get
events in the background. Each driver would send its events to the
TabletManager which would then filter the events into a single
coherent stream and then pass them on to the client.

All the code already exists, except for the "filter the events into a
single coherent stream". Of the many ways to perform the filtering,
one reasonable approach would be to give individual drivers a certian
priority (whether
defined by the user, the driver itself, or a combination) and only
pass events from the highest-priority driver that is in proximity. Not
only is this code easy to write, but is generally exactly what the
user wants to happen anyway. A more complex filter could handle things
like multitouch or multiple pointers (which would be **really** cool!)

[Marcello Bastéa-Forte]

I like the motive of your design, and I want to push you further in fleshing out the implementation (especially the "filter" aspect). Let me see if I can summarize the rational behind the current implementation:

The primary difference between your suggestion and the current design is at what point simultaneous drivers are handled. Currently, the platform-specific implementation decides how to combine and dispatch events (the model being, it knows best), rather than a cross-platform system.

The Mac OS X driver receives all mouse and tablet events from JNI. It then subclasses ScreenTabletManager to handle the actual work of dispatching events.

The Windows driver only receives tablet data (no mouse data), so it has a slave driver for use in situations where there are no tablet events. The switching logic is Wintab-specific and wouldn't apply to the Mac OS X driver (but may be similar to the Linux driver).

The driver hierarchy is more of a tree:

Mac OS X      Windows        *nix          Other

  |              |             |             |

CocoaDriver   WinTabDriver   XInputDriver    |

  |              |             |            /

   \______________\_____ _____/____________/

                        |

                  WacomWebPlugin (requires plugin, applet with custom html)

                        |

                  AWTMouseDriver (requires security access)

                        |

               ComponentMouseDriver (if all else fails)

In this respect, we have a pseudo-2D hierarchy, where a platform-specific driver controls everything, otherwise we cycle through cross-platform fall-back drivers. 

It doesn't really make sense to spend cycles on ComponentMouseDriver if we have an AWTMouseDriver, and it doesn't make sense to spend cycles on an AWTMouseDriver if we have a CocoaDriver...

That said, it does give less control to the developer/user if the decision is somehow made incorrectly.

And for multi-touch/multiple pointers, I would much rather come up with a really good solution that targets multi-touch/multiple pointers (jtablet 2.5? ;-)) in a sensible matter that fits with the Java model before adding it into the main project. Writing a GOOD api for multi-pointer/multi-touch applications is not a trivial task (especially when it's not supported by the operating system's GUI), but I think it'd be great to experiment with support (JTablet branch?) if we can come up with some solid use-cases first.

Marcello

--
You received this message because you are subscribed to the Google Groups "jtablet-dev" group.
To post to this group, send email to jtabl...@googlegroups.com.
To unsubscribe from this group, send email to jtablet-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jtablet-dev?hl=en.