[kde-linux] [SOLVED with thanks] Re: Alt-F1 shortcut (Kicker) disappears
Bruce Miller
subscribe at brmiller.ca
Sat Apr 17 16:32:50 UTC 2010
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 at cox.net>
>
To: kde-linux at 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 <app> <app options and
> parameters>
... will give you a list of all the files <app>
> 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 <app and parameters>
2>&1 | grep
> <path you're interested
in> | grep -v <stuff you're not interested
> 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 at 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. <bss at iguanasuicide.net>
> To: For people using KDE on Linux with related questions/problems <kde-linux at kde.org>
> Sent: Sat, April 17, 2010 11:35:21 AM
> Subject: Re: [kde-linux] Alt-F1 shortcut (Kicker) disappears
>
> In <
> href="mailto:126762.5191.qm at web88305.mail.re4.yahoo.com">126762.5191.qm at 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 at iguanasuicide.net">bss at iguanasuicide.net
> ((_/)o o(\_))
ICQ: 514984
> YM/AIM: DaTwinkDaddy `-'(. .)`-'
> href="http://iguanasuicide.net/" target=_blank
> >http://iguanasuicide.net/
> \_/
More information about the kde-linux
mailing list