Re: [kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
On Sat, Oct 27, 2012 at 1:50 PM, Duncan 1i5t5.dun...@cox.net wrote: OK, this is *MUCH* later, but I still had this marked unread in ordered to deal with later, and I'm finally getting the appropriately rounded tuit. =:^) There are two executable scripts and one kmap file, placed in a system location, and as many user menu files as desired. One menu file is invoked first, but invocation is nestable, so it's possible for the first one to invoke the scripts again, thus invoking an additional layer of menus. ...snip a ton... Duncan, I just found this email! For some reason some of your emails addressed to me did not get the Gmail Star that I use to identify mail addressed to me or replies to my mails. I see that there are quite a few, some dating back years! I'll go through these treasures in due time. You are extremely thorough and it will take me some time to go it all. Thank you very much! -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ 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.
Re: [kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
Dotan Cohen posted on Tue, 27 Aug 2013 14:57:06 +0300 as excerpted: Duncan, I just found this email! For some reason some of your emails addressed to me did not get the Gmail Star that I use to identify mail addressed to me or replies to my mails. I see that there are quite a few, some dating back years! LOL! Years now, indeed. Let's see, I finally got active on the kde lists when I switched to 4.2 after being a kde user since 2.x, and remember you were active on the list from early in my activity and likely from earlier. Now we're on 4.11, so nine releases, with two a year... over four years (it was 4.2.5, late in the 4.2 cycle, and it's still early in 4.11). I'm not familiar with how gmail works, but I can speculate that the some reason you speak of might have something to do with the fact that I read the list and normally reply via gmane.org's list2news service, which presents the various lists I follow as newsgroups. I then use the news client pan to read and reply, via gmane, which uses methods originally designed to forward posts to moderated newsgroups to their moderators, to in this case forward the messages to the appropriate list-serv, on the poster's (my) behalf. Presumably something in that process is fooling gmail's reply detection methods... I'll go through these treasures in due time. You are extremely thorough and it will take me some time to go it all. Thank you very much! Thanks for the explanation. I had wondered, about this one in particular, since external feedback should be interesting, but I realized some time ago that like me, sometimes your replies may be delayed by (up to) months, presumably because (like me) you get busy with other things, and because for some detailed replies, one must be in the proper mood, and have sufficient time available, to properly read and reply. Anyway, looking forward to your comments, in time, now that you've discovered that trove. =:^) -- 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.
[kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
Duncan posted on Tue, 13 Mar 2012 16:12:03 + as excerpted: [1] When kde4 broke multi-key hotkeys that worked just fine in kde3, I rolled my own solution. I'm not a C/C++ or even python/perl coder, only a bash scriptor, so I coded the script in bash and run it in a special konsole window with its own kwin window rules. It's not fancy, but it does a rather impressive job, considering it's all bash and kwin rules, picking up where all kde4 left me was broken pieces of a solution that USED to work! A kde single-key hotkey still launches my script tho there's independent hotkey solutions out there too, if kde decides to break that as well. My script in turn takes a category and then an action selection key, to launch anything I use often enough to have programmed a sequence for in a total of three individual key presses. For example, to open my browser of choice to bank's secure login site is launcher, n, b. Launcher is an extra key available on my inet/media keyboard, n=net (category), b=bank (individual task in the selected category). I would love to see your scripted hotkeys bash file. I use Krunner very heavily, and your solution might be even more efficient. FWIW, it's actually a collection of several files, an initial trigger script, the main menu script, a keymap file that maps ctrl-key hotkeys (normal printing characters and shifted chars are native, ctrl-key combos need the mapping file and some like ctrl-J, newline, don't work anyway, it's just those three variants, normal, shifted and controlled), and of course the menu files. The menu files are user owned/configured, the others are placed under the /usr/local/ location as system files. There's actually a bit of kde config that goes along with it too. I mentioned the kwin window rules and the single khotkeys based trigger key above. The last bit of the puzzle is that I run a separate konsole profile for the menu, tho I believe it's optional. (I tried it along the way, and had it setup when I got the thing working, so left it setup, but I don't think it's actually necessary.) I'll probably post the collection, along with appropriate instructions, later. I'm too tired to compose the instructions properly, ATM. OK, this is *MUCH* later, but I still had this marked unread in ordered to deal with later, and I'm finally getting the appropriately rounded tuit. =:^) There are two executable scripts and one kmap file, placed in a system location, and as many user menu files as desired. One menu file is invoked first, but invocation is nestable, so it's possible for the first one to invoke the scripts again, thus invoking an additional layer of menus. Here, I have two menu layers, a primary that selects the category (net, config, games, etc), and a second, category menu, that launches the desired action. It's thus three keys to launch anything I have configured an action for, the kde-launcher key (to launch the scripts with the primary menu), the category selector key (select the category and launch that menu), and the action selector key (launch the app/action configured for that key). (Originally, I had a single layer menu, much larger, thus requiring only two keys. But that got unwieldy, so I added a layer of indirection and a key to the sequence, breaking it into pieces arrange by category.) I'll post the files separately as replies. This is the instructions for setting them up and using them. First, create a separate konsole profile called hkm (without the quotes, hkm being short for hotkey menu). This allows you to setup different behavior for it than for your normal konsole. Here, my hkm konsole profile has a MUCH smaller scrollback menu of only a hundred lines, for instance, and I have the scrollbar set hidden, while it's shown on my normal konsole profile. If you like you can also set a distinctive font and background. (You could skip the separate konsole profile or name it something else, but if you do, you have to change the launcher script accordingly, since it invokes the menu script with the --profile hkm option.) Second, create a new window rule for the menu. If you don't already have a window rule for your normal konsole windows, you'll probably want to create one for them as well, setting anything you want to behave differently than the konsole menu windows. (The following description is for kde 4.9, other versions might be slightly different. I'm describing the English terms, I'm not sure how much of this might be localized. Window rules are found in kde settings, workspace appearance and behavior, window behavior, window rules.) On the window matching tab, set window class to exact match konsole konsole, and check match whole window class. Set window role to substring match, mainwindow#. Set window types to normal window. Set window title to substring match Hotkey Menu. The window title bit is extremely important, since
Re: [kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
Duncan posted on Sat, 27 Oct 2012 11:50:27 + as excerpted:
So four posts should follow, one each for the hkm menu script, the
hotkeylookup.lst keymap file, and two example user menu scripts.
Here's hkm, the menu script. Again:
1) There's some settings near the top you can change as desired.
2) If you change the name from hkm, change the invocation in hkl as well.
3) I put it in /usr/local/bin/, but anywhere on the path should work.
(Or you can change the invocation in hkl to an absolute path and won't
have to have it on your normal executable path, then.)
4) Don't forget to set the file executable.
I'm posting this as text, unwrapped. Be sure your client isn't
rewrapping the lines when you copy the below to the file. Also
be sure not to copy my sig to the file too, only the content between
the --- begin hkm --- and --- end hkm --- lines. =:^)
begin hkm
#!/bin/bash
# hkm (hotkey-menu)
# Two options possible:
# * debug as first will redirect the command's output to ~/hotkey.debug
# * Anything else as first parameter (or second if the first is debug)
# will be interpreted as the menu file to use (there's a default, see
settings).
# If the menu file path isn't absolute, it's interpreted as relative
# to $hotkeylistdir, see settings, below.
unset hotkeydebug
unset hotkeylistfile
if [[ $1 = debug ]] ; then
hotkeydebug=1
[[ $2 ]] hotkeylistfile=$2
elif [[ $1 ]]; then
hotkeylistfile=$1
fi
# Settings
# Prompt settings:
# Hotkey menu timeout delay, seconds (default=30)
querytimeout=30
# Post-launch timeout delay, seconds (default=3)
postlaunchtimeout=3
# Default key entered if prompt times out (default=escape)
defaultkey=$(echo -e \\e)
# Hotkey prompt
hotkeyprompt=Enter key from first column.\nAuto-cancel in $querytimeout sec.:
# Comment the /second/ line below if you don't want $defaultkey to abort
unset abortondefaultkey
abortondefaultkey=yes
# Location of the (default) hotkey listfiles dir.
# * Listfile format is keytabsdescriptiontabscommandnewline,
# thus allowing commands with options and arguments.
# * A line beginning with # is a comment.
# * The first two lines should be comments,
# and are intended to be displayed as the
# column headers when the list is displayed (below).
# * Blank lines are allowed for display formatting.
# * Settings defaulted here can be set per-file:
# * as comments for backward compatibility
# * keyed on the leading #%%
# * post-setting comment optional):
# #%%querytimeout=nnn #comment
# #%%postlaunchtimeout=nn #comment
# #%%defaultkey=xx#comment
hotkeylistdir=${XDG_CONFIG_HOME:-~/.config}/hotkey.lst
# The default hotkey list file.
# If the path isn't absolute,
# it is parsed as relative to $hotkeylistdir, above.
defaulthotkeylistfile=default
# Location of the hotkey-lookup list, for control code lookups.
# This matches typed codes such as bs (backspace), as found in the hotkey list,
# to the control codes the script gets from the machine.
# Format is textcode:machinecodenewline
# Again, a line beginning with a # is a comment, blank lines allowed.
# No special processing of the path is done here, so best make it absolute.
hotkeylookupfile=/usr/local/etc/hotkeylookup.lst
# First, do some setup
# If defaulthotkeylistfile is relative, prepend hotkeylistdir
[[ ${defaulthotkeylistfile} = ${defaulthotkeylistfile#/} ]] \
defaulthotkeylistfile=${hotkeylistdir}/${defaulthotkeylistfile}
# Do the same for hotkeylistfile if it was passed, default it if not.
if [[ $hotkeylistfile ]] ; then
[[ ${hotkeylistfile} = ${hotkeylistfile#/} ]] \
hotkeylistfile=${hotkeylistdir}/${hotkeylistfile}
else
hotkeylistfile=$defaulthotkeylistfile
fi
unset defaulthotkeylistfile
# sed hotkeylistfile for per-file settings and evaluate them.
IFS=
perfilesettings=$(sed -n 's/^#%%//p' $hotkeylistfile) #'
[[ $perfilesettings ]] set $perfilesettings
for eachperfilesetting; do
eval $eachperfilesetting 2-
done
unset IFS eachperfilesetting perfilesettings
# OK, now the real functionality!
# Display the first two lines of hotkeylistfile as column headers
head -2 $hotkeylistfile
# Grab the active lines out of hotkeylistfile, display them.
IFS=
hotkeylist=$(sed /^#/d $hotkeylistfile)
echo $hotkeylist
echo
unset IFS hotkeylistfile
# Display the prompt (takes one (perhaps modified) key, reply caught in $REPLY)
echo -ne $hotkeyprompt
read -r -N1 -d$defaultkey -t$querytimeout
[[ $? -gt 128 ]] REPLY=$defaultkey
echo
unset querytimeout
Re: [kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
Duncan posted on Sat, 27 Oct 2012 11:50:27 + as excerpted:
So four posts should follow, one each for the hkm menu script, the
hotkeylookup.lst keymap file, and two example user menu scripts.
Here's the hotkeylookup.lst file, UUE encoded after the sig as it
has control characters as the machine-codes. Despite that, the file
should be text-editable as long as you're careful not to munge-up the
machine-codes (to the right of the colons).
ASCII control characters are the assumption. I'm not sure how that
might work with localization. You surely know more about that than
I do.
Again, I place this in /usr/local/etc/ as hotkeylookup.lst, but that
can be configured in the settings near the top of the hkm script.
No need for execute permissions on this one, only read.
--
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
begin 644 hotkeylookup.lst
M(R`O;]E=,O:]T:V5Y;]O:W5P+FQS=`HC($AO=ME2!T97AT8V]D93IM
M86-H:6YE8V]D92!M871C:'5P('1A8FQE+@H*(R!3;VUE(-O95S('=O;B=T
M()E('1R:79I86QL0HC(]B=%I;F%B;4@:6X@=5R;6EN86P@8V]N=5X
M=X*B,@55X=-O94@9'5PR!/2RX*B,@36%C:EN96-O94@9'5PSH@
M4V-A;FYI;F@W1O',@870*(R!F:7)S=!E;G1R2!S;R!P=70@=AE(]N
M92!Y;W4@=7-E(9IG-T+@H*7D`Z``IN=6PZ``IN=6QL.@`*EY!.@$*V]H
M.@$*EY.@(*W1X.@(*B-0SH#0D)5Y#(')EV5R=F5D(A324=)3E0I
MB-E='@Z`PH*7D0Z!`IE;W0Z!`H*7D4Z!0IE;G$Z!0H*7D8Z!@IA8VLZ!@H*
M7DZ!PIB96PZ!PIB96QL.@*EY(.@@*8G,Z`IB86-KW!A8V4Z`IBSI_
M@I23H)FAT.@D*=%B.@D*B-2CH)0D)7DH@F5S97)V960@*YE=VQI
M;F4@/2!R96-OF0@V5P87)A=]R*0HC;FPZB-N97=L:6YE.@HC;8ZB-L
M:6YE9F5E9#H*EY+.@L*=G0ZPH*7DPZ#`IF9CH,F9OFUF965D.@P*B-
M33H-0D)5Y-(')EV5R=F5D(AT97)M:6YA;!C;VYT97AT(')E='5R;G,@
M7DHIB-CCH-B-C87)R:6%G97)E='5R;CH-@I3CH.G-O.@X*EY/.@\*
MVDZ#PH*7E`Z$`ID;4Z$`H*7E$Z$0ID8S$Z$0H*7E(Z$@ID8S(Z$@H*7E,Z
M$PID8S,Z$PH*7E0Z%`ID8S0Z%`H*7E4Z%0IN86LZ%0H*7E8Z%@IS6XZ%@H*
M7EZ%PIE=(Z%PH*7E@Z`IC86XZ`IC86YC96PZ`H*7EDZ0IE;3H9@I
M6CH:G-U8CH:G-U8G-T:71U=4Z@H*7ELZPIEV,ZPIEV-A4ZPH*
M7EPZ'`IFSH@I73H=F=S.AT*EY.AX*G,Z'@H*7E\Z'PIUSH?@IS
,,Z(`IS%C93H@
`
end
___
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.
Re: [kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
Duncan posted on Sat, 27 Oct 2012 11:50:27 + as excerpted: So four posts should follow, one each for the hkm menu script, the hotkeylookup.lst keymap file, and two example user menu scripts. Here's the first example user menu file, default. The hkm script has a setting that tells it which menu to load if it's not invoked with any. By default, that's default. There's a setting that tells it which directory to look in as well. By default, that's $XDG_CONFIG_HOME/hotkey.lst/, defaulting to ~/.config/hotkey.lst/ if XDG_CONFIG_HOME isn't set. The idea is to put the scripts and keymap file in a system location, with only the actual menu files stored in the user's home dir and editable by them. The menu files don't need executable permissions. This is my default menu file, invoked if no menu file is passed to the script. Note the per-menu-file option comments, with one of them, postlaunchtimeout, actually set. The global default is 3 seconds, generally enough time to see init errors after launch before the menu disappears. However, since my default menu entries simply launch additional menus, a 3/4 second delay is more appropriate. --- begin default - #keydescription command ### # a appshkl apps c config hkl config f files hkl files g games hkl games m media hkl media n net hkl net t terms hkl terms x xorghkl xorg ### # #^C (impl.rsvd) (unavailable) #^J (impl.rsvd) (unavailable) #^M (impl.rsvd) (unavailable) # used: # ^C ^J ^M a c f g m n t x ### per-file settings, keyed to initial #%% (so ##%% is commented): #%%postlaunchtimeout=.75 ### possible per-file settings: ##%%querytimeout=nnn#comment ##%%postlaunchtimeout=nn#comment ##%%defaultkey=xx #comment end default -- -- 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.
Re: [kde] @ Dotan: As requested (back in March, sorry): Hotkey launcher scripts
Duncan posted on Sat, 27 Oct 2012 11:50:27 + as excerpted: So four posts should follow, one each for the hkm menu script, the hotkeylookup.lst keymap file, and two example user menu scripts. Here's the last one, the second example user menu file, my games menu. I haven't yet described the menu file format. It's mostly self-evident, but there's a couple non-intuitive aspects. * In general, # beginning a line indicates a comment, but there's two exceptions. * The TOP TWO LINES are taken as column headers and displayed verbatim. * There's the previously mentioned #%% lines, used to set per-menu values for querytimeout, postlaunchtimeout, and defaultkey, if desired. Because these begin with # already, add another # for ##%% to comment them. * Blank lines are displayed as-is. * Non-#-commented lines are of this format: key description command Keep in mind that it's bash-parsed, so no spaces/tabs allowed in key or description. Use - or . or _ or whatever where you'd normally place a space in the description, and use either spc or space for space as a hotkey. That leaves the rest of the line for command, which can thus have spaces, etc as needed for the command. So here's the file... -- begin games --- #keydescription command ### # o orion /home/x/config/local/share/orion/orion.sh p patiencekpat P palapelipalapeli s sudoku ksudoku ### # #^C (impl.rsvd) (unavailable) #^J (impl.rsvd) (unavailable) #^M (impl.rsvd) (unavailable) # used: # ^C ^J ^M o pP s ###per-file settings, keyed to initial #%% (so ##%% is commented): --- end games --- -- 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.
