KGlobalAccel issues

Lubos Lunak l.lunak at suse.cz
Tue Aug 1 17:38:42 BST 2006


On Saturday 15 July 2006 01:49, Hamish Rodda wrote:
> On Friday 14 July 2006 23:22, Lubos Lunak wrote:
> > - It doesn't work. Whoever ported the code consistently used
> > KAction::setShortcut() instead of KAction::setGlobalShortcut(). I'll
> > check all those set in KControl

 Done.

> > - It doesn't work. What's the point of
> > KAction::setGlobalShortcutAllowed()? If a KAction has a global shortcut
> > set, it wants to use it, so why does this flag exist at all?
>
> I got some feedback when I was doing the development that even though all
> actions can now have global shortcuts, it shouldn't mean we should allow
> the user to assign one to whichever action they liked.  So I added this
> flag and set it to false by default.  I guess setGlobalShortcut should
> automatically enable the allowed flag.

 Ok, done.

> > - It finally works, but only if I use all kinds of funny shortcuts,
> > because somebody changed all shortcuts to the 4-modifiers scheme by
> > default.
>
> Well, I guess that was because the separation in the code between 3 and 4
> modifiers went away.
>
> > What
> > exactly is the plan with schemes here? If we default to 4-modifiers I
> > expect many people won't be that happy for their shortcuts suddenly
> > changing, people with only 3-modifier keyboards probably won't be that
> > happy either. If I pass both variants to KAction::setGlobalShortcut()
> > then both will be used if I'm getting it right, which is not desired
> > either.
>
> Well, with this being removed (I assume for a good reason), we'll need an
> alternate way to do this now... perhaps apps could detect which shortcut
> config is in use and adjust accordingly?

 Hmmm ... since we have (we still do, don't we?) the kcontrol module where one 
can select the layout scheme and all the global shortcuts are forced to be 
written to the config file during KDE startup, what's actually written in the 
source file should matter only for a) the defaults and b) the case when 
somebody uses it outside of KDE without ever changing the scheme or using KDE 
the desktop.

 For both of these cases I think it should default to 3 modifiers - people are 
used to them, not all keyboards have them, whatever. The kcontrol module can 
even default to something else if somehow find out which one would be the 
best. So unless you have a better idea, I'll make the code use only the 3 
modifiers shortcuts instead of 4 modifiers.

> > - Some global shortcuts in KWin are of the form "do something with X",
> > where X is a number in a range (like, "window to desktop 1" to "20").
> > KDE3's KGlobalAccel allowed connecting a slot with int argument and
> > passed that number to it, that doesn't work now. Should I just make
> > separate slots? Not that I mind doing that, I just want to know.
>
> I didn't realise that was possible.  It's not possible now, and I'd say
> that creating separate actions for each action makes sense, unless there
> was a compelling reason for readding this.

 Not really, I just wanted to make sure.

> BTW, other my plan for KGlobalAccel is to move it out into a kded module
> which communicates with apps via dbus.  This will help with centralising
> configuration, be generally more efficient, and further eliminate the
> requirement for KApplication.

 I wonder a bit if this won't cause some problems with X grabs (either 
keyboard or global) - right now an app with such grab normally gets even 
KGlobalAccel events, but this way it wouldn't. On the other hand I guess it 
doesn't make really sense to use KGlobalAccel in such case. Anyway.

 There's one more thing I noticed - KGlobalAccel is now a singleton. How is 
one now supposed to disable a group of shortcuts?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/




More information about the kde-core-devel mailing list