Unplugged tablets and tablet hotplugging

[Jason]

I've been spending the past few days (finally getting around to)
working on the Linux port. I've got a working ANT script, and have
recently started on actually implementing XInputTabletManager. I've
been building up a list of questions and suggestions, though I just
ran into one that's a little more peculiar than the rest:

What should happen if a JTablet user starts an appl(et|ication]) with
their tablet unplugged? Using a Windows user as an example, this would
mean that they have the native WinTab driver available but no actual
tablet device to use.

If I understand the code correctly (since I haven't actually tried
this), WinTabTabletManager should currently load() without any
problems. Since TabletManagerImpl only uses the "best" TabletManager
it can find, this means that an appl(et|ication]) will receive events
from these native managers. However, since there is no tablet plugged
in, no events will be generated.

It seems that JTablet should gracefully fall back to a simple
MouseTabletManager if no tablet is connected. This would be needed for
the e.g. laptop user who did not bring their tablet but still wishes
to use a JTablet-enabled appl(et|ication]). The simplest way to
implement this would be to have the NativeTabletManager bomb on load()
if there are no tablets connected.

Ideally though, a user should be able to connect and disconnect
tablets at will and have JTablet continue to work without problems.
I'm not sure how feasible it would be to do this though. Any ideas?

[Garret Cole]

There should definitely be an event generated if the tablet is unplugged or plugged in, that is, if the drivers can detect such a thing. Where the event is directed to in the API is the next question. Perhaps just another method to pass a driver notification event.

G

--
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.

[Marcello Bastéa-Forte]

You hit on some good points, so let me see if I can throw some things to think about!

On Mon, Mar 29, 2010 at 1:08 PM, Jason <kille...@gmail.com> wrote:

I've been spending the past few days (finally getting around to)
working on the Linux port. I've got a working ANT script, and have
recently started on actually implementing XInputTabletManager. I've
been building up a list of questions and suggestions, though I just
ran into one that's a little more peculiar than the rest:

What should happen if a JTablet user starts an appl(et|ication]) with
their tablet unplugged? Using a Windows user as an example, this would
mean that they have the native WinTab driver available but no actual
tablet device to use.

If I understand the code correctly (since I haven't actually tried
this), WinTabTabletManager should currently load() without any
problems. Since TabletManagerImpl only uses the "best" TabletManager
it can find, this means that an appl(et|ication]) will receive events
from these native managers. However, since there is no tablet plugged
in, no events will be generated.

On Windows, to support regular mice, I combine a MouseListener with WinTab and switch when I stop receiving WinTab events. I seem to recall if you start the WinTab without a tablet plugged in, it will fail/throw an exception, though I'm not positive.

On Mac OS X, since the OS handles the tablet as regular mouse events with extra information, and JTablet pulls all these events, and implicitly handles the hot-swap scenario. Since I translate all mouse events, tablet or not, I don't need to use a MouseListener at all.

On Linux, you could go either way. Switch back and forth like on Windows, or map all XInput mouse/tablet events like on Mac OS X.

It seems that JTablet should gracefully fall back to a simple
MouseTabletManager if no tablet is connected. This would be needed for
the e.g. laptop user who did not bring their tablet but still wishes
to use a JTablet-enabled appl(et|ication]).

 

The simplest way to
implement this would be to have the NativeTabletManager bomb on load()
if there are no tablets connected.

Ideally though, a user should be able to connect and disconnect
tablets at will and have JTablet continue to work without problems.
I'm not sure how feasible it would be to do this though. Any ideas?

This is the ideal scenario. Currently that feature is not supported on Windows (afaik), but it be automatic. 

Plug in a tablet, the applet/application starts to receive events. Similarly, unplugging and replugging should be supported.

As Garret suggests, I think it is worth considering an API for hot swapping down the line. Such as a TabletDeviceListener with tabletDetected / tabletLost events, a way to enumerate the current tablets, get information about them (size, capabilities), and even support some of the additional features like the touchstrips/wheels and OLED buttons. I think that can wait for a post 2.0 release. ;-)

Curious, are you using the JPen XInput code, or are you using the JTablet 0.9.x XInput code?

Marcello

[Jason Gerecke]

On Mon, Mar 29, 2010 at 10:14 PM, Marcello Bastéa-Forte <marc...@cellosoft.com> wrote:

You hit on some good points, so let me see if I can throw some things to think about!

On Mon, Mar 29, 2010 at 1:08 PM, Jason <kille...@gmail.com> wrote:

I've been spending the past few days (finally getting around to)
working on the Linux port. I've got a working ANT script, and have
recently started on actually implementing XInputTabletManager. I've
been building up a list of questions and suggestions, though I just
ran into one that's a little more peculiar than the rest:

What should happen if a JTablet user starts an appl(et|ication]) with
their tablet unplugged? Using a Windows user as an example, this would
mean that they have the native WinTab driver available but no actual
tablet device to use.

If I understand the code correctly (since I haven't actually tried
this), WinTabTabletManager should currently load() without any
problems. Since TabletManagerImpl only uses the "best" TabletManager
it can find, this means that an appl(et|ication]) will receive events
from these native managers. However, since there is no tablet plugged
in, no events will be generated.

On Windows, to support regular mice, I combine a MouseListener with WinTab and switch when I stop receiving WinTab events. I seem to recall if you start the WinTab without a tablet plugged in, it will fail/throw an exception, though I'm not positive.

On Mac OS X, since the OS handles the tablet as regular mouse events with extra information, and JTablet pulls all these events, and implicitly handles the hot-swap scenario. Since I translate all mouse events, tablet or not, I don't need to use a MouseListener at all.

On Linux, you could go either way. Switch back and forth like on Windows, or map all XInput mouse/tablet events like on Mac OS X.

I had totally missed the MouseListener hiding in there. A very interesting solution! I'm not sure which route I'll choose right now, but since XInput works like OS X, it may be more similar to that. We'll have to see which works best :)

It seems that JTablet should gracefully fall back to a simple
MouseTabletManager if no tablet is connected. This would be needed for
the e.g. laptop user who did not bring their tablet but still wishes
to use a JTablet-enabled appl(et|ication]).

 

The simplest way to
implement this would be to have the NativeTabletManager bomb on load()
if there are no tablets connected.

Ideally though, a user should be able to connect and disconnect
tablets at will and have JTablet continue to work without problems.
I'm not sure how feasible it would be to do this though. Any ideas?

This is the ideal scenario. Currently that feature is not supported on Windows (afaik), but it be automatic. 

Plug in a tablet, the applet/application starts to receive events. Similarly, unplugging and replugging should be supported.

As Garret suggests, I think it is worth considering an API for hot swapping down the line. Such as a TabletDeviceListener with tabletDetected / tabletLost events, a way to enumerate the current tablets, get information about them (size, capabilities), and even support some of the additional features like the touchstrips/wheels and OLED buttons. I think that can wait for a post 2.0 release. ;-)

It would be pretty interesting to have tablet detection, though you're right that it can wait for a later release. As long as tablet users can still work without one, things should work quite well.
 

Curious, are you using the JPen XInput code, or are you using the JTablet 0.9.x XInput code?

I'm having the implementation use JPen's code. My XInput code has always been somewhat finicky, so I'm hoping that this will work better on more people's systems.

Jason

[Marcello Bastéa-Forte]

I had totally missed the MouseListener hiding in there. A very interesting solution! I'm not sure which route I'll choose right now, but since XInput works like OS X, it may be more similar to that. We'll have to see which works best :)

While writing my last e-mail I noticed that I'm using a regular component based mouse listener and not a "screen" mouse listener (which listens to the awt event queue)... so I'm probably going to change that.

I'm having the implementation use JPen's code. My XInput code has always been somewhat finicky, so I'm hoping that this will work better on more people's systems.

Awesome. I can add you as an SVN user if that'd make it easier. I have ubuntu on vmware and am happy to help.

On a related note, I decided to not do a Java web-based installer due to complications. I'm now using Mac OS X's PackageMaker, and NSIS (used for JTablet 0.9.x, too) on Windows, so I think a new .deb installer is in order (especially if it can do stuff like detect java, and require removal of the previous version).

It looks like on Linux with Java 6 you can build multiple architectures and put them in /usr/java/packages/lib/<arch>. How difficult is it to get a debian into the official debian/ubuntu package manager system?

Marcello

[Jason Gerecke]

On Wed, Mar 31, 2010 at 10:00 AM, Marcello Bastéa-Forte <marc...@cellosoft.com> wrote:

I had totally missed the MouseListener hiding in there. A very interesting solution! I'm not sure which route I'll choose right now, but since XInput works like OS X, it may be more similar to that. We'll have to see which works best :)

While writing my last e-mail I noticed that I'm using a regular component based mouse listener and not a "screen" mouse listener (which listens to the awt event queue)... so I'm probably going to change that.

I'm having the implementation use JPen's code. My XInput code has always been somewhat finicky, so I'm hoping that this will work better on more people's systems.

Awesome. I can add you as an SVN user if that'd make it easier. I have ubuntu on vmware and am happy to help.

That would be nice to have. Just email me if you need any information.
 

On a related note, I decided to not do a Java web-based installer due to complications. I'm now using Mac OS X's PackageMaker, and NSIS (used for JTablet 0.9.x, too) on Windows, so I think a new .deb installer is in order (especially if it can do stuff like detect java, and require removal of the previous version).

It looks like on Linux with Java 6 you can build multiple architectures and put them in /usr/java/packages/lib/<arch>. How difficult is it to get a debian into the official debian/ubuntu package manager system?

DEB (and other packages) are all good at making sure the system has the necessary requirements, and downloading them if they aren't already there. Its pretty easy to make a DEB as well, though I haven't a clue as to how hard it is to get a package into the official repositories. However, there are a *lot* of better-known projects though that require the user to use add a private repository or download/run a DEB file.

Jason

[Marcello Bastéa-Forte]

On Windows, to support regular mice, I combine a MouseListener with WinTab and switch when I stop receiving WinTab events. I seem to recall if you start the WinTab without a tablet plugged in, it will fail/throw an exception, though I'm not positive.

In my testing of the alpha release I tried this out. It works correctly on Windows as well. Plugging a tablet in after starting JTablet and unplugging/replugging while it's running all work as expected.

Of course, there's no way to determine whether the user has a tablet plugged in, but we can save that problem for a future release. :-)

Marcello