How to use Plasmoid shortcuts

Duncan 1i5t5.duncan at
Thu Feb 24 04:37:09 GMT 2011

Dotan Cohen posted on Thu, 24 Feb 2011 02:08:07 +0200 as excerpted:

> On Wed, Feb 23, 2011 at 20:14, Duncan <1i5t5.duncan at> wrote:
>> Dotan Cohen posted on Wed, 23 Feb 2011 19:00:00 +0200 as excerpted:
>>> I have the Quick Launch plasmoid in a panel. I have set it a keyboard
>>> shortcut, but pressing that shortcut does not focus the plasmoid. How
>>> are these shortcuts to be used?
>> I don't claim any authority on this, but based on my observations...
>> Plasmoid keyboard shortcuts should make the plasmoid visible... bring
>> the panel to the top or unhide it if it's hidden, etc.

>> What plasmoid shortcuts do beyond "make visible" appears to be
>> individual plasmoid dependent.

>> I suspect that quicklaunch, being primarily icon based interaction,
>> doesn't do much beyond become visible when the shortcut is triggered.
>> I'd consider it relatively unlikely that keyboard navigation
>> implementation would be any sort of priority (other than "bluesky"),
>> the assumption being that you use the right tool for the job, and while
>> quicklaunch may indeed be a useful tool for point-n-click launching,
>> it'd make a poor keyboard launcher even if the functionality was
>> implemented.

> Like you, I prefer to launch with a keyboard launcher. I usually use
> Krunner (Alt-F2). However, because of a bug I cannot launch some apps
> with it:

I believe part of the issue may be that krunner checks more than just the 
shell-path.  In particular, it knows of and ranks higher in the priority 
sequence anything found in the the apps menu (kickoff/kmenu/lancelot).  If 
it sees more than one choice, it should have a list (you may have to 
expand the krunner window vertically, or look for the arrow, to cycle thru 
items not fitting in the list).  If the nepomuk runner plugin is enabled 
and it's looking in mail, etc, as well, you can get a whole SLEW of 
generally false-positives, so turning that and a few others off if you 
never use their supplied choices can be useful.  (Plus, at least in kde 
4.5 and previous, the nepomuk plugin tended to crash krunner once in 
awhile, so turning it off increased krunner stability.  IDK if that still 
applies with 4.6.)

You can use the icons presented with the run-choices to determine the type 
of item.  A nice app icon indicates that it's using the menu entry, with 
its associated icon.  A generic "gear" icon indicates that it's pointing 
directly at a binary.

What I suspect is happening is that you have a firefox menu entry which 
points to the system firefox (bypassing your ~/.bin/firefox entry).  That 
has the nice fancy firefox icon since it's associated with the menu entry 
which includes it, so you can tell it's the menu entry.  Lower down the 
rankings, you should find probably two "gear" icon choices, one for your 
~/.bin/firefox entry, and another for the system firefox binary.  
Presumably, they'll be in path order.

You have a couple choices to modify this (beyond turning off unnecessary 
krunner plugins as mentioned above).  First, you can edit your firefox 
menu entry (context-click on the menu plasmoid and choose edit 
applications, that's the 4.6 wording, AFAIK it was slightly different in 
earlier versions, or simply run kmenuedit) to point to the ~/.bin/firefox 
instead of the system firefox.  

Second, you can either rename your ~/.bin/firefox entry to something 
unique (firefx, fx, ffox, whatever), or create a uniquely named symlink in 
the same dir to the existing firefox entry.  Suppose you choose ffox.  
Hopefully, that won't conflict with anything else, or if it does, the 
other entries will be ranked lower in krunner, so typing ffox in krunner 
will get you the desired ~/.bin/ override.

Meanwhile, kde/krunner path...

Try this (in krunner) to see what settings kde/krunner are actually 

env > ~/krunner.env

Then open the file in a text editor to see the results.

Since env is a separate app, that doesn't invoke the shell init files as 
konsole does, so you get the environment directly as krunner sees it.

FWIW, kde, including krunner, gets my custom environment, including path, 
here, and with ~/bin coming before pretty much anything else in the path, 
as expected, it allows me to override (or more often, setup additional 
custom environment before launching) system binaries.

I know there was a thread on that, but I suspect it might well be working 
as it does here, because I login at the CLI, then run "k" (actually, 
generally ". k", so it logs out the existing CLI login after starting), a 
custom script which:

# Set/export some kde and xdg specific vars as so (see KDE User Guide
# (from the khelpcenter package), Part VI, KDE for Administrators, Chapter
# 25, KDE Internals, Environment variables subheading), because I don't
# like the defaults:

export KDE_NO_IPV6=1
export KDEHOME="$HOME/kde"
export KDETMP="/tmp/tmp-$USER/kde"
export KDEVARTMP="$HOME/config/cache"
export XDG_DATA_HOME="$HOME/config/local/share"
export XDG_CONFIG_HOME="$HOME/config"

# Then:

[[ $KDEVARTMP ]] && mkdir -p $KDEVARTMP	# in case it doesn't exist
kbuildsycoca4				# regen the config-db

# XSESSION should point to a system session script file in
# /etc/X11/Sessions, the KDE-4 file is provided on Gentoo by
# the kdebase-startkde package.  If it's not set, a generic
# default is used (on Gentoo, a minimal xsm and xterm), but that
# wouldn't be kde and I don't have the packages for it installed
# (I overrode the dependencies since I only use kde), so KDE-4 it is.

startx &

# Note the & putting startx into the background...
# That allows this to work, thus exiting the CLI login
# as KDE starts, if I use the ". k" launch form.

disown -a
exit 0

#### end of script ###

That starts a kde session from my CLI login.  Since the CLI login is 
running a shell, the exported environment, INCLUDING the PATH and the 
various specific vars set above, gets inherited by the KDE session, and 
krunner gets the working path one would expect.

I suspect there's a similar way to do it using a *DM, but I haven't used 
those things ever since the one I was using broke on me, along about 
Mandrake 8.2 or so (so nearing a decade ago now).  Fortunately, startx 
still worked, and I've considered it more reliable ever since.  I don't 
need a fancy graphical login to enter username and password, and given 
that I only have kde setup as an X environment, it's not like a point-n-
click session chooser is of much benefit either.

Plus, it's actually straightforward to have my environment setup as I 
want, since if it's kde specific I can put it in the "k" script, and if 
not, it's simply inherited from the existing CLI login environment.

>> So... if you're looking for a plasmoid (or other tool) to take focus
>> and allow keyboard interactive launching... use something other than
>> quicklaunch... and without active keyboard navigation implemented in
>> quicklaunch, "make-visible" is about the best one can expect from a
>> trigger shortcut assigned to it.
> I'll file a feature request on the arrows-navigation on the plasmoid,
> like you mentioned. That is quite the behaviour that I had expected.

As an aside, I've been sick a couple days.  I'm getting better now, but am 
rather bored as I already caught up (well, as of a few hours ago, there's 
a few more now I imagine) on system updates, all my news feeds, my 
newsgroups/mailinglists, etc.  And now I'm scheduled an additional two 
days off... so I have more time to reply in depth than I usually do.  
That's why all the detail...

Since you mentioned a preference for keyboard launching...

Have you tried kde's launch shortcuts?  There's a couple ways to configure 

First, for stuff in the menu, you can attach shortcuts using the 
previously mentioned menu editor.  Of course, that means it has to have a 
menu entry, and altho you can create one if necessary, over the longer 
term this results in a seriously customized menu that becomes difficult to 
maintain as your app mix changes.  Still, for only a few already-in-menu 
entries, this is the easiest way.

Second, in kcontrol (system-settings that umm... aren't for the most part 
system-settings), there's the Custom Shortcuts applet under Shortcuts and 
Gestures (under Common Appearance and Behavior).  This is **FAR** more 
flexible, allowing not only keyboard shortcuts, but mouse gesture 
triggered shortcuts, etc. as well.  Further, the range of available 
actions is far larger, everything from global app launchers (as we're 
talking here) to dbus-commands to keyboard input either to the active 
window or a specific app.

Using custom shortcuts, it's quite possible to setup say Meta-F (Win-F) to 
launch firefox.

Meanwhile, my needs, based on kde3 khotkeys' ability to take multi-key 
input (not available in kde4, I've referenced the bug many times here) and 
the fact that I have an inet/media keyboard with a number of extra keys, 
one of which I was using in kde3 as a sort of launch-key, for two-key 
launching, aren't quite served by the above, thus the script I mentioned 
earlier in the thread.

What I eventually realized when trying to figure out how to get kde4 to 
function like kde3 did in regard to multi-key hotkeys, was that what I was 
in effect doing was using the first key as a sort of hot-app launcher menu 
trigger, with the second key selecting the app from that menu.  Thus, what 
I actually needed was a launcher app that would take a single key and then 
execute the command configured for that key, since I could then map that 
app to a single-key custom shortcut as above.

So that's what I did.  The implementation is actually in six parts.  The 
first part is a kde custom shortcut setup to launch a hotkey-launcher stub-
script.  This stub-script, part two of the implementation, consists of a 
single line, and is never directly visible:

exec konsole --profile hotkey-menu -e hotkey-menu

That line launches konsole with a special profile, executing the real core 
of solution, part three of the implementation.  The special konsole 
profile then becomes part four, as I then have a kwin window-rules setting 
keyed to it, setting it always-on-top, centered, etc, rather different 
than my normal konsole kwin-rules settings, which are also customized.

As I mentioned, part three is the real core of the solution.  It's a bash 
script executed in the special konsole profile window, that takes exactly 
one key (optionally modified by shift or control, it's limited to those 
modifiers for technical reasons), looks that key (plus modifier) up in a 
conversion table text file (part 5), and in turn looks the result up in 
the user's hotkey.lst text file (part 6).

The conversion table (part 5) simply maps control characters to their text-
represented counter-parts, thus giving me control as well as shift 

The user's hotkey.lst file consists of a three-column mapping, space-
delimited, #-commented:

#key		short-description	actual-command
####		#################	################################
####		^^^^^^^^^^^^^^^^^	^ First two lines used as header
a		bAnk			konqueror <url-to-my-bank>

# snip... note that I've tried to keep generic where possible,
# so I can change banks, calc applets, text editors, etc,
# without having to retraining myself to different shortcuts

c		Calc			kcalc

# snip...

e		textEdit		kwrite

# snip... "k" has all three possibilities used

k		mouseset		xset m 13/5 0
K		keyrep-norm		xset r rate 200 12
^K		keyrep-slow		xset r rate 333 3

# snip... ^M is reserved...

m		Mail			kmail
#^M		(impl.rsvd)		(unavailable)

# snip... set-display is a a script of mine that invokes
# xrandr to set various resolutions.  The number roughly
# corresponds to horizontal resolution, so 19-6 indicates
# 1920 (full 1920x1080) on the top monitor, 640 on the lower,
# 9 indicates 960x540 on both, 10x indicates a non-square-pixel
# but standard resolution of 1024x768, etc.
# Note that this is a whole row of keys in order...

`               setdisplay-full         set-display
1               setdisplay-19-6         set-display 19-6
2               setdisplay-19-9         set-display 19-9
3               setdisplay-6x           set-display 6x
4               setdisplay-8x           set-display 8x
5               setdisplay-10x          set-display 10x
6               setdisplay-9            set-display 9
7               setdisplay-11           set-display 11
8               setdisplay-12           set-display 12
9               setdisplay-14           set-display 14
0               setdisplay-16           set-display 16

# snip...

<		player-prev		mpc prev
,		player-play		mpc play
>		player-next		mpc next
.		player-stop		mpc stop

# snip... end sample

Key can be something like g or G or ^G, with obvious holes for ^M, ^J, 
etc, which are reserved due to implementation limitations.  Short-
description is a human-readable description, with the limit that it's bash-
parsed as a single "word", so no spaces, etc (as is common, _ and - can be 
used as substitutes).

That leaves the third field and beyond to be treated as a single command, 
which can then have spaces, etc, as necessary.

I have part one, the custom shortcut, setup to use Home_Page aka 
XF86_Home_page, one of the "extra" keys on my inet/media keyboard.  That 
launches part two, the stub-script launcher for part 3, the core script.

The core script (part 3) gets a bit complex so I won't post it inline or 
attach, but if you or anyone else is actually interested, I can post it as 
a followup.  Meanwhile, as I've mentioned that I use my own custom 
keyboard shortcut launcher script a number of times in the past, I thought 
it might be interesting to post the above, so people could have at least 
some idea of what I was talking about in rather more detail than I've 
posted in the past.

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:
More info:

More information about the kde mailing list