How to use Plasmoid shortcuts
Duncan
1i5t5.duncan at cox.net
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 cox.net> 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:
> https://bugs.kde.org/show_bug.cgi?id=263883
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
getting:
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 KDE_UTF8_FILENAMES=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.
export XSESSION=KDE-4
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
them.
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
modifiers.
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>
#A
#^A
# 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
#C
#^C
# snip...
e textEdit kwrite
#E
#^E
# 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
#^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: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list