You are not logged in.
Heavily edited, mostly re-written on 2017-04-01.
I looked at xfwm4 event handling a bit. The code is "interesting". Someone has previously added a few lines which attempt to perform certain actions upon occurrences of "Button8" and "Button9". But events with those button numbers absolutely, positively cannot be received by this program. Wrong, those actions do work, because of xlib 'core event' button number assignments. These "buttons" line within the range of visible button values, and the code works.
(Rewritten TWICE on2017-04-01)
xfwm4 is using original xlib - WITHOUT the 'XInput2' extension. The single biggest defect in original 'xinput' event design was the use of a single-byte mouse event data fields for button state and 'responsible button', these fields didn't have enough bits to work with any high-numbered buttons. The xorg guys invented extension 'xinput1' to solve that problem, and subsequently created 'xinput2' to solve related problems (multi-pointer, unlimited buttons, and devices with 'location' and 'movement' occurring in more than 2 dimensions) AND unrelated problems (extended UTF character sets in keyboard events). Basically, in XI-2 the length of data associated with an 'event' can be extended by a variable length "cookie", which can be as long as needed to work with the device.
In order to do this enhancement with *genuine* mouse buttons, we would need to build and run using one of the extensions (xinput, or xinput2). I'm proposing that we do it only within xfwm4, and avoid delivering high-numbered mouse button events into application Windows which are expecting "legacy" 2-byte mouse event signatures. So, unfortunately, high-numbered buttons (and button combinations with modifier keys) will only effect desktop switching, window placement, and similar things - not actually getting "into" applications. Major Correction: Not so - we can act on XI-2 button input events as if they were core events, merely with higher button numbers. Applications (e.g., and 'xev' test window) can still receive anything which we didn't act upon and "consume".
Is anyone interested in this sort of stuff? If so, what kind of "features" would you all like to see using higher numbered buttons, or buttons combined with single held "modifier keys" on the keyboard?
Last edited by rickst29 (2017-04-02 06:03:19)
Offline
As Xfce is currently being ported to GTK3 I would these sort of changes would happen as part of the porting. It looks like the work hasn't started on xfwm4 yet - https://wiki.xfce.org/releng/4.14/roadmap
Offline
As Xfce is currently being ported to GTK3 I would these sort of changes would happen as part of the porting. It looks like the work hasn't started on xfwm4 yet - https://wiki.xfce.org/releng/4.14/roadmap
Most of the event code in xfwm4 works directly with xlib (and that's also true of the program as a whole). It's use of GTK/GDK "toolkit" objects and functions is minimal. IIUC, rewriting it all to 'go through' such structures and functions would be a massive effort, and would significantly hurt response time and efficiency (CPU) by adding lots of new layers.
Wow. I just edited this message to delete several 'bad' paragraphs (from 9 hours ago) full of worrisome talk about how "hard it would be to use XI-2".
When I actually tried it.... I imported the header. And proceeded to write some 'else if' code blocks like this one:
else if (ev->button == Button13) // workspace 'hop forward' by two
{
workspaceSwitch (screen_info, screen_info->current_ws + 2, NULL, TRUE, ev->time);
}
And they ALL work, without any other changes
Last edited by rickst29 (2017-04-02 05:55:32)
Offline
Really, the only remaining questions are: (1) What 'actions' do we want all these new buttons to perform; and (2) Should they be configurable, rather than hard-coded?
Offline
[ Generated in 0.007 seconds, 7 queries executed - Memory usage: 533.33 KiB (Peak: 534.17 KiB) ]