[kde-linux] [SOLVED with thanks] Re: Alt-F1 shortcut (Kicker) disappears

Duncan 1i5t5.duncan at cox.net
Sat Apr 17 17:22:08 UTC 2010

Bruce Miller posted on Sat, 17 Apr 2010 09:32:50 -0700 as excerpted:

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

I'm honestly not sure.

I actually have two such entries here.  But as I mentioned, I heavily 
customize, so have multiple panels and multiple launchers, kickoff (which 
I see from another post you recognized you had mixed up with kicker), 
classic (but not with the apps menu, only systemsettings and bookmarks), 
sometimes I add lancelot for awhile...  I've moved it between panels and 
had several on different panels all at the same time on an occasion or two 
as I experimented with various layouts, etc.

So it wasn't particularly surprising for me to see two entries, as I 
figured (and still figure) it has something to do with the various 
experimentation I've done that has left me with my current plasma config.

But why you have no entry... I don't know.

But as I said, and as you discovered, individual plasmoid settings offer a 
keyboard shortcut option, that seems the simpler way to set it, once you 
figure it out, at least.  And as long as that works, here, I'd not bother 
filing a bug on the other, which of course would mean I'd not need to 
figure out whether to file it with my distribution or with kde.  But of 
course that's up to you.

Glad you liked the bisect method, tho.  I had come up with the idea on my 
own back in the 90s, on the MS platform of the day, but simply called it 
the trial and error method.  However, I've been testing still in-
development Linux kernels for awhile now, and a few years ago, they had a 
testing howto in their documentation that described something similar for 
the kernel.  Now, with git, it's even more formalized, as git has its own 
bisect command, pretty much automating the process for kernel testing.  
You tell it which kernel version was the last one that worked correctly, 
and the first one that you tried that broke, and it'll give you one pretty 
close to half way in between to try.  You test it and tell git whether 
it's good or bad, and it'll again give you one about half way thru the 
remaining bad area.  Etc.  And the bisect name is so nicely descriptive, 
since I learned about git bisect, I've used the same name when describing 
the manual process when looking for config errors.

The biggest issue with bisect, other than the patience it requires, is 
that occasionally, there's complex problems that have two different 
triggers, or where where an actually correct and functional on its own 
option, triggers a bug in something else.  Those are rather more 
difficult, occasionally impossible, to reliably pin down with the bisect 
method, but fortunately, the single triggering issue is still the most 
common (or there are more triggers but they don't apply for some reason, 
so it's just one that shows up), and even where the wrong thing is 
pinpointed, often, particularly with the kernel, that still is a clue that 
the kernel devs can use to find the real problem.  What's great about it, 
tho, is that you don't have to know how to read a line of source code in 
ordered to help find and fix kernel issues, and I've spotted and reported 
a number of bugs in my testing, that were therefore fixed before the full 
kernel release.  That's a very nice feeling to have, especially for 
someone that doesn't read C and thus can't do actual kernel development. 

KDE is in the process of switching to git (from subversion) as well.  
While I don't run the kde testing versions now (heh, until 4.4, the 
releases were testing enough!), there's a decent chance that I might at 
some point in the future be doing git bisects for kde as well. =:^)

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

More information about the kde-linux mailing list