On Thu, Feb 24, 2011 at 06:37, Duncan <1i5t5.duncan@xxxxxxx> wrote:
>> 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.)
>
Thanks. The Firefox in the Lancelot menu is in fact ~/.bin/firefox.
Disabling the "command line" in Krunner fixed it, it is now running
~/.bin/firefox. However, there are other wrappers in ~/.bin that are
not in the menu and naturally stopped working. I'll just add them all
to the menu.
Other than that, I learned a long time ago to disable Nepomuk in
Krunner and the Nepomuk service.
> 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.
>
Yes, but it does not distinguish between binaries in /usr/bin and in
~/.bin. The menu item does in fact point to ~/.bin/firefox.
> 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.
>
No, just one with the gear icon. It points to /usr/bin/firefox. But
you are right, I can simply tab over to the firefox with the
kitty-titty icon and launch from that.
http://www.humorhound.com/wp-content/uploads/2008/10/firefox-boob-cat.jpg
> 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.
>
Editing ~/.bin/firefox to something else would quite defeat the
purpose of a wrapper, but I could wrap the wrapper with a unique name.
> 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.
>
Nice thinking there! It does appear that the path is correctly set:
âganymede:~$ cat krunner.env | grep PATH
WINDOWPATH=7
PATH=/home/dotancohen/.bin:/home/dotancohen/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
QT_PLUGIN_PATH=/home/dotancohen/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/
> 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.
>
That was quite my goal, alas, it is not working as expected (krunner
opens binaries in /usr/bin instead of ~/.bin even though the latter
precedes the former in the PATH).
> 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:
>
What does that dot do? I don't see how I could google that!
> # 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.
>
I'm not sure that I want to start messing with all that, especially as
this clearly looks like a bug. And there is an easy workaround: wrap
the wrapper. But it is good to know. Thanks.
> 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...
>
Well, it did take me a week to get back to you, but I hope that you
feel better. The wife was also sick last week. Hey...
> 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.
>
I did have this at one point (Tux-1 through Tux-0 for launching my top
ten apps). But I happen to like launching by name. I plan on doing
something else with those controls, such as macros or some such.
> 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.
>
This is quite the scroll you have compiled! I will have to reread
that, but I see that there are some goodies in there that I want to
learn from. Thanks, Duncan, your posts are always very informative.
Informative enough to take me a full week to digest!
--
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.
