Popular Keyboard shortcuts (Was: RFC: KDE4, KMix and a public Mixer API)
Christian Esken
esken at kde.org
Wed Oct 11 21:51:24 BST 2006
Am Mittwoch, 11. Oktober 2006 14:17 schrieb David Faure:
> On Wednesday 11 October 2006 14:05, Lubos Lunak wrote:
> > On Wednesday 11 October 2006 12:47, David Faure wrote:
> > > On Wednesday 11 October 2006 12:38, Lubos Lunak wrote:
> > > > > (And such a redesign could also fix the current #include of cpp files
> > > > > hacks to make up the kcontrol module for global shortcuts; instead apps
> > > > > could install some files and the kded and kcontrol modules could read
> > > > > from that, for instance).
> > > >
> > > > I somehow doubt that the increased complexity would make up for just
> > > > avoiding the few #includes.
> > >
> > > The point is that apps not in kdebase would be able to have configurable
> > > global shortcuts too, which isn't the case currently.
> >
> > It is. They just don't show up in the kcontrol module, but it's a question if
> > they should anyway. It's already a bit crowded and would I really go there to
> > configure shortcuts e.g. for a media player?
>
> I would certainly find it useful to have all global shortcuts visible in one place, in order to
> 1) be able to figure out why a certain key combination triggers something in kde, without
> knowing exactly which app it's triggering
> 2) be able to choose a global shortcut without creating conflicts with another app that is
> already defining that global shortcut.
3) be able to find out, which app is holding the global shortcut at the moment. Useful if the shortcut is taken, but currently doesn't trigger anything (example: XF86AudioStop assigned to an Application that has no playing media).
It could also help in detecting double assignments of global shortcuts. I am unfortunately not aware why KDE currently is not able to detect that a global shortcut is already taken.
Christian
--
Is Unix ready for the Desktop? See http://www.kde.org
More information about the kde-core-devel
mailing list