Klipper - snippets

[Duncan]

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