| | [ 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) |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #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 Fl_cocoa.mm 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:
FL_TABLET_PROXIMITY_ENTER
FL_TABLET_PROXIMITY_LEAVE
..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 Fl_cocoa.mm 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 MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_10
if (fl_mac_os_version >= 101000) [theEvent symbol];
#endif
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 :
1)
- (void)tabletProximity:(NSEvent *)theEvent {
if (Fl::using_tablet()) cocoaMouseHandler(theEvent);
}
and similar for tabletPoint.
2)
define a new, derived class
@interface FLView_Tablet : FLView
- (void)tabletProximity:(NSEvent *)theEvent;
- (void)tabletPoint:(NSEvent *)theEvent;
@end
@implementation FLView_Tablet
- (void)tabletProximity:(NSEvent *)theEvent {
cocoaMouseHandler(theEvent);
}
- (void)tabletPoint:(NSEvent *)theEvent {
cocoaMouseHandler(theEvent);
}
@end
and don't implement tabletProximity and tabletPoint in class FLView.
and in the Fl_X::make() function, replace
FLView *myview = [[FLView alloc] initWithFrame:crect];
by
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.
Anyway.. | |
| |
| #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? | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
