KGlobalAccel issues

[Hamish Rodda]

On Wednesday 02 August 2006 02:38, Lubos Lunak wrote:
> 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.

Great.

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

Thanks.

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

Sure... are the 4 modifier versions going to be saved somewhere? (or are they 
already...)

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

Hmm, a valid point but I think when you do X grabs, you're presenting a _very_ 
modal window and are uninterested in allowing global accels to other apps, 
and I guess it would be a design flaw to intend for an action with a global 
accel to be enabled here.

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

Use KActionCollection::setEnabled()

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060802/4569d76e/attachment.sig>