STR #2179: Allow receiving events before FLTK handles them

STR #2179

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	1 - Request for Enhancement, e.g. asking for a feature
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Allow receiving events before FLTK handles them
Version:	1.4-feature
Created By:	sanel.z
Assigned To:	AlbrechtS
Fix Version:	1.3.3 (SVN: v10310)
Fix Commit:	e145df21652a643c358afabe979cdca8e0c55429
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	sanel.z 04:49 Mar 22, 2009

Currently there is no way to receive OS (in this case X11) events before FLTK handles them. The only way is to use Fl::add_handler() and received events will be after FLTK manage them. Some events, like SelectionClear (SelectionClear is used by XSETTINGS protocol and EDE uses it) are discarded, so the only way to catch it is to watch fl_xevent changes; not very safe due X11 async nature of events reports. Also, without getting events before FLTK, there is no way to receive e.g. DamageNotify events in the sane way (they are used by composite managers). The only way to make it work is to re-implelemnt FLTK loop (using Fl::add_fd()) in user application. There are much more examples, and IMHO, a lot of flexibility would be gained, especially for FLTK's advanced uses beyond OS specific wrapper.

#2	AlbrechtS 06:03 Mar 22, 2009

Recently I thought about another usage case that needs to process events before FLTK would even try to do it. A TWAIN scanner driver (e.g. in Windows: a dynamically loaded dll) would require some kind of handler being called _before_ FLTK uses the event. The logic is that this handler would decide, if *it* uses the event. It then returns a value (0 or 1), similar like in FLTK's logic, if it used the event or not, and FLTK would only process events that the scanner driver did not use. TWAIN 2.0 is currently available for Windows and Mac OS X, but maybe only Windows would need such an event processing hook - maybe). Details can be read in [1], chapter 3. Maybe we could call such a function Fl::add_event_filter(), and the event filter (handler) would return 1 if it used the event, and 0 if not. Under Windows this event filter would have to be called after GetMessage (or PeekMessage), but before TranslateMessage and DispatchMessage. ----- [1] http://www.twain.org/docs/TWAIN_2_Spec.pdf

#3	fabien 11:36 Mar 24, 2009

It indeed makes sense to me than for every platform, one should be able to intercept any event _before_ fltk does. I thought that Fl::add_handler() would suffice for that. If we can confirm that some events are disgarded not only for FLTK but also for the custom event handlers ; then I would tend to think it's a bug and we should fix that ASAP. In other words, I think we should be able to intercept with Fl::add_handler() all events.

#4	sanel.z 03:06 Mar 25, 2009

> I think we should be able to intercept with Fl::add_handler() all events With Fl::add_handler() user will receive events after FLTK, which is perfectly fine. There just have to be another function (e.g. Fl::add_event_filter()) that will send events before FLTK. Both are needed :) (or add_handler() could have two parameters; one for before FLTK handles them, one for after FLTK handles them) > If we can confirm that some events are disgarded not only for FLTK but also for the custom event handlers ; then I would tend to think it's a bug and we should fix that ASAP. Please check fl_handle() implementation in Fl_x.cxx; you will see how not all events are routed to the add_handler() callback.

#5	matt 03:24 Mar 25, 2009

I can see where this function is needed. I doubt though that there is a simploe solution for all platforms. OS X for example has tons of events that must be registered first which is something that FLTK will not cover. I would suggest that we add an argument to add_handler that determines if that specific handler gets added before or after FLTK event handling. That way, we can extend the function even further (if additional requests should come up) without adding yet another function to FL.

#6	matt 03:26 Mar 25, 2009

Example: Fl::add_handler(myHandler, FL_HANDLE_BEFORE_FLTK); or Fl::add_handler(myHandler, FL_HANDLE_AFTER_FLTK); with the obvious default

#7	AlbrechtS 14:26 Mar 25, 2009

> Fl::add_handler(myHandler, FL_HANDLE_BEFORE_FLTK); +1, this is probably better than my idea Fl::add_event_filter. There is also the very much related STR #2177 (adding a void * parameter to the callback). This could be achieved by an overloaded method, maybe Fl::add_handler(myHandler, void *my_arg, int flag=FL_HANDLE_AFTER_FLTK) or similar. This would set another bit in the internal handler structure such that it would call the handler function with the additional void * argument. Or similar ...

#8	AlbrechtS 14:30 Mar 25, 2009

Regarding OS X: I saw the problem you (Matt) mentioned, when I looked in the code. We could document: "FLTK registers the following events: <enumeration of FLTK-registered events>. You can request to get these in your handler function. For all other events you're on your own." How does this sound?

#9	matt 22:59 Mar 25, 2009

Yes, I uess that is a start. I'll have to figure out a way for the OS X user to know which events were requested by FLTK and which were not... .

#10	sanel.z 10:11 Mar 26, 2009

> There is also the very much related STR #2177 Thank you for mentioning it :) > Fl::add_handler(myHandler, void *my_arg, int flag=FL_HANDLE_AFTER_FLTK) If my vote counts, then definitely +1 for this :)

#11	AlbrechtS 18:14 Jan 15, 2023

Fixed in Git repository. This feature was added in FLTK 1.3.3 (Sep 15, 2014) in git commit e145df21652a643c358afabe979cdca8e0c55429: See documentation of Fl::add_system_handler(): https://www.fltk.org/doc-1.3/group__fl__events.html#gad87427a41cb546d97236c244abaff8bd