Stephen Dowdy posted on Wed, 28 Dec 2016 14:54:54 -0700 as excerpted:
> Michael,
>
> I don't know the current state of KDE applications, but at least on
> Debian Stable, there's a plasma applet called 'paste' that lets you
> paste snippets.
Does Debian stable use frameworks5/plasma5 for plasma yet, or is
everything still kde4/plasma4 (aka plasma1). If it's 5, the plasmoid
should be available and generally usable for all of plasma5. If it's 4,
there's very little still shipping that, except for the occasional still
supported long-term-stale^H^Hble.
> as long as you have exec() you can do anything.
True, that. =:^) I use the "exec/script it" idea with all sorts of
stuff, including yasp-scripted (yet another sysmon plasmoid) early in
kde4, eventually migrated to superkaramba later, and I guess soon to be
migrated to something else again, as superkaramba is now EOL, no more
updates or porting to frameworks/plasma5, altho the kde4 version
continues to be functional for now, and will likely remain that way until
the distros finally drop kdelibs4/qt4.
> You could leverage the klipper Actions to do something similar, though
> it would be a bit more "hackish".
>
>
> Setup a regular expression like @K -- If you type, then double click
> that, and have automatic enabled (or, alternatively, if you use
> <CTRL><ALTR><R> to invoke manual klipper actions popupmenu), you would
> have a popup menu with all your commands that could be things like:
>
>
> Command=echo FLIMFLAM
>
> Output Handling=Replace Clipboard
>
> (organize as many commands that echo what you want under a single
> klipper action)
>
>
> then you'd just have to paste. I don't see a way in klipper to
> auto-paste
I hadn't thought of that, but it's right up my alley in terms of things
I'd be likely to try if I were desperate enough. See below. Meanwhile,
I'm going to have to keep the idea in mind now, just in case. Thanks!
=:^)
> Also, you can use 'khotkeys' to create a global shortcut that performs
> keyboard input. (but you'd likely run out of keyboard combos, or forget
> them.) also, i think khotkeys was destined for deprecation?
Well, sort of, khotkeys itself has been phased out, yes, but not the
general hotkey functionality, which is controlled by kglobalaccel in
plasma5. Tho AFAIK the mouse gestures functionality is gone, as is the
applications-menu hotkey association mechanism, and the input-typing-
emulation as suggested here, as well. But plasma5 still has configurable
exec-based hotkey-triggered launching via kglobalaccel, and as you said,
exec ultimately gets you pretty much everything. While it doesn't have
the nice GUI setup that khotkeys did with its apps-menu and kmenuedit
hotkeys association (kmenuedit is still there, just without the hotkeys
feature), and the mouse-gestures and emulated typing stuff is gone, as
long as you know how to run the app at the command-line, you can still
configure kglobalaccel to associate a command with a global hotkey launch-
trigger.
FWIW, I was a bit concerned about that myself, tho not as much as I would
have been, due to ... (below). But once I saw what they actually did, it
wasn't as bad as I thought it would be, and in fact I had tried the menu
associated hotkey launchers and mouse gestures and ended up not really
using them, gestures because I could never remember them, hotkey
triggered menu item launchers because... well, again, below.
> probably many other solutions. (i recall a very simple Xt X11
> application from many years ago that did similar things)
Check out sxhkd (simple X hotkey daemon), xdotool, xdo (IIRC a simpler
variant of xdotool), evrouter, xbindkeys, and perhaps wmctrl and xprop,
which compliment the others on the X window management side, thus
rounding out a full set of X scripting tools. Also, the xf86-input-
mtouch touchpad/touchscreen pointing device driver, to drive mouse
"button" events based on gestures such as pinch, 2/3/4-finger-swipe in
each of the four directions, etc. Most of these I actually use here,
either starting them with kde/plasma, or calling them in my own scripts
when various hotkey or mouse "button" events (as configured in the mtouch
driver) trigger.
My initial kde3 khotkeys setup was based on the fact that in kde3,
khotkeys could be configured with hotkey "chains", and I had done just
that, the reason being that I wanted more shortcuts than I had extra keys
to launch them with, and than I could easily remember without some help,
anyway. So I configured a couple of those "extra" keys as chained
launcher keys, such that I could hit launcher-g-p, for instance, to
launch first the games submenu (g), then kpat (p). Similarly, launch-w-b
would be launch-web-submenu (w), bank (b), and launch-f-e would be file
submenu, kwrite (editor).
Unfortunately, kde4 broke that, as chained hotkeys were no longer
possible in kde4's khotkeys. So I had to come up with a workaround.
Well I looked at various more generic solutions and the only one I could
find that directly supported chained hotkeys was xbindkeys in its
advanced mode. The only problem was that its advanced mode was scripted
using guile/scheme, which I didn't already know, and learning it just for
that was a rather steeper learning curve than I was after, as this was
only one of several problems I had to find a solution to, to get kde4
working with the functionality I had in kde3, and I was on a deadline as
my distro was phasing out kde3 because upstream kde was, even tho kde4
was still so very very broken for my usage and that of so many others,
and despite the Aaron S's (president of KDE eV at the time) very public
_promise_ that kde3 would be supported as long as there were users -- so
much for /that/!
The key insight to my ultimate solution came as I was beginning to study
guile/scheme. The eureka moment was realizing that if I could find or
script a popup menu app, that instead of using key chaining, all I had to
do was have kde's khotkeys recognize the first hotkey and use it to
launch this popup menu, which could then reinvoke itself as necessary,
nesting as many submenus deep as I wanted to chain, with each invocation
only dealing with a single level of the chain.
So that's what I ultimately hacked together, using what I *DID* know,
bash scripting, with a special konsole profile invoked running my bash-
based hotkey script to display a list of (possibly shift and/or control
modified, since those are the modifiers passed thru konsole on to
whatever it's running) single hotkeys, along with their associated
commands.
So then I could use the kde-based hotkey to launch the initial popup,
with its config, files, games, media, power, web, etc. single-key (c/f/g/
m/p/w) initial popup menu, using bash's read command configured to read a
single character, which would then launch the appropriate submenu, which
in turn would launch the desired app (normally, in a few cases I went
another submenu deep, like a hotkeys submenu under config, with choices
of hotkey menu file to edit).
Great. That worked well and effectively gave me my chained hotkey
functionality back, altho scripting it all in bash was obviously rather
slower than it would have been had I known C/C++ or whatever and could
have designed and built a real elf-based executable, instead of the bash
script that I used because that's what I already knew.
Time went on, and I upgraded keyboards and bought a fancy new touchpad.
But the problem with the keyboard was that some of its "extra" keys
weren't recognized by X. Which is where evrouter comes in. While it has
some hotkey functionality, its real purpose and strength is in mapping
events that X doesn't recognize onto something that it does recognize,
usually emission of a keysym that the various other hotkeys apps can
recognize and trigger on, or a shell command, tho it has a few other
command modes as well.
Similarly for the touchpad but xf86-input-mtouch is the solution there.
It recognizes gestures such as two-finger-pinch-in/out or three-finger-
swipe-left/right/up/down, and translates those into mouse-button-events,
generally using the button numbers above 7, since 1-3 are conventional
left/right/middle, 4/5 are vertical-scroll, and 6/7 are horizontal-scroll.
That gives you simulated high-button X-based mouse events, but as there's
no standard mapping for them as there is for buttons 1-7, you still need
something else to see those button events and translate them into actual
practical work.
Which is where sxhkd comes in, since it can see those high-numbered X
mouse button events and do something with them, emitting a string of
characters, for instance, or running a command.
As it happens, sxhkd is easy enough to configure, that given I already
had it running to handle those high-button events, particularly once I
started the kde5/frameworks5/plasma5 upgrade and I had to reconfigure
kde's hotkeys again, I ended up moving pretty much all my generic hotkey
config to sxhkd. So it's what's watching for my "launch" key now, to
launch the still bash-script-in-konsole based hotkey menu stuff.
Which leaves kde's hotkey config pretty much only handling kde-specific
hotkeys, mostly kwin related (switching desktop, moving windows to a
different desktop, activating the grid or cube or alt-tab switchers,
maximizing/normalizing, moving and resizing windows, etc), tho there's a
few for the plasma-desktop itself (switching activities, activating kmenu,
etc), ksession-manager (logging out), etc.
So as I mentioned above, while kglobalaccel still lets you map arbitrary
commands to hotkeys, it's functionality I don't use that much any more,
primarily because kde keeps changing stuff as it did with the kde4 and
now frameworks5/plasma5 upgrades, and if it continues to work AT ALL
(which the kde4 hotkey chaining did NOT), I keep having to reconfigure it
every few years. But with the plasma5 upgrade, I had relatively little
of that to worry about, because I already had most of the generic stuff
in the bash-and-konsole-based popup menu config. And I took that
opportunity to move even MORE of it to desktop-generic, sxhkd mostly, to
avoid that problem in the future.
Tho of course the switch/upgrade from X to wayland is going to be
trouble, and I guess there the only app that really has global reach is
the window manager, kwin, so there's quite some chance I'll either be
back to configuring generic global hotkeys via plasma/kwin again, or
perhaps there will be some third-party solution developed that will be
configurable as the compositor, but will pass the actual compositing
duties on to kwin, while only handling the global hotkeys (passing on to
kwin what it isn't configured to handle itself, of course). In any case,
that's a bridge to be crossed when I come to it, and wayland's changing
enough other stuff that this will probably be only one of several
concerns I have to worry about then, but meanwhile, there's going to be
enough legacy X-based stuff around, for long enough, that there's
unlikely to be the immediate pressure to switch that was so horrible when
they dumped kde3 support after promising not to, as they did.
Meanwhile... tying up a dangling loose end, much of the above is global
scope, while for some of those high-button events and for a few special
key events, I wanted/needed application or window scope. For instance, I
have the touchpad pinch-in/out event (as mapped to a particular high-
button pair) set to globally trigger kwin's zoom, so I can zoom in/out
globally, regardless of the app that's in focus. That only requires the
mtouch input driver mapping the pinch to the high-button event, and sxhkd
then mapping that high-button event to kwin's zoom functionality. But
the corresponding two-finger rotate, I wanted to rotate images in
gwenview, for instance, while doing nothing in most other apps, and
something else that's per-app individual in a couple other apps, instead
of the closest equivalent global functionality, which would be xrandr's
monitor rotation, something I don't find particularly practical (unlike a
global zoom function).
So then I needed some way to figure out what the in-focus window was, and
whether it matched gwenview's main window, or whatever other specific
window. That's where xprop comes in. Via scripting I can use wmctrl to
get the X window ID of the active window, and feed that to xprop to get
the window class, window title, etc. Basically the same stuff that kwin's
window rules uses, but here exposed in a script so I can logically match
window class and window title, etc, against preset strings, to see if the
active window is actually gwenview, or whatever.
So I have a helper script called winpropis, that matches a property given
on the commandline, against a string, also given on the commandline.
Then I have a script called winactiveis, that has some hard-coded preset
strings that match various properties of a given window, that calls
winpropis, to see if the given property of the active window matches the
desired preset, returning true if all the configured properties match
appropriately, false otherwise.
Then, in sxhkd, I can do for example:
winactiveis gwenview && <command for gwenview> \
winactiveis someotherapp && <command for it> \
winactiveis somethirdapp && <command for it> \
...
Finally, xdotool is often what I call in the actual command.
So putting it all together, here's my sxhkd configuration for buttons 18
and 19, rotate, along with the (# denoted) comments as in the file:
################################################################################
# 18,19: rotate: app-context
button18
[[ winactiveis gwenview || winactiveis okular ]] && xdotool key Left
button19
[[ winactiveis gwenview || winactiveis okular ]] && xdotool key Right
################################################################################
When either of those two specific app windows are active, and ONLY when
one of them is active (as determined by the xprop comparison via winactive
is), I invoke xdotool, telling it to type a single key, left, for the
button corresponding to touchpad rotate left, right for the button
corresponding to touchpad rotate right. Those two apps, in turn, have
their keymapping set so they rotate the image using those keys.
Here's a more complex example (a few lines are wrapped for posting):
################################################################################
# 8,9: swipe3up/down: app-specific
# gwenview: start-page/up
# firefox: zoom out/in
# orion: (cancel)/"gl n" (*100)
button8
winactiveis gwenview && xdotool key super+Return ; \
winactiveis firefox && xdotool key ctrl+minus ; \
winactiveis orion && { \
killall xdotool; \
dbusref=`kdialog --title Orion --progressbar " Orion:
Autoinput killed " 2`; \
qdbus $dbusref autoClose true; \
for sec in 1 2; do \
sleep 1; \
qdbus $dbusref Set "" value $((sec++)); \
done; \
}
button9
winactiveis gwenview && xdotool key Escape ; \
winactiveis firefox && xdotool key ctrl+plus ; \
winactiveis orion && xdotool getactivewindow type --window %1 --
delay 1400 \
"gl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl
ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl ngl
ngl ngl ngl ngl ngl ngl ngl ngl ngl"
################################################################################
So... umm... back on the original topic...
As you can see my usage is primarily for hotkeys, not to invoke
"snippets", and is rather advanced compared to that required just for
snippets, which would require little more than some hotkey app, perhaps
kglobalaccel, or perhaps the more generic sxhkd, or one of the others,
along with something like xdotool, if the selected hotkey app didn't
allow direct or easy snippet triggering. But kglobalaccel and xdotool
together could do it, or sxhkd and xdotool, or evrouter by itself could
do it, tho it's primarily designed for hardware event translation and the
configuration for this purpose would be somewhat obtuse/abstruse, such
that either of the above pairings would be more natural. And xbindkeys
really has quite a bit of functionality (tho it's been long enough since
I looked at it in detail that I really forgot the detail, just
remembering that it really does have rather advanced functionality), but
to access the more advanced stuff you'll need to know guile/scheme.
--
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
