Reply bottom-posted As happens too often, I forgot to set the correct identity before posting this reply the first time. That reply was bounced. I have tried to stop it; if it slips through and this message ends up double-posted, please be forgiving. ----- Original Message ---- > From: Duncan <1i5t5.duncan@cox.net> > To: kde-linux@kde.org > Sent: Sat, April 17, 2010 11:21:59 AM > Subject: Re: [kde-linux] Alt-F1 shortcut (Kicker) disappears > > Bruce Miller posted on Sat, 17 Apr 2010 05:57:10 -0700 as excerpted: > > I have an recurrent problem with KDE 4.x in which the Alt-F1 shortcut > > ceases to function. The Alt-F1 shortcut brings up Kicker and the panel > > (what, in another OS's terms, is called the "Start Menu"). > > Does > anyone know what might be causing this problem? I suspect it might > be a > "finger fumble" on my part. By definition, "finger fumbles" are > random > and therefore hard to avoid, but there is some possible comfort > in > knowing the cause. > > More importantly, does anyone know a fix or > a possible workaround? So > far, the only thing that has worked for me is > the "nuclear option," > which is surely overkill. By "nuclear option," I > mean backing up the > ~/.kde tree and reconfiguring KDE from > scratch. > > I use Kubuntu and am currently on Lucid Lynx 10.04 > Beta2, using KDE > 4.4.2. I don't know if kubuntu customizes this > or not. The below describes what kde ships. There's a couple > ways to set that. One is using kcontrol (aka system settings, even tho > it's kde control more than system settings), computer administration, > keyboard and mouse, global keyboard shortcuts. Select plasma-workspace > from the drop-down list. Activate Application Launcher > Widget. However, depending on your plasmoid/widget layout (number of > panels and activities, the plasmoids on each), you may have several such > items listed. You can click on each one to see what the default > reference is (if it's unset or set to something else), and set it to that, > or select a custom hotkey. The other way to set it is more direct, > and better, if you have several launchers on various activities and panels, > as this way you know which one you're actually setting. Context-click > on the plasmoid in question. Select application launcher settings, > then in the resulting dialog, the keyboard shortcut tab. Click the > button and set what you want. As far as your "nuclear option", consider > using the bisect method the next time you are forced to "go nuclear". > You didn't mention it, but this should normally be done while working in > other than kde, so from the command line or from gnome or something, not > inside kde. Backup (copy) the ~/.kde tree as you mentioned, then in > the working version (not the backup), delete roughly half the > stuff. Start kde and see if the problem's still there or is gone. > (Of course, a lot of your other customizations may be gone, but don't worry > about that, you're just testing.) If the problem was in the part that > you deleted, the problem should be gone. If the problem was in the > part that you kept, it should still be there. Quit kde again, and > delete the working ~/.kde copy, since the test will have likely recreated a > bunch of files with default entries again, and you still have your complete > backup. Now, based on whether the problem was gone or not, copy back from > your backup the half of the settings that you now know do NOT have the > problem (the half you deleted if the problem was still there, the half you > kept if the problem was gone. Also copy back about half of the "bad" > half, so you now have roughly 3/4 of your settings, the half you know was > NOT the problem, and half of the half you know WAS the > problem. Repeat the process recursively, each time narrowing down the bad > candidates, half the first time, a quarter the second, an eighth the > third, etc. Eventually, you'll know what directory the problem is in, > so you can keep everything else, and repeat the process in that directory, > until you find the subdirectory it's in, then the individual > file. When you get down to the individual file, you have a choice. > (Well, actually, you have this choice anywhere along the line, but when you > get to the individual file is where it starts getting interesting.) By > this time, based on name and narrowing missing functionality, you should > have figured out to a reasonable degree how many remaining settings that > file contains. You can confirm your guess by seeing how big the file > is and/or by taking a look at it in a text editor. If you're > comfortable with resetting any still affected settings, you can simply > delete the file and do the reconfiguring necessary. People that don't > customize that much will probably find their quitting point earlier in the > bisect, since they don't have many customized settings lost that they have > to reconfigure. Heavy customizers such as myself will continue the > bisect far further, since they have more to lose at the same point in the > process. Others may simply be curious, and want to find what went > wrong to the finest degree possible. I'm generally one of those folks > too, even where I don't customize so much. If you aren't satisfied with > just the file, you can continue the process into the file itself, using the > text editor instead of file operations, now. KDE has deliberately > continued to keep nearly all settings in text based files, precisely so they > /can/ be edited with a simple text editor, if need be. Often, you'll > find the file is the reasonably standard *.ini file format that was popular > back in the MS Windows 3.x days. These have sections denoted by > [titles], followed by lines of configuration for that section, usually in > setting=value format. These files are very easy to continue > bisecting. Simply choose about half the file to delete, working with > whole sections. Continue bisecting until you find the specific problem > section. When you know the specific bad section in the file, you > again have the choice of simply deleting that and reconfiguring what's left, > or focusing now on just the bad section and continuing the bisect to the > individual line level, the individual configuration item. Now some > general bisect method observations, based on experience. The first few > times you do it, it'll be hard. But as you get more familiar with the > process and the way each app or family of apps (all of kde in this case) > stores its settings, it'll get much, much easier, as you'll already have an > idea where the problem is before you start, often to the file or just a few > files level, thereby eliminating multiple bisect iterations before you even > start. With kde, the settings tend to be in one of two subdirs, both > under ~/.kde/share. Kde apps with just a few settings, a file or two > worth, generally keep them in ~/.kde/share/config/ . Kde apps with > more settings or data and settings, enough to have a subdir of files, will > use a subdir in ~/.kde/share/apps/ instead. So your problem is very > likely to be in either an appropriately named file in ~/.kde/share/config/ , > or in an appropriately named subdir in ~/.kde/share/apps/ . Knowing > just that already eliminates a bisect iteration or two, and if you can > either guess what subdir/file by looking, or at least eliminate half or more > that you know definitely do NOT apply so you don't need to test them, you > eliminate even more bisect iterations, and with a bit of experience, you'll > often need just one test at the file level to confirm your guess, before > diving into the file itself, should you decide to do so. One > important exception to remember is that some of the newer apps and settings > are in the freedesktop.org standard config or data dirs. Akonadi > settings are one example. ~/.config/ (or other similar location set > either by your distribution, or the $XDG_CONFIG_HOME and $XDG_DATA_HOME > variables, if appropriately set and exported, thus giving the user a way > to change the location, if desired) is used for these, instead of > ~/.kde/. But this is pretty easy to figure out, if the problem doesn't > go away when you backup and remove the entire ~/.kde dir, and now you have a > pointer as to where to look next. =:^) Another option, tho it > requires a bit more skill then bisect, and that you know what specific > application is the problem (thus, it wouldn't work here, since you're not > sure what's causing the problem, only that it occurs over time), is to use > strace, and then grep, running from a konsole window. This works great > if you want to know where a specific app looks for its config, for instance, > or if one is crashing, so you know where to start your bisect as > above. You can check the strace and grep manpages for details on the > options. strace -f -eopen parameters> ... will give you a list of all the files > tries to open as it runs. The problem with just strace is that for the > average modern X based app, especially kde and gnome apps, you'll often have > output of several hundred if not several thousand lines to go thru (several > times that if you were tracing everything, not just file opens). One > thing's for sure, an strace like that really DOES give you an appreciation > of just how much work your computer is doing behind the scenes! But > to filter that output down a bit, you pipe the output to grep, like > so: strace -f -eopen 2>&1 | grep > | grep -v in> The 2>&1 bit is important, as strace's output normally > appears on STDERR, not STDOUT, so it won't get piped to grep unless you > redirect STDERR (file descriptor 2) to STDOUT (file descriptor 1). As > a more real example, try this (replace /home/user as appropriate): strace > -f -eopen systemsettings 2>&1 | grep /home/user/ As that's still a > lot of output, we'll start by filtering out references to icons and cursors > with a second grep: strace -f -eopen systemsettings 2>&1 | grep > /home/user/ | \ grep -v 'icon\|cursor' The \ ending a line simply > tells the shell to continue with the next line, treating them as one. > The -v tells grep to filter these out. As you'll note, I used quotes > on the second grep's search term, so the shell wouldn't try to parse the > pipe (|) and redirect to a command called "cursor". The | means "or" > in regular expression language which is what grep uses, but it has to be > escaped by the \, or it would simply be taken as a literal | symbol. > So the second grep says filter out lines that include "icon" OR > "cursor". Here, for a simple systemsettings run without actually changing > anything, that's actually getting almost manageable, "only" about 60 lines > of output to sort thru. But as soon as you actually start wandering > around in systemsettings, you'll get more output again. You could take > a look, and say, OK, I'm not interested in fonts either, and add that to > your grep -v line, with the appropriate \|, and continue filtering out > additional stuff until you get something manageable. A hint, "ENOENT" > means the file or directory doesn't exist, so if you're only interested in > files that exist, you can add that to your grep -v filter. And if > you're only interested in files in ~/.kde, you can add the subdir to the > first grep. You will also probably see references to your style > config, (oxygenrc, here), that you can filter out, along with > fonts/cursors/icons, but I didn't add here, as if you use a something other > than oxygen, that might have confused you. I'm sure that's WAYYY more > info than you expected, but perhaps it'll be useful, if not to you, maybe to > someone else who ends up reading it. =:^) -- Duncan - List replies > preferred. No HTML msgs. Duncan, Thank you for the very helpful reply. While I haven't necessarily solved the problem, I discovered the dead-simple workaround: - using the mouse, bring up Kicker; - right-click on the K application launcher icon; - choose application launcher settings| Keyboard shortcut; As I feared, the Keyboard shortcut was "None." It was a trivial task to re-enter it. Your bisection method makes such obvious good sense that I was tempted to smack my forehead in frustration and shout out loud, "Why didn't I think of that?' And all this time, I had never actually blown away the ~/.kde tree. I always renamed it and moved it to a "cool dry corner" of the home directory. Kubuntu's implementation of the KDE4 control is called "SystemSettings" (with no space between the two English words). Under the drop-down for keyboard and mouse | global keyboard shortcuts | plasma-workspace there is no entry for an Application Launcher Widget. The only entry is for the Widget Dashboard. Nor do I find a reference anywhere else in the large SystemSettings context to defining a keyboard shortcut for Kicker. Since this appears to be a question of Kubuntu's implementation of the KDE function (and not a core matter within KDE itself), should I be filing a bug report on Launchpad (the Ku/Ubuntu bug tracker)? Thanks once again for all the help. Bruce -- Bruce Miller, Ottawa, Ontario, Canada bruce@brmiller.ca; (613) 745-1151 Just when you think your software is idiot proof, somebody comes up with a better idiot Keyboard not found...Press any key to continue. ----- Original Message ---- > From: Boyd Stephen Smith Jr. > To: For people using KDE on Linux with related questions/problems > Sent: Sat, April 17, 2010 11:35:21 AM > Subject: Re: [kde-linux] Alt-F1 shortcut (Kicker) disappears > > In < > href="mailto:126762.5191.qm@web88305.mail.re4.yahoo.com">126762.5191.qm@web88305.mail.re4.yahoo.com>, > Bruce Miller wrote: >I have an recurrent problem with KDE 4.x in which the > Alt-F1 shortcut ceases > to function. The Alt-F1 shortcut brings up Kicker > and the panel (what, in > another OS's terms, is called the "Start > Menu"). Kicker was an application in KDE 3.x that provided one or more > docked panels. It wasn't the only one for KDE 3.x. In KDE 4.x > there is no more kicker application. Instead the panels are handled by > the same thing that handles wallpaper and widgets: plasma-desktop. As far > as Alt+F1, I seem to remember that it works with "Application Launcher Menu" > and "Lancelot", but that "Application Launcher" (the default) has issues > with it. You should read the archives, it came up earlier this > year. -- Boyd Stephen Smith Jr. > ,= ,-_-. =. > href="mailto:bss@iguanasuicide.net">bss@iguanasuicide.net > ((_/)o o(\_)) ICQ: 514984 > YM/AIM: DaTwinkDaddy `-'(. .)`-' > href="http://iguanasuicide.net/" target=_blank > >http://iguanasuicide.net/ > \_/ ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.