JPen - Java Pen Tablet Access Library

Hi, I just downloaded the 091221 release and found there are some problems when running on mac. When I launch the demo application, like previous releases it starts in CURSOR mode, however unlike previous releases it does not switch to STYLUS mode when the cursor enters the drawing area. I can get it to switch to STYLUS mode by doing one of several things: - Move the mouse while the cursor is inside the drawing area - Switch to another application and back while the cursor is inside the drawing area Once the switch to STYLUS mode is made, it is no longer possible to draw using the mouse (blue ink). This problem does not occur in release 090914. Thanks! Karl ===== JPen - Status Report ===== JPen Version: 2-091221 Date: Fri Dec 25 21:32:37 EST 2009 Providers: Constructor: JPen Construction Exception: none Device: Emulation (Emulation@JPen) Is Digitizer: false Enabled: false Kind: (type=IGNORE) Constructor: System Construction Exception: none Device: Mouse (Mouse@System) Is Digitizer: false Enabled: true Kind: (type=CURSOR) Constructor: Cocoa Construction Exception: none Native Version-Build(Expected): 2-1(1) Device: Cocoa Cursor (Cocoa Cursor@Cocoa) Is Digitizer: true Enabled: false Kind: (type=CURSOR) Device: Cocoa Stylus (Cocoa Stylus@Cocoa) Is Digitizer: true Enabled: false Kind: (type=STYLUS) Device: Cocoa Eraser (Cocoa Eraser@Cocoa) Is Digitizer: true Enabled: false Kind: (type=ERASER) Device: UNKNOWN (UNKNOWN@Cocoa) Is Digitizer: true Enabled: false Kind: (type=IGNORE) System Properties: apple.awt.graphics.UseQuartz: true awt.nativeDoubleBuffering: true awt.toolkit: apple.awt.CToolkit file.encoding: MacRoman file.encoding.pkg: sun.io file.separator: / ftp.nonProxyHosts: local|*.local|169.254/16|*.169.254/16 gopherProxySet: false http.nonProxyHosts: local|*.local|169.254/16|*.169.254/16 java.awt.graphicsenv: apple.awt.CGraphicsEnvironment java.awt.printerjob: apple.awt.CPrinterJob java.class.path: /Users/karlwillis/Alchemy/Code/svn/Alchemy/lib/jpen/jpen-2.jar java.class.version: 49.0 java.endorsed.dirs: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/endorsed java.ext.dirs: /Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext java.home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java java.runtime.name: Java(TM) 2 Runtime Environment, Standard Edition java.runtime.version: 1.5.0_20-b02-315 java.specification.name: Java Platform API Specification java.specification.vendor: Sun Microsystems Inc. java.specification.version: 1.5 java.vendor: Apple Inc. java.vendor.url: http://www.apple.com/ java.vendor.url.bug: http://bugreport.apple.com/ java.version: 1.5.0_20 java.vm.info: mixed mode, sharing java.vm.name: Java HotSpot(TM) Client VM java.vm.specification.name: Java Virtual Machine Specification java.vm.specification.vendor: Sun Microsystems Inc. java.vm.specification.version: 1.0 java.vm.vendor: Apple Inc. java.vm.version: 1.5.0_20-141 mrj.version: 1050.1.5.0_20-315 os.arch: i386 os.name: Mac OS X os.version: 10.5.8 path.separator: : socksNonProxyHosts: local|*.local|169.254/16|*.169.254/16 sun.arch.data.model: 32 sun.awt.exception.handler: apple.awt.CToolkit$EventQueueExceptionHandler sun.boot.class.path: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsfd.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/sunrsasign.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar sun.boot.library.path: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Libraries sun.cpu.endian: little sun.cpu.isalist: sun.io.unicode.encoding: UnicodeLittle sun.java.launcher: SUN_STANDARD sun.jnu.encoding: MacRoman sun.management.compiler: HotSpot Client Compiler sun.os.patch.level: unknown user.country: US user.language: en user.timezone: America/New_York ===== ===== =====

===== JPen - Status Report ===== JPen Version: 2-091221 Date: Fri Dec 25 21:32:37 EST 2009 Providers: Constructor: JPen Construction Exception: none Device: Emulation (Emulation@JPen) Is Digitizer: false Enabled: false Kind: (type=IGNORE) Constructor: System Construction Exception: none Device: Mouse (Mouse@System) Is Digitizer: false Enabled: true Kind: (type=CURSOR) Constructor: Cocoa Construction Exception: none Native Version-Build(Expected): 2-1(1) Device: Cocoa Cursor (Cocoa Cursor@Cocoa) Is Digitizer: true Enabled: false Kind: (type=CURSOR) Device: Cocoa Stylus (Cocoa Stylus@Cocoa) Is Digitizer: true Enabled: false Kind: (type=STYLUS) Device: Cocoa Eraser (Cocoa Eraser@Cocoa) Is Digitizer: true Enabled: false Kind: (type=ERASER) Device: UNKNOWN (UNKNOWN@Cocoa) Is Digitizer: true Enabled: false Kind: (type=IGNORE) System Properties: apple.awt.graphics.UseQuartz: true awt.nativeDoubleBuffering: true awt.toolkit: apple.awt.CToolkit file.encoding: MacRoman file.encoding.pkg: sun.io file.separator: / ftp.nonProxyHosts: local|*.local|169.254/16|*.169.254/16 gopherProxySet: false http.nonProxyHosts: local|*.local|169.254/16|*.169.254/16 java.awt.graphicsenv: apple.awt.CGraphicsEnvironment java.awt.printerjob: apple.awt.CPrinterJob java.class.path: /Users/karlwillis/Alchemy/Code/svn/Alchemy/lib/jpen/jpen-2.jar java.class.version: 49.0 java.endorsed.dirs: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/endorsed java.ext.dirs: /Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext java.home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java java.runtime.name: Java(TM) 2 Runtime Environment, Standard Edition java.runtime.version: 1.5.0_20-b02-315 java.specification.name: Java Platform API Specification java.specification.vendor: Sun Microsystems Inc. java.specification.version: 1.5 java.vendor: Apple Inc. java.vendor.url: http://www.apple.com/ java.vendor.url.bug: http://bugreport.apple.com/ java.version: 1.5.0_20 java.vm.info: mixed mode, sharing java.vm.name: Java HotSpot(TM) Client VM java.vm.specification.name: Java Virtual Machine Specification java.vm.specification.vendor: Sun Microsystems Inc. java.vm.specification.version: 1.0 java.vm.vendor: Apple Inc. java.vm.version: 1.5.0_20-141 mrj.version: 1050.1.5.0_20-315 os.arch: i386 os.name: Mac OS X os.version: 10.5.8 path.separator: : socksNonProxyHosts: local|*.local|169.254/16|*.169.254/16 sun.arch.data.model: 32 sun.awt.exception.handler: apple.awt.CToolkit$EventQueueExceptionHandler sun.boot.class.path: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsfd.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/sunrsasign.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar sun.boot.library.path: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Libraries sun.cpu.endian: little sun.cpu.isalist: sun.io.unicode.encoding: UnicodeLittle sun.java.launcher: SUN_STANDARD sun.jnu.encoding: MacRoman sun.management.compiler: HotSpot Client Compiler sun.os.patch.level: unknown user.country: US user.language: en user.timezone: America/New_York ===== ===== =====

Hey Karl, There does appear to be a bug switching back to the cursor when using the system mouse, though it correctly switches to CURSOR when I use the tablet mouse. I've committed a (java-source) fix to trunk, if you want to test. However, I'm unable to reproduce your first bug (or misunderstanding). If I launch the app and use my tablet stylus it consistently switches to STYLUS when the cursor enters the drawing area. What are your exact steps (both physical and digital) and expected behavior? Marcello

Thanks for the prompt reply Marcello. I made a video showing what is going on. http://al.chemy.org/misc/jpen-bug.mov (17MB) The expected behaviour is for the demo app to recognise the STYLUS immediately once it enters the drawing area. It can do this, but only after moving the mouse (the separate USB one not the tablet one) or switching the app out of focus then into focus. My tablet is a Wacom Bamboo by the way. I haven't built jpen before so if you have a compiled version handy I'll give it a try (alchemy AT al DOT chemy DOT org). Hope this helps. Karl

That's quite bizarre! Not the behavior I have at all. However, I am using an Intuos2 and Snow Leopard (Mac OS X 10.6.x), so there are two differences that might account for the difference in behavior. I'll do a little investigation and maybe email you a version of jpen with extra logging for you to try out and get some further debugging information... Marcello

Yeah, bizarre isn't it. Not sure if it is related, but using the previous release I get this type of output on a pretty consistant basis: Dec 26 16:23:04 windgap java[15979]: ! Swizzling [NSApplication sendEvent:] Dec 26 16:23:06 windgap java[15979]: *** Assertion failure in -[NSEvent subtype], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSEvent.m:1336 Dec 26 16:23:06 windgap java[15979]: Apple AWT Startup Exception : Invalid message sent to event "NSEvent: type=NSTabletPoint loc=(476,319) time=367062.4 flags=0x100 win=0x0 winNum=44096 ctxt=0x22e83deviceID=0 x=3108 y=4630 z=0 buttons=0x1 pressure=0.041077 tilt={0, 0} rotation=0.000000 tangentialPressure=0.000000 vendor1-3=(0, 0, 0)" Dec 26 16:23:06 windgap java[15979]: Apple AWT Restarting Native Event Thread Dec 26 16:23:32 windgap java[15979]: *** Assertion failure in -[NSEvent subtype], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSEvent.m:1336 Dec 26 16:23:32 windgap java[15979]: Apple AWT Startup Exception : Invalid message sent to event "NSEvent: type=NSTabletPoint loc=(481,185) time=367088.1 flags=0x100 win=0x0 winNum=44096 ctxt=0x22e83deviceID=0 x=3140 y=5995 z=0 buttons=0x1 pressure=0.080232 tilt={0, 0} rotation=0.000000 tangentialPressure=0.000000 vendor1-3=(0, 0, 0)" Dec 26 16:23:32 windgap java[15979]: Apple AWT Restarting Native Event Thread Dec 26 16:23:38 windgap java[15979]: *** Assertion failure in -[NSEvent subtype], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSEvent.m:1336 Dec 26 16:23:38 windgap java[15979]: Apple AWT Startup Exception : Invalid message sent to event "NSEvent: type=NSTabletPoint loc=(419,309) time=367094.6 flags=0x100 win=0x0 winNum=44096 ctxt=0x22e83deviceID=0 x=2822 y=4721 z=0 buttons=0x1 pressure=0.050874 tilt={0, 0} rotation=0.000000 tangentialPressure=0.000000 vendor1-3=(0, 0, 0)" Dec 26 16:23:38 windgap java[15979]: Apple AWT Restarting Native Event Thread Dec 26 16:23:38 windgap java[15979]: *** Assertion failure in -[NSEvent subtype], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSEvent.m:1336 Dec 26 16:23:38 windgap java[15979]: Apple AWT Startup Exception : Invalid message sent to event "NSEvent: type=NSTabletPoint loc=(419,309) time=367094.6 flags=0x100 win=0x0 winNum=44096 ctxt=0x22e83deviceID=0 x=2822 y=4717 z=0 buttons=0x1 pressure=0.086091 tilt={0, 0} rotation=0.000000 tangentialPressure=0.000000 vendor1-3=(0, 0, 0)" Dec 26 16:23:38 windgap java[15979]: Apple AWT Restarting Native Event Thread Swizzling?! Karl

Swizzling is just the technique being used to capture events. (see [jrswizzle][1]) That was just a debug log message, the technique is still being used. The other errors were bugs in the Objective-C code that I've since resolved. I presume you no longer get those messages in the new build? [1]: http://github.com/rentzsch/jrswizzle

I was able to reproduce your other bug. It does not seem to be related to using a system mouse (usb or touchpad), but rather the fact that you start the app with stylus. If I lift the stylus off the tablet, then return back down, the JPen demo starts reporting STYLUS (without moving the system mouse). If I command-tab to another application and back, it correctly determines the stylus regardless of whether the cursor is over the drawing area when switching back. If I start the application with my stylus on the tablet, and then move the system mouse, it continues to say CURSOR. But if I switch applications or remove the stylus from proximity of the tablet and return it, it starts correctly reporting the device. And indeed, the previous release doesn't have this problem, so it's a regression. What happens is if you start the program already using the tablet, it never receives a "tablet entered proximity" event (since it's already in proximity), and thus JPen does not know the current device accurately. In the previous release it used to the knowledge that there was pressure information being reported to determine the user is using a tablet. You will notice, if you start the previous build with the eraser end of your tablet, it will incorrectly report STYLUS as the device type, not ERASER. Marcello

Hi Marcello, Thanks for that, I can confirm the behavior you mention is the same for me. I use the stylus for everything, so it was certainly the case that I was launching the application with the stylus. So what do you think is the solution/workaround? Best, Karl

Hi Marcello, I found another (possibly related) issue with both jpen-2-090914 and jpen-2-091221 releases. penLevelEvent() is not called when drawing to a window that is out of focus/not in front. With the standard mouseListener events, the behavior is to switch the focus to the window then call mousePressed(), mouseDragged() etc... I have made a video demonstrating the problem, and a small application below: http://al.chemy.org/misc/jpen-bug2.mov I would be interested to know how this behaves on Linux/Windows? This may not seem like a big deal, but for interfaces implementing separate toolbars (i.e. to change colors or line thickness - as is the case with Alchemy) the user often returns to draw directly on the canvas. Do you think the problem is Objective-C or Java related? I can assist for any Java related stuff if you point me in the right direction. Thanks for your help, Karl import java.awt.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import jpen.event.*; import jpen.*; import java.awt.geom.*; import javax.swing.*; public class JPenExample extends PenAdapter { private static final long serialVersionUID = 1L; public static void main(String... args) throws Throwable { new JPenExample(); } JFrame frame; JFrame secondFrame; JPanel panel; Dimension windowSize; Graphics2D g2d; Point2D.Float prevLoc = new Point2D.Float();// previous location of cursor Point2D.Float loc = new Point2D.Float();// current location of cursor float brushSize; float opacity; BasicStroke stroke; boolean isDown;// if the pen is boolean keepFocus = true; { secondFrame = new JFrame("Focus-seeker"); secondFrame.setPreferredSize(new Dimension(400, 200)); secondFrame.setLocation(600, 600); JPanel contentPanel = new JPanel(); contentPanel.add(new JTextArea("When clicking on the out-of-focus drawing canvas \n" + "pen events are not reported for the duration of that stroke")); JToggleButton focusButton = new JToggleButton("Keep Focus"); focusButton.setSelected(true); focusButton.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e) { keepFocus = !keepFocus; } }); contentPanel.add(focusButton); secondFrame.setContentPane(contentPanel); windowSize = new Dimension(800, 600); frame = new JFrame("Drawing Surface"); panel = new JPanel(); panel.setBackground(Color.white); panel.setCursor(Cursor.getPredefinedCursor(Cursor.CROSSHAIR_CURSOR)); frame.setContentPane(panel); PenManager pm = new PenManager(panel); pm.pen.addListener(this); frame.setSize(windowSize); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setVisible(true); secondFrame.pack(); secondFrame.setVisible(true); secondFrame.requestFocus(); g2d = (Graphics2D) panel.getGraphics(); g2d.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY); g2d.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE); g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); } @Override public void penButtonEvent(PButtonEvent ev) { isDown = ev.pen.hasPressedButtons(); } @Override public void penLevelEvent(PLevelEvent ev) { if (!ev.isMovement()) { return; } if (ev.pen.getKind() == PKind.valueOf(PKind.Type.CURSOR)) { return; } g2d.setColor(Color.white); g2d.fillRect(0, 5, 155, 35); brushSize = ev.pen.getLevelValue(PLevel.Type.PRESSURE) * 10; opacity = 255 - (ev.pen.getLevelValue(PLevel.Type.PRESSURE) * 255); loc.x = ev.pen.getLevelValue(PLevel.Type.X); loc.y = ev.pen.getLevelValue(PLevel.Type.Y); if (isDown) // if the pen is down - draw { if (ev.pen.getKind() == PKind.valueOf(PKind.Type.STYLUS)) // using the stylus { g2d.setColor(new Color((int) opacity, (int) opacity, (int) opacity, 255)); stroke = new BasicStroke(brushSize, BasicStroke.CAP_ROUND, // round line endings BasicStroke.JOIN_MITER); } else if (ev.pen.getKind() == PKind.valueOf(PKind.Type.ERASER)) { g2d.setColor(Color.white); stroke = new BasicStroke(brushSize * 2); // make it a bit more sensitive } g2d.setStroke(stroke); g2d.draw(new Line2D.Float(prevLoc, loc)); } else { if(keepFocus){ secondFrame.toFront(); } } prevLoc.setLocation(loc); g2d.setColor(Color.black); g2d.drawString(("Brush size: " + brushSize), 5, 20); g2d.drawString(("Opacity: " + opacity), 5, 35); } }

Hi Karl and Marcello, About the last issue, I see that the PenManager pausing method (on jpen.owner.awt.AwtPenOwner) is too aggressive. Let me see what I can do. Cheers! Nicolas

I changed the pause/unpause method and now it works as expected on linux and windows, I didn't test on os x: <br> http://jpen.svn.sourceforge.net/viewvc/jpen/trunk/users/nicarran/product/snapshots/rev-197/jpen-2.jar?revision=198 . <br> it is from trunk/src revision 197, only the jar changed, and includes Marcello's fix "resetting to cursor when tablet stylus is removed".<br> Please let me know if it works right for your use cases. Cheers! Nicolas

Hi Nicolas, Thanks for that. Yes the internal focus bug is resolved on mac. But not when another separate application has focus. Again, this works with the standard mouseListener, so in the best case scenario it should work the same with jpen. I have found another small issue. If I draw a line with the STYLUS, then without moving the mouse (the separate USB one) press the mouse button to start drawing a line, the expected blue line never appears. [http://al.chemy.org/misc/jpen-bug3.mov][1] However, if I draw a line with the STYLUS, then move the mouse, then press the mouse, the blue line appears. In the video you can see that it is registering the button changes, so my guess is it is just a small bug in the demo application. But just to be sure... Marcello, Regarding the mac bug, I can now switch between the STYLUS and the CURSOR ok (with the above exception). However when starting the application with the STYLUS I still have to either move the CURSOR over the drawing area or toggle the focus between applications to activate the STYLUS. Thanks for all your help guys, really appreciated! Karl [1]: http://al.chemy.org/misc/jpen-bug3.mov

> But not when another separate application has focus. Again, this works with the standard mouseListener, so in the best case scenario it should work the same with jpen. Isn't this standard behavior on Mac OS X? My experience has been that you need to activate the application before you can interact with it. Quick test: try to click on a scrollbar on an application that doesn't have focus. You have to click twice before it scrolls. > I have found another small issue. If I draw a line with the STYLUS, then without moving the mouse (the separate USB one) press the mouse button to start drawing a line, the expected blue line never appears. http://al.chemy.org/misc/jpen-bug3.mov However, if I draw a line with the STYLUS, then move the mouse, then press the mouse, the blue line appears. This sounds like a great candidate for "undefined behavior." JPen isn't currently designed with multiple simultaneous inputs in mind, so situations where you are using two different input devices will definitely create unexpected behavior across platforms. Certainly if this is a behavior/scenario you need to support, it would be great to hear a proposal on how it should be handled at an API and behavioral level for future releases to JPen. > However when starting the application with the STYLUS I still have to either move the CURSOR over the drawing area or toggle the focus between applications to activate the STYLUS. I have not found a good solution to this problem (as outlined in my previous post). Moving the cursor should not actually affect the problem. It's when you remove and return the stylus that the problem disappears. Marcello

> Quick test: try to click on a > scrollbar on an application that > doesn't have focus. You have to click > twice before it scrolls. It seems that it depends on the application. Using the Finder scollbars you need to click twice, but Safari scrollbars only once, Java in OSX, only once. Would be interested to see what the behavior is on other platforms. > > This sounds like a great candidate for > "undefined behavior." JPen isn't > currently designed with multiple > simultaneous inputs in mind, so > situations where you are using two > different input devices will > definitely create unexpected behavior > across platforms. This is not so much simultaneous, but rather a sequential switch. At any rate it is not a high priority, I mentioned it because it seemed like a small bug in the demo itself (given the pen events were being reported). > Moving the cursor should not actually > affect the problem. It's when you > remove and return the stylus that the > problem disappears. I see. In this case because the "tablet entered proximity" event is not received, is it better/possible to assume the device is a STYLUS rather than a CURSOR? Or revert to how the previous release handled this situation by looking for pressure data? I'm guessing not to many people will start the app with the ERASER :) Again, thanks for your help! Karl

> It seems that it depends on the application. Using the Finder scollbars you need to click twice, but Safari scrollbars only once, Java in OSX, only once. Interesting. Sounds like Apple is backpedalling... The double-click thing is the standard, and I'm guessing to get the single click behavior some override mode is required. > Would be interested to see what the behavior is on other platforms. I'm pretty sure Mac OS X is the only OS that works like this. > This is not so much simultaneous, but rather a sequential switch. At any rate it is not a high priority, I mentioned it because it seemed like a small bug in the demo itself (given the pen events were being reported). From a user interaction perspective, the user is using two devices at the same time. Obviously from the computer's perspective the events come at separate times, but what should the behavior be when both devices are being moved "simultaneously?" Or what happens if I click both the button on the tablet and the mouse, then release one of them? Obviously there are a multiple ways to solve this problem. The most accurate is probably to treat the events as separate simultaneous streams. > I see. In this case because the "tablet entered proximity" event is not received, is it better/possible to assume the device is a STYLUS rather than a CURSOR? Or revert to how the previous release handled this situation by looking for pressure data? I'm guessing not to many people will start the app with the ERASER :) I certainly can do that (in fact I wrote a quick implementation to test it out), but it's not ideal, since the information about what features a given tablet device supports is missing. I've been experimenting with some sample code, and it looks like it is indeed possible to detect the starting tablet device. The OS probably does send the proximity event at startup, but JPen isn't loaded yet and the event is lost. I'm still looking into it. Marcello

> Obviously there are a multiple ways to > solve this problem. The most accurate > is probably to treat the events as > separate simultaneous streams. Yeah, it is probably not a road we need to go down. If that sort of functionality is required then it would be easy enough to cook up some Java code on the application side implementing both the MouseListener and PenListener. > I certainly can do that (in fact I > wrote a quick implementation to test > it out), but it's not ideal, since the > information about what features a > given tablet device supports is > missing. > > I've been experimenting with some > sample code, and it looks like it is > indeed possible to detect the starting > tablet device. The OS probably does > send the proximity event at startup, > but JPen isn't loaded yet and the > event is lost. I'm still looking into > it. Great! Thanks for the help! Karl

Ok, I've made a little progress. If the jpen native code is loaded *before* the awt libraries, I get the correct behavior: public static void main(String[] args) { CocoaAccess ca = new CocoaAccess() { protected void postProximityEvent(double eventTimeSeconds, int cocoaModifierFlags, int capabilityMask, int deviceID, boolean enteringProximity, int pointingDeviceID, int pointingDeviceSerialNumber, int pointingDeviceType, int systemTabletID, int tabletID, long uniqueID, int vendorID, int vendorPointingDeviceType) { System.out.println("pointDeviceType = " + pointingDeviceType); } // do nothing... protected void postEvent(int type, double eventTimeSeconds, int cocoaModifierFlags, float screenX, float screenY, boolean tabletEvent, int absoluteX, int absoluteY, int absoluteZ, int buttonMask, float pressure, float rotation, float tiltX, float tiltY, float tangentialPressure) { } }; System.loadLibrary("jpen-2-2"); ca.start(); ca.enable(); JFrame frame = new JFrame("HELLO VORLD"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(400,400); frame.setLocationByPlatform(true); frame.setVisible(true); } If I merely move the creation of the JFrame object up two lines above ca.start(), the event is lost: ... System.loadLibrary("jpen-2-2"); JFrame frame = new JFrame("HELLO VORLD"); ca.start(); ca.enable(); ... While this solves the problem for Java applications, it's not great/elegant, plus it doesn't work for Applets (since there's no way to load jpen before jawt). Marcello

> I'm pretty sure Mac OS X is the only OS that works like this. I can confirm that. On windows and linux the jpen demo starts drawing immediately when coming from another active application (at least with my window manager settings). I also observed that when running: import java.awt.event.*; import javax.swing.*; class Test{ public static void main(String... args) { final JFrame f=new JFrame(); final JLabel l=new JLabel("Hello"); MouseMotionListener mouseMotionListener=new MouseMotionAdapter(){ @Override public void mouseDragged(MouseEvent ev){ System.out.println("DRAGGED "+System.currentTimeMillis()); } }; l.addMouseMotionListener(mouseMotionListener); MouseListener mouseListener=new MouseAdapter(){ @Override public void mouseReleased(MouseEvent ev){ System.out.println("RELEASED"); } }; l.addMouseListener(mouseListener); f.add(l); f.pack(); f.setVisible(true); } } on linux you can click and drag the pointer outside the window and then switch to another application and you still get the mouseDragged/mouseReleased calls. But on windows when you do the same operation, once you switch to other application it stops calling mouseDragged and even worse it never calls mouseReleased leaving the java application with the mouse button pressed :-( . As jpen critically relies on when to stop a drag operation to ungrab the tablet device (and let other applications receive tablet data), I decided to make jpen stop sending PenEvents (also releasing pressed buttons) when the jpen application gets completely deactivated (none of its windows are active). Then with the current implementation we have the same behavior on all supported platforms at the cost of that extra flexibility (we won't have events when dragging after switching apps). > but what should the behavior be when both devices are being moved "simultaneously?" Looking first at what I think is happening in this case.... jpen takes the pen kind from the device being moved. If the you press the left mouse button without moving the mouse, then you are "still using" the STYLUS and the emulated level event is not configured to be fired when STYLUS is selected. On top of that, on os x it appears to be that right after pushing the mouse button the cocoa provider starts sending mouse movement (instead of tablet stylus movements, as the video shows integer x and y levels) causing the pen kind to be changed from STYLUS to CURSOR (but too late to cause an emulated pressure event, so there is no blue line, and we must stay in wonderland). We could define jpen as mouse pointer driven: what move the pointer in the most accurate way is what is reported by JPen... Then if we accept this rigorously, we can say that what is happening (above) is a bug but not because the pressure is not being emulated (blue line) but instead because when the mouse button is pressed and the stylus is moved, the most accurate device is the stylus and then jpen must report the stylus data and not mouse data (the expected behavior would be to continue drawing in black STYLUS with variable width, floating point precision x and y, and report the LEFT button pressed event... this is actually what jpen does on linux and windows in such case). But I think that this "bug" is currently unavoidable because that is what cocoa is reporting. Of course... I could have been misinterpreting the video. > Or what happens if I click both the button on the tablet and the mouse, then release one of them? The current policy is to take into account only the first hardware button press and the last hardware button release of a given type. But this is still work in progress... is sane to leave it undefined until tablet buttons are supported. Nicolas

Marcello, Nice work. But I guess as you say it is more of a work around. I'm wondering if there is a way to query the tablet device directly? As this is only a once-in-an-application-lifecycle case, would that work? Nicolas, Regarding the out of focus behavior, I agree, having consistency across applications is the priority. > jpen takes the pen kind from the > device being moved I think this is not enough. In my mind the pen kind should also be set by buttons/presses as well as movement. I don't think it is necessary to accommodate any simultaneous usage scenario, but it should switch between the two cleanly. > when the mouse button is pressed and > the stylus is moved In this case the mouse button would create a single blue dot, then the stylus would create black dots. I think it is important to tie together where the event came from so that these edge cases can be handled intelligently on the application side. Thanks guys for all the good work. Karl

>Nice work. But I guess as you say it is more of a work around. I'm wondering if there is a way to query the tablet device directly? As this is only a once-in-an-application-lifecycle case, would that work? You're exactly right. I found some code in Wacom's documentation ([page 25 of this .doc][1]) that actually allows you to re-request the last proximity event. It solves the problem, but this code is Wacom-specific, and it's unclear that it will help non-Wacom devices. Marcello [1]: http://www.wacomeng.com/devsupport/downloads/mac/macosx/EN0056-NxtGenImpGuideX.doc

Nice work! That looks like a viable option! To be honest, until you mentioned it just now I didn't even consciously realise that the JPen code-base was not wacom-specific. Well that is cool. I guess the issue is not people not using wacoms (because they are common), but people not installing the wacom driver and using the default Apple driver right? The only other thought would be to somehow store that first tablet event somehow and query it later. But I guess that comes back to the issue of library load order... Karl

I've just been looking around in the OS X documentation. You will have to excuse my ignorance of all things objective-c, but would this be useful? [nextEventMatchingMask][1] [1]: http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#//apple_ref/occ/instm/NSApplication/nextEventMatchingMask:untilDate:inMode:dequeue:

That unfortunately doesn't help since it's for capturing events that have yet to happen, rather than re-executing events that happened in the past. I just committed my changes ([rev 199][1]) which uses the Wacom command to re-execute the last proximity event at JPen start combined with the hack of assuming a stylus when receiving tablet events but the current device is cursor. Marcello [1]: http://jpen.svn.sourceforge.net/viewvc/jpen?view=rev&revision=199

hey Marcello, nice! tomorrow I will publish a new release... I see that the new osx libjpen is incompatible with the previous... I will change its version to 3 (libjpen-2-3.jnilib). good night, Nicolas