How to block only certain global hotkeys?

[Duncan]

Aleksey Midenkov posted on Fri, 15 May 2015 11:54:40 +0300 as excerpted:

> I see that sxhkd is more sophisticated than xbindkeys. Though, it have
> no official packaging yet. What are advantages over xbindkeys? The only
> issue with xbindkeys I encountered is that it doesn't send fake
> KeyRelease events for its hotkeys, so you have to do it manually in
> order to send another keypress:

tl;dr: Due to its guile scriptability, xbindkeys has a steep initial 
learning curve (beyond the guileless real simple stuff) unless you 
already know guile, but that should translate into extreme flexibility as 
well, once you're over that initial hump.

So assuming you're over that hump, you're probably best off sticking with 
it.

But for those who don't know guile, sxhkd will provide most of the 
functionality, I'd guess all of it with other tools and possibly a bit of 
shell scripting thrown in as well, without having to learn the after all 
rather obscure guile.


Now "the scenic route". =:^)

I've almost setup xbindkeys a couple times, but never quite got into it.

Back when kde4 was new and kde3 support was dropping off the planet, I 
needed some way to continue chaining hotkeys, as I had with khotkeys3 but 
which broke with khotkeys4.  I looked at several options including 
xbindkeys, which was one of the only options that actually allowed hotkey 
chaining, which I considered a pretty hard requirement at the time.  So I 
dove in and started experimenting.

But I had a whole stack of stuff on my plate at the time, as I had pretty 
much standardized on kde3 solutions, and the kde4 versions of many of 
them were still simply... broken... while kde3 support was, as I said, 
dropping off the planet.

Unfortunately, xbindkeys' advanced functionality, which I would have 
certainly used, is configured/programmed in guile, which I don't know, 
and while I actually settled down to start learning it as I didn't see 
much choice given khotkeys4 breakage and the lack of other alternatives, 
given the stack of kde4 switching tasks I had on my plate, I definitely 
preferred to avoid it if possible.

As it happened, after spending a couple hours on guile, I got sleepy and 
decided to sleep on it.

I woke up with a critical insight, triggered by how I'd seen the xbindkeys 
guile configuration handling those chained hotkeys:  What I had been 
doing in kde3 hotkeys was setting up several chained hotkeys with the 
same initial keystroke.  Instead of considering each chain its own 
individual command as the khotkeys3 configuration had encouraged me to 
do, xbindkeys, via guile, was actually handling it differently.

What xbindkeys/guile was actually doing was considering each event in the 
chain its own command, and chaining /them/ together to effect a chained 
sequence.

My insight as I woke up was that I could do the exact same thing, using 
knowledge and tools already at my disposal.  In particular, what I needed 
was a single initial hotkey, with a command that simply popped up a menu 
of all the second-stage keys configured under the primary.  Hitting the 
second-stage key could then either run the actual intended command, or 
popup another, third-stage menu.

And while setting up a popup menu like that would have been easier and 
more X-like/kde-like if I knew and could actually program it in C++ or 
even python, I could actually do /most/ of it in bash shell, which I 
*DID* know! =:^)

So I dropped learning guile for xbindkeys, and started hacking up a 
solution using bash scripting, calling various tools as I needed them.  
What I ended up with, was an initial single-key trigger configured in 
khotkeys4 (single-key hotkeys, with or without modifiers, it could still 
handle), that ran a script that popped up a konsole window, which 
displayed lines from a menu config file.  I used the bash read builtin to 
wait for exactly one key (possibly with shift and/or ctrl as modifiers), 
which was matched against a line in the menu config file to determine 
what command to run.

What was nice was that a command could invoke the same program again, 
with a different menu, thus letting me chain as many levels deep as I 
wanted.

So my initial menu has a bunch of entries: g(ames) c(onfig) a(pps) w(eb), 
p(ower), etc, invoked with a simple g/c/a/w/p, respectively.  That in 
turn pops up the appropriate category menu, games on the games menu, 
various config options on the config menu, etc.  One of the config 
commands is h(otkeys), which for that specific one, pops up a third 
level, which lets me choose which hotkey config file I want to edit.

The end result is that for instance <launcher>, w, K, selects web, gentoo-
bugzilla, which opens up that page in my web browser (firefox), while 
<launcher>, g, p, runs games, patience (kpat), and <launcher>, c, h, w, 
selects config, hotkeys, web, loading the web hotkey file in my editor of 
choice (mcedit in konsole).

This multiplexing lets me overload a single launcher key such that I can 
launch any number of apps/commands from it, just as I used to do with 
khotkeys3. =:^)

What's really good about it, however, is that now I can use pretty much 
any generic single-key hotkey app for the initial trigger, as all it does 
is launch my own custom menu-launcher second stage.  KDE can never break 
khotkeys and leave me high and dry again, as I can switch to whatever 
else (including xbindkeys if desired, with just the simple no-guile config 
if I still don't want to learn guile) with little trouble.

Actually, the end result of the whole kde4 fiasco was that I depend on kde 
for very little any more.  I still run it as my core desktop, but other 
than the desktop (plasma) itself, kwin, and a few games, I'm no longer 
really tied to kde.  And switching them out too will be far easier than 
all the switching I had to do when kde3 support dropped and I had to 
switch to a still very broken kde4!

Which is exactly what I might find myself doing, if it turns out semantic-
desktop is no longer optional in kde5.  Time will tell...


But back on the xbindkeys topic...

I considered xbindkeys again when I got the new touchpad, decided the 
xorg synaptics input driver didn't recognize enough multitouch gestures, 
and switched to the xorg mtrack input driver.

Mtrack recognizes and converts to "mouse button" events twenty different 
gestures (1-4 finger "clicks" = 4, 2-4 finger swipes in four directions, 
up/down/left/right = 3*4 = 12, two-finger pinch-zoom in/out = 2, two-
finger rotate left/right = 2, 4+12+2+2 = 20).

Unfortunately, few apps recognize more than the standard three buttons, 
plus four more as vert (4,5) and horiz (6,7) scroll.  So some way to 
convert the other 13 "buttons" to something useful is needed.  Which is 
where something like xbindkeys or sxhkd comes in.

But... looking at the xbindkeys documentation, I didn't see anything 
saying how many mouse "buttons" it recognized, and the examples only 
showed it using the standard three. =:^(

Of course I could have installed it and tried, but I didn't need to, as 
sxhkd's documentation said in an easily found description (and in the 
manpage) that it handled 24 "mouse buttons". =:^)


Besides which, I /still/ haven't learned guile.


So bottom line, if I had actually continued with xbindkeys the first time 
and learned guile, I'd have very likely known how many mouse buttons it 
supported, and if not, it would have already been installed and 
configured, so experimenting to find out would have been easy, as it 
would have been a familiar tool already.

But as I never tried it other than the initial experimentation and a 
couple hours learning guile to program it, sxhkd was simply easier.

And sxhkd does work very well doing what it says on the tin. =:^)

So if you're already familiar with xbindkeys, including knowing guile so 
you can program its advanced functionality, I'd say stay with it.  Guile 
for scripting means a steeper learning curve but it should also mean it's 
extremely flexible, likely more so that pretty much anything else 
including sxhkd.  So if you're over that initial learning curve, there 
really isn't that much reason to change.

Tho I still don't know how many mouse buttons xbindkeys can handle.  If 
it's limited to 3/5/7, as many tools seem to be, sxhkd has the advantage 
if you end up with either a very fancy mouse or a touchpad with a bunch 
of gestures converted to mouse button events above button 7.  I /suspect/ 
with its programmable flexibility, xbindkeys probably handles as many 
mouse buttons as the driver or X can throw at it, but I don't /know/ 
that, and not knowing either that or guile, it was simply easier to go 
with sxhkd.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.