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.
