justinfrankel / WDL

WDL (by Cockos) mirror
http://www.cockos.com/wdl
425 stars 57 forks source link

Consider refactoring GDK global event handler #24

Open agoschie opened 1 month ago

agoschie commented 1 month ago

First off, I want to say I am a huge fan of your work. I love Reaper, and its great to see how a custom library like WDL made it possible.

The GDK global event handler appears to be being used as a global event translator for swell, correct? An issue may arise when a SWELL based callback wishes to filter events, but the messages are getting translated then being sent to them, so they might not be able to identify the messages. For example, a GDK touch begin message gets translated to a WM_LBUTTONDOWN, but there is no SWELL implementation of GetMessageExtraInfo/SetMessageExtraInfo (https://learn.microsoft.com/en-us/windows/win32/wintouch/troubleshooting-applications?redirectedfrom=MSDN).

SOLUTION: Implement GetMessageExtraInfo/SetMessageExtraInfo in SWELL, such that a thread specific global variable is set with the current events extra info. For example, touch messages could set a flag 0xFF515700 in the thread specific global variable like in the troubleshooting documentation listed above. Furthermore, the rest of the code base is not affected so anything that depends on the WDL library wont be affected.

agoschie commented 1 month ago

Furthermore, the Reaper SDK could be updated with internally linked definitions of the respective functions above.

cfillion commented 1 month ago

There is SWELL_GetOSEvent("GdkEvent") for obtaining the original GDK event that triggered a SWELL message. It's available since REAPER 6.57.

https://github.com/cfillion/reaimgui/blob/24b51618dffb0cdfd5b405c265b38f11110b9917/src/gdk_window.cpp#L39

agoschie commented 1 month ago

The issue is its only internally linked and not forwarded to through the Reaper SDK, unless I am wrong on that.

A more SWELL solution (pardon the pun) is implement GetMessageExtraInfo/SetMessageExtraInfo with extern "C", and you can then use RTLD_DEFAULT with dlsym for the linux/gdk implemenation to check the existence of an already existing SWELL_GetMessageExtraInfo/SWELL_SetMessageExtraInfo. That way you can be sure your accessing the executables message queue.

Obviously, it exposes more information shared libraries, and if SWELL is not intending to do that, its a change in the opposite direction.

cfillion commented 1 month ago

It's exposed the same way as every other SWELL functions. Just a function pointer populated by the modstub. If you've got SWELL working in your extension (using REAPER's SWELL, not statically compiling a second copy) you already have SWELL_GetOSEvent from swell.h ready to be used.

agoschie commented 1 month ago

Is libSwell.so under a different license to the Reaper binary?

Edit: If it is, I guess that solves that. Although, since SWELL appears to be made for win32 emulation, it might make more sense to eventually get the discussed functions implemented at some point.

agoschie commented 1 month ago

Anyway, I thank everyone for the help!