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