[kde] Re: How to use Plasmoid shortcuts
On Fri, Mar 4, 2011 at 02:31, Duncan 1i5t5.dun...@cox.net wrote: 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! =:^) That's what I thought too: Why didn't I think of that? 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. =:^( 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.) I did not realise that I could use the bash help on that. Thanks, that is enough to get me started. 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. That is handy! 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... I had never heard of disown, thanks. 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),
[kde] Re: How to use Plasmoid shortcuts
On Thu, Feb 24, 2011 at 06:37, Duncan 1i5t5.dun...@cox.net 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
[kde] Re: How to use Plasmoid shortcuts
Dotan Cohen posted on Thu, 03 Mar 2011 22:28:19 +0200 as excerpted: On Thu, Feb 24, 2011 at 06:37, Duncan 1i5t5.dun...@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
[kde] Re: How to use Plasmoid shortcuts
Dotan Cohen posted on Thu, 24 Feb 2011 02:08:07 +0200 as excerpted: On Wed, Feb 23, 2011 at 20:14, Duncan 1i5t5.dun...@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
