KDE4 default shortcut theme
Andreas Pakulat
apaku at gmx.de
Thu Mar 29 13:47:43 BST 2007
On 29.03.07 15:26:38, Alexander Dymo wrote:
> On Thursday 29 March 2007 14:54, Andreas Pakulat wrote:
> > > Can we have that preference implemented please?
> >
> > I strongly object. This will introduce a mess. People needing shortcuts
> > will use them in Krita happily (for example F6 to switch to
> > image-displaying-widget) and then they start KDevelop and F6 is bound to
> > Build and they have to re-learn.
>
> I understand that. But there're not only KDE programs which users run.
> We (KDevelop) can take care about non-clashing shortcuts. But will other
> developers outside KDE do that? I don't think so.
>
> In any particular case it's much easier to blame/fix an application rather
> than DE.
>
> Also we have applications that set global shortcuts (like konversation, amarok
> and others do). This is the case when I'd strongly prefer local application
> shorctut over global one. We can't take care about all possible combinations
> of applications setting global shortcuts.
> Btw, Amarok has a great solution. They use Win-... keys that are almost
> guaranteed not to clash. What if we set this as a policy?
Not every keyboard out there has a win-key.
I think Cyrille's idea is good: Make it configurable, but off by
default. This would easily work with KDE apps.
About the case where users use non-kde apps: KWin allows to set special
properties for a window or app, like transparency and other stuff. So if
there's a way to know for KDE wether a given app "consumed" a keyboard
action this would provide a way for non-kde apps too. Then you could set
via the window-menu or somewhere in kcontrol, that a given apps key
shortcuts should have precedence over the global one and the
global-keyboard-shortcut-code only jumps in if the app didn't handle the
shortcut. As I said, I have no idea if/how that would work code-wise,
but I think it would provide a decent solution to the problem.
Andreas
--
You have literary talent that you should take pains to develop.
More information about the kde-core-devel
mailing list