How to use Plasmoid shortcuts

[Duncan]

Dotan Cohen posted on Thu, 03 Mar 2011 22:28:19 +0200 as excerpted:

> On Thu, Feb 24, 2011 at 06:37, Duncan <1i5t5.duncan at cox.net> wrote:
>>> Like you, I prefer to launch with a keyboard launcher. 

>> I believe part of the issue may be that krunner checks more than just
>> the shell-path.

> 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.

Yeah, that kinda sux... but at least there's a workaround...

> Other than that, I learned a long time ago to disable Nepomuk in Krunner
> and the Nepomuk service.

=:^)

> 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

Interesting. =:^)

>> 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 

>> 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 [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.

That'd be what I'd probably do... and actually do do in other contexts.  
For example, gentoo's portage has an "esync" (gentoo tends to use e* for 
many of their gentoo-tools, including "emerge", the portage package 
manager's main binary name) command that syncs the local package tree with 
the remote.  I've chosen the "esyn" (lacking the terminating "c") moniker 
for my wrapper, which among other things, syncs overlays as well, and pre-
downloads the sources for the packages to be updated.

As most sysadmins, I tend to like short commands for stuff I'll be typing 
a lot (thus the wrappers in the first place, since many of them simply 
include a pre-cooked default command line), so ffox or ffx or simply fx 
might well be the operational name on my wrapper.  Occasionally, I even 
check $0 in my shell-scripts and base the default command on what that is, 
thus allowing me to create a whole host of different defaults, by simply 
symlinking different command names.  (Changing command personality based 
on what it is run as, thus allowing different symlink/hardlink names to do 
different things, is a not uncommon Unix trick; most definitely it's not 
original to me.)

>> 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!

I'd love to claim the credit, but IIRC it was Kevin Krammer that 
originally posted that tip.  I just filed it away for use whenever I 
needed it, as I have a couple times since.  =:^)  Given that he's a kde 
dev, I imagine it might be somewhat common knowledge among the devs, who 
after all likely have various env settings they want to check from time to 
time, as well.

Wherever it originated, seeing it posted immediately triggered one of 
those "Duh! I should have figured that out!" moments that we all have from 
time to time.  It /is/ nice thinking! =:^)

> 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).

That's... frustrating, for sure.

>> 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!

Unfortunately, there's some things google isn't too good with. =:^(

(Of course this is one of my secondary objections to the renaming of 
kcontrol to systemsettings, as well, kcontrol is reasonably googlable, 
systemsettings... not so much!  IMO whoever came up with that rename 
should have their memory of where to find kde's control options 
cauterized, so they are forever forced to have to google systemsettings 
and sort thru the mess they created to figure out how to set anything!  
The same thing applies to ksysguard/systemmonitor, too!)

Enter "help ." at a shell (presuming bash here, I'm not sure whether the 
"help" builtin is in POSIX sh or not).  That gives you the "official" 
version.  (You can use "help <builtin>" for any bash builtin to get a 
short explanation of the command, similar to the --help command line 
option for most stand-alone commands.)

Perhaps more practically, a single . as a command, followed by whitespace 
and another command, is a shortcut for the "source" builtin (the help 
output is identical for both, save for the name, of course).  "source" 
simply means "run in the current shell" not as a child process, as would 
normally be done.  There are two primary reasons I use it, instead doing 
the default child process thing.

First, because it executes the content of the called script in the 
/current/ environment, it allows setting environmental variables, etc, in 
the /current/ environment, whereas otherwise they'd disappear along with 
the child process when it terminates.  Thus, if I will be repeatedly using 
a complex environment with a lot of shell variables, shell functions, etc, 
but don't want to pollute my /normal/ shell environment with them, I can 
set them up in a script, then when I want that environment, simply "source 
<scriptname>" or using the shortcut ". <scriptname>" and "like magic" all 
those shell vars/functions, etc, "appear" in my current environment, as if 
I'd typed them all in manually.  Without the ./source in front, the script 
would be invoked as a child process and when it finished, the vars/
functions it setup would disappear with it -- nice when that's what you 
want, but frustrating when the whole object is to get them in the 
/current/ environment, without having to type them all in.

Second, and the reason I use it to call my kde launcher (simply "k", I 
/said/ I liked short commands! =:^), for stuff that's going to be running 
for awhile, it allows one to:

a) launch the long-term process in the background using "<command> &" (the 
terminating "&" uses shell job control to launch the command in the 
background).

That's what the "startx &" bit is doing, issuing the startx in the 
background, so the script continues running instead of hanging around 
waiting for startx to finish.

b) (sometimes necessary to avoid a termination race condition) sleep a few 
seconds to let the backgrounded task actually start.  I've found that if 
the steps below happen too quickly, sometimes the script terminates before 
the launch has actually properly occurred, and it doesn't happen.  
Sleeping a couple seconds seems to allow the new process to properly 
background before the below occurs, eliminating the race.

This would be accomplished with a "sleep 2" or some such.  As it happens, 
in this case it doesn't appear necessary on my system, so the script as I 
posted it doesn't include the sleep.

c) call "disown -a" to "disown" the just backgrounded app.  This prevents 
the SIGHUP normally sent from the parent to its children when it exits 
from terminating its backgrounded childen as well... Terminating what was 
just launched along with the launcher rather defeats the purpose of a 
launcher script! =:^)

Obviously, that's what the disown -a does...

d) explicitly exit the launcher script.  Again, the disown above prevents 
this from SIGHUP-terminating the children just launched.  And of course, 
the whole bit of the script beyond the backgrounded launch executes 
immediately, instead of hanging around for the launched process to exit, 
because the launched process was launched in the /background/.  The 
"explicitly" is important, see the next step.

The exit 0.

e) THE POINT OF USING the "."! =:^)  Because I launch the script with ". " 
aka "source ", it executes as part of the /existing/ shell, instead of as 
a child.  Thus, the explicit exit in step "d" above exits not JUST the 
child, but ALSO the current shell which invoked the launcher.

Thus, the effect is as if I had manually run startx in the background (so 
I get the shell prompt back), manually disowned it, then manually exited 
my current CLI session.

So:

If I run it as ". k" it exits the CLI shell I logged in at, which is often 
what I want it to do, if all I'm doing is starting X/KDE.

If instead I run it simply as "k", it runs in a child process, so the 
explicit exit only applies to the child process, and I keep my CLI login 
around.

The point is that this way, I get the choice, depending on whether I 
prefix the "k" with ". " or not.  If I'm just launching X/KDE, I'll use 
". k" and exit the CLI login since it's just sitting there using extra 
memory otherwise.  If I'm testing/troubleshooting something (maybe a new 
xorg.conf option, or an X that won't start because I updated xorg-server 
to a new abi-incompatible version and forgot to rebuild the xf86-input-
evdev and xf86-video-ati drivers I use for the new abi, as happened 
recently when I upgraded to xorg-server 1.10...), and expect to be back in 
the CLI relatively quickly, I'll often run it without the ". " as simply 
"k", so the current CLI login stays around, and I don't have to repeatedly 
enter username and password again and again, testing X/KDE sessions likely 
to last 3 minutes or less.

FWIW, similar to source/. is the "exec" builtin, which basically does the 
same thing, except with any binary.  So running "exec command" will 
transfer control of the existing process to "command", instead of starting 
"command" as a new child process.  (The PID, process ID, of the script 
before the call to exec will be inherited by the exec-ed command.  In an 
advanced script, therefore, one could use this handy bit of knowledge to 
for instance pass the automatically set $BASHPID variable to some control 
process, then exec the command that is intended to be controlled, so it 
inherits $BASHPID as its PID as well.  The control process could then do 
its thing using the PID it was passed as $BASHPID, since that's now the PID 
of the target that was exec-ed. ... Tho I've not actually needed to use 
exec for that purpose, but it's nice to know that I can.  I normally use 
it simply for the slight resource conservation and speed, since exec 
eliminates some of the new-process setup overhead.) 

Thus, the two practical reasons I use ./source are (1) to allow me to 
import a working environment setup in a script, and (2) to allow me to 
exit the current shell when I exit the called script.

[Previously posted CLI-based kde start script, and discussion, omitted.]

> 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 ... so I have more time to reply in depth than I usually
>> do.

Yeah, I knew that was a bit much as a solution.  However, given that I had 
several times mentioned that I start kde from a CLI login, using a script, 
and I was as I explained bored and had the time... I figured someone 
either now or coming across it later might find something useful therein...

And it /did/ provide the context for your question about source/. , so if 
you or someone else finds that useful... there's the "something useful 
therein"! =:^)

> 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...

/MUCH/ better now, thanks! =:^)  Nothing like being sick for a few days to 
make one SERIOUSLY appreciate the health they kind of take for granted 
much of the time.  =:^)

>> Since you mentioned a preference for keyboard launching...
>>
>> Have you tried kde's launch shortcuts?

> 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.

FWIW... Here, I use the Meta/Win/Tux key as my (X-)windows key. =:^)  
Seriously.  I use Win-End to... what else... end (close) a window, Win-
Insert to "insert" the window menu (normally alt-f3), Win-PgDn to 
minimize, Win-PgUp to maximize.

... And for other window/window-manager (kwin) related shortcuts, Win-C 
triggers the cube-desktop-switcher effect, Win-G the desktop-grid, Win-S 
toggles desktop effects, Win-Ctrl triggers the mouse-finder stars, Win-
Ctrl-Up the ZoomIn effect, Win-Ctrl-Dn ZoomOut, Win-Ctrl-Left ZoomNormal...

I find mapping the Windows key to (X-)windows actions both intuitive and 
far easier to remember than the rather arbitrary Ctrl-f11 type shortcuts 
kde defaults to for some of these.  Also, Ctrl and various fN keys can be 
used for other purposes, thus creating conflicts, while the Windows/Meta/
Super/Tux/whatever key is traditionally system-reserved and not always 
available, so is relatively unlikely to conflict with app-specific 
shortcuts.

Of course, that's doable since I use the multi-key approach for my app-
launchers (and have several additional keys on my Logitech keyboard that I 
use for the purpose).  If I didn't have that, as was the case before I 
setup my own scripted system for kde4 after kde4 killed the functionality 
that worked so well for me in kde3, I'd be (and WAS!!) at a /terrible/ 
loss!  Until I could find a workable solution for that, kde4's loss of 
multikey hotkey launching was a GAME OVER as far as switching to kde4, for 
me.  Fortunately, I'm just stubborn and just bash-script-skilled enough to 
hatch a workable solution, once I had that insight regarding multikey, 
that what it was, was simply configuring the first as effectively a menu-
launcher for the second.

>> 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)

[snip, snip, snip...]

> 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!

<g>  Well, as I said, I was sick... and bored... so my usually /quite/ 
detailed replies became /very/ detailed indeed!  =:^O  But it solved the 
boredom issue... and I've enough experience with my posting style by now 
to know that often, way more people than simply the original poster find 
my long replies at least moderately useful and informative (even when the 
original poster doesn't), so ... I guess it's all good (even if I also 
realize it drives certain others to absolute distraction... but then 
that's what kill filters are for if they find it /that/ terrible to deal 
with <shrug>).

-- 
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.