STR #3329

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3329

Application:FLTK Library
Status:5 - New
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Support for tablet features (pen pressure, tilt, etc)
Created By:greg.ercolano
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 greg.ercolano
16:01 Sep 20, 2016
#2 greg.ercolano
19:52 Sep 20, 2016
#3 greg.ercolano
07:05 Sep 21, 2016
#4 manolo
04:49 Sep 22, 2016
#5 manolo
22:36 Oct 07, 2016
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 greg.ercolano
11:32 Sep 20, 2016
Would like there to be an FLTK way to access things like
pen pressure and tilt. This would allow FLTK to be used for
drawing/painting applications.

I'll probably be suggesting a patch for OSX, as I'm actively
developing such an app.

Should be minimal additions to and the Fl class.
I expect to implement as an ABI feature, since adding this info
necessarily would enlarge class 'Fl' to manage the extra values.
#2 greg.ercolano
16:01 Sep 20, 2016
Attaching initial patch suggestion, showing the general direction
of implementation.

Manolo: would like if you could give it a once over.
Seems straight forward enough, but would still like your blessing.

Should maybe hold for 1.4, but unless I'm missing something, seems
like it can be added easily enough to both 1.3 and 1.3 porting.

Caveats for v1 patch:
    To use, ABI must be set to 10304.

    Tested with my Wacom Intuos2 USB tablet + OSX 10.7.5.

    Need to do a cleanup pass to remove some personal
    comment markers and debug code.

    Apple says some constants I'm using (pen type) is deprecated
    in 10.12.. will probably need some #ifdef's to handle that.

    Did not test if apply patch breaks non-10304 ABI build..
    didn't get that far in testing; mainly focused on getting
    the code to work.

    Haven't tried compiling on older and newer OSX machines..
    will try that next.

    I think there's limits on tablet support for some of the older
    OSX releases (which we may not support anymore anyway)
#3 greg.ercolano
19:52 Sep 20, 2016
Posting v2 patch.

    1) Combined the two tablet events:


       ..into a single FL_TABLET_PROXIMITY event. App can check the proximity flag
       to determine which happened.

    2) Modified example/tablet-test.cxx program accordingly

    3) FL_PUSH/DRAG/RELEASE documents new valid tablet values that can be read.

The tablet API as it stands in v2 patch:

    The user's application doesn't have to do any initialization steps
    to read the tablet. Tablet data is just available if the app wants it.

    If a tablet is present and app wants to read its special values:

    A) The handle() method can check for FL_PUSH/RELEASE/DRAG events
       and access the tablet's extra data with these new Fl:: methods:

        Fl::tablet_pen_tilt_x()   -- pen tilt as signed 0.0 - 1.0 values.
        Fl::tablet_pen_tilt_y()      Sign indicates left/right and up/down orientations.

        Fl::tablet_pen_pressure() -- pressure on pen (0.0 - 1.0 floating value)

        Fl::tablet_pen_rotation() -- pen's rotational orientation (in floating degrees, 0 - 360.0)

        Fl::tablet_pen_eraser()   -- returns 1 if the eraser end of pen is down, 0 otherwise

        Fl::tablet_pen_type()     -- returns 0 if cursor, 1 if pen, 2 if eraser, -1 if unknown

        Fl::tablet_pen_tangential_pressure() -- pen barrel pressure or pressure wheel

    B) The app's handle() method can optionally look for these two new FLTK events:

           FL_TABLET  -- tablet specific events that are unlike a mouse
                         (such as changing the pressure without changing the position)

           FL_TABLET_PROXIMITY -- if the app cares about the tablet's pen hovering
                                  near the tablet. Fl::tablet_proximity() is 1 if
                                  entering tablet's range, 0 if leaving tablet's range.

       Apps wanting to detect pressure changes without movement should watch for
       FL_TABLET. Apps caring about pen hovering should detect FL_TABLET_PROXIMITY.
       A paint app could work fine without checking for either of these two events.        

See the examples/tablet-test.cxx in the patch.

Arguably, I should provide a way for the app to "turn on" tablet events,
so FLTK won't have to bother delivering tablet events to an app that doesn't care.

For instance, whenever the tablet button is clicked, potentially dozens of pen
pressure change events (as FL_TABLET events) are delivered. A non-tablet app
would simply receive (and ignore) these events. But I think we (me and Albrecht)
found event delivery can be more effort for FLTK than one might think. (widget
hierarchy traversal).

If that's a problem, perhaps something like Fl::tablet(1|0) could be useful,
so an app can enable/disable tablet event hooks in main().

Not sure how to do this under OSX though; my understanding is event hooks in OSX
are implemented as method overrides, so I'm not sure how to conditionalize method
overrides at runtime. I'll bet ObjectiveC has a way to do this though.. I just don't know it.

Anyway, curious for opinions.
#4 greg.ercolano
07:05 Sep 21, 2016
Updating the v2 patch: tablet_v2a.patch.

No functional changes, just updated to work for svn current.
(manolo made some small tweaks to today that
caused the older v2 patch to no longer apply)
#5 manolo
04:50 Sep 22, 2016
FLTK is at present upward and downward compatible between
Mac OS 10.3 and 10.12. That is, it's possible to compile
on a new mac and run the exe on an old one, and vice versa.
I believe it's important to keep that.

Thus, one has to carefully check for what OS versions each symbol is valid,
and to protect the use of this symbol as follows. I suppose here
symbol is a message known to the NSEvent class, but any symbol must be protected similarly.
Let's suppose symbol appeared in Mac OS 10.10 :

  if (fl_mac_os_version >= 101000) [theEvent symbol];

this way the new symbol is compiled only with SDK ≥ 10.10, and is executed
at runtime only if OS 10.10 or more is running.

I have noted all symbols that are newer than Mac OS 10.3 in the attached
new version of the tablet patch. Each has to be protected as described.
The patch involves symbols valid after Mac OS 10.4, and others after 10.10.
Other symbols have changed names in 10.12.

About how to process tablet-related events only when a feature is turned on,
I see 2 solutions, supposing that Fl::using_tablet() returns true when useful :

- (void)tabletProximity:(NSEvent *)theEvent {
  if (Fl::using_tablet()) cocoaMouseHandler(theEvent);
and similar for tabletPoint.

define a new, derived class

@interface FLView_Tablet : FLView
- (void)tabletProximity:(NSEvent *)theEvent;
- (void)tabletPoint:(NSEvent *)theEvent;

@implementation FLView_Tablet
- (void)tabletProximity:(NSEvent *)theEvent {
- (void)tabletPoint:(NSEvent *)theEvent {

and don't implement tabletProximity and tabletPoint in class FLView.

and in the Fl_X::make() function, replace
    FLView *myview = [[FLView alloc] initWithFrame:crect];
    FLView *myview = Fl::using_tablet() ? [FLView_Tablet alloc] : [FLView alloc];
    myview = [myview initWithFrame:crect];
This way, the myview object will respond to tablet events only if Fl::using_tablet()
returned true when the window was created.
Thus, tablet events could be turned
on or off on a single window basis, if practical.
#6 manolo
22:38 Oct 07, 2016
Attached file tablet_V4.patch is the same as tablet_v3.patch
but with all guards to make it upward and downward
compilable and executable across Mac OS X versions.
#7 greg.ercolano
12:59 Oct 08, 2016
Ah, thanks Manolo.

So is there confidence that this can be committed to svn current,
or should I maybe #ifdef it out with e.g. #ifdef OSX_TABLET
so that it wouldn't be built by default, only if that macro is set.

I can handle the double commit to 1.3 and 1.3-porting.

Would just like to get the code in there so that it can be
tested and used by others who use tablets and such.

Esp. curious if this patch helps people with touch sensitive
displays, which maybe use the same techniques.

I'll maybe ask the devs what they think before a commit.
#8 greg.ercolano
13:05 Oct 08, 2016
Oh, I forgot, I need to take a pass at making this an optional feature
via the API.

So Manolo, I'll start with your V4 and implement around that,
and once tested, I'll bounce it off the devs for a possible commit.
#9 matt
07:05 Feb 05, 2019
Did this ever come to life? I would love to see that feature and I would port it to Android (if the API exists yet).  
#10 greg.ercolano
09:41 Feb 05, 2019
I think the only thing left incomplete was designing the API to allow
turning this feature on and off, as necessarily when enabled this
delivers a /lot/ of events that many apps won't want to see.

I wasn't sure weather to implement the option using Fl::option():

    Fl::option(OPTION_TABLET_EVENTS, on|off)

..or with a separate method call that allows for other optional data
besides just an on|off flag, e.g.

    Fl::tablet_events(bool flag)                // simple on/off flag
    Fl::tablet_events(bool flag, void *data)    // ioctl(2) style options

And perhaps too, this should manage touch screen options, either
with the same API (e.g. OPTION_TOUCHSCREEN_EVENTS), or a separate one
(e.g. Fl::touchscreen_events(bool flag, void *data)..)

The reason for void* is to allow for a possible structure argument,
vis a vis unix ioctl(2) API style.. though perhaps that's unnecessary..
I'm not sure how many options we might need to manage event control.

Whatever we come up with it would hopefully be 'easy to remember'.

If we go the Fl::option() route, perhaps that API can be expanded a bit
to allow for generalized optional data, besides just a bool, e.g.

    Fl::option(option, bool flag)    // on|off
    Fl::option(option, void *data)   // NEW: optional data can be NULL or a struct*, int, etc.

#11 greg.ercolano
09:45 Feb 05, 2019
And I should add I'm not familiar enough with other APIs
for touch screens + tablets to know what the most forward thinking
way to implement the option control is.

Maybe you guys are more familiar with what options might be needed
to control this stuff as these devices become more and more complex
(multi-finger gestures, two handed game like devices for virtual
reality, etc etc)

Also, in comment #10 s/weather/whether/ lol.
#12 greg.ercolano
07:56 Aug 12, 2020
Just adding a note here: need input from devs on the above items.
Also, for this to be applied to 1.4.x, this /may/ need some tweaks
in light of the new 'driver' system.. not sure.
#13 AlbrechtS
06:27 Aug 17, 2020
I don't have a tablet device and I don't have macOS, but I'm trying to give some input on the open questions.

1) This feature should only be applied to 1.4, hence the ABI guards can be removed, but the patch should be applicable to 1.4. Just a note, didn't test, but I'd *guess* that the patch couldn't be applied cleanly to 1.4.

2) I saw notes by Manolo regarding name changes of constants in later macOS versions. This should be addressed.

3) As for a switch to turn this feature on and off:
3a) I think such a switch would be essential.
3b) I suggest to set the default to OFF (0) so users must explicitly enable it.
3c) I think we shouldn't use Fl::option() for this. I like the idea to have one or more Fl::tablet_*() methods so we are free with function arguments. Maybe we need more methods later.
3d) Another implementation option would be an Fl_Tablet class with (presumably, for now) only static methods.

4) Regarding "tweaks in light of the new 'driver' system": I looked at the patch and I don't think that there would be much to do WRT the new driver system. OS event handling is in separate code parts anyway.

5) I'd like to see such features on other platforms as well, but I don't know if there's somebody who can implement it. :-(

Something I thought about: what if a user has two (or more) tablets connected. How would someone distinguish events from one or the other tablet device?
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.