KDE4 default shortcut theme

[Andreas Hartmetz]

On Thursday 29 March 2007 18:29:41 Ellen Reitmayr wrote:
> On Thursday 29 March 2007 18:00, Andreas Hartmetz wrote:
> > On Thursday 29 March 2007 16:29:34 David Faure wrote:
> > > On Thursday 29 March 2007, Lubos Lunak wrote:
> > > > On Thursday 29 of March 2007, Thomas Zander wrote:
> > > > > On Thursday 29 March 2007 12:52, Andras Mantia wrote:
> > > > > > On Thursday 29 March 2007, Ellen Reitmayr wrote:
> > > > > > > On Thursday 29 March 2007 11:58, Andras Mantia wrote:
> > > > > > >
> > > > > > >
> > > > > > > as an alternative. alt only works in combination with an
> > > > > > > accelerator keys.
> > > > > >
> > > > > > No, pressing Alt alone focuses the menu
> > > > >
> > > > > Yes, and the first time I saw it was in Win95.  Which IMO makes it
> > > > > a standard.
> > > >
> > > >  Which however doesn't necessarily mean that much, as there's
> > > > another "standard" called pressing Win alone opens the system menu.
> > > > Which we've tried to implemented and eventually gave up. They're
> > > > about the same. Or, to complete the list, yet another similar
> > > > (mis)feature is pressing Ctrl alone shows accesskeys in KHTML.
> > >
> > > Yes. All three single-modified-shortcuts tend to trigger by mistake.
> > > I have seen my wife fight with kmail which wouldn't accept key input
> > > anymore after pressing Alt by accident.
> > > And I am annoyed by accesskeys showing up on Ctrl alone like everyone
> > > else, of course.
> > >
> > > Alt alone should go. But F10 alone ... a very common shortcut for many
> > > things (kdevelop, new folder in konqueror...)... I would have suggested
> > > Ctrl+F10 (to still be near the F10 standard that Ellen says is used by
> > > other DEs), but she's already suggesting that one for something else...
> > >
> > >
> > > About Ctrl+R for reload: the standard action already has Qt::Key_F5 and
> > > Qt::Key_Refresh (what's that? there are keyboards with a Refresh key?).
> > > Konq replaces the latter with Ctrl+R - we have room for only two
> > > alternate shortcuts; hmm, I wonder if this limitation still stands at
> > > the technical level, or only in the API...
> >
> > It's only in the API. QAction now has setShortcuts(QList<QKeySequence>).
> > KDE ignores any shortcuts after the second two everywhere, however. They
> > will still trigger an action, but they won't get saved when changed, are
> > not configurable in KKeyDialog, etc.
> > All this could be changed with some nontrivial effort.
> >
> > KKeyDialog ATM cannot resolve shortcut conflicts involving more than the
> > first or second key sequence. It's simply an UI problem to deal with an
> > arbitrary list of arbitrary lists of shortcuts.
> > For example, in a QTreeView, you cannot open a subtree with its root in a
> > column different from the first.
> >
> > A possible solution goes like this:
> > I made a thing called "KExtendableItemDelegate" that lets you put an
> > arbitrary QWidget that spans all columns under an item (of any column) in
> > a list-like itemview, which could be used there. It was originally
> > intended to be used in KKeyDialog, though not exactly as outlined here.
> > Ellen and me discussed a design using it, but that one is centered around
> > "one column for one key sequence".
> > Maybe it could be adapted to look like this:
> > (Some tricks required, but doable. Will Qt get faster drawing code for
> > QTreeWidget in time?)
> >
> >
> > Name	shortcut			rocker gesture				shape gesture
> > (foo)		^ Ctrl+A;Ctrl+B	^ Hold left, push right		(pic) line
> > (bar)		^ Ctrl+B;Ctrl+C	^ Hold right, push left		(pic) square
> > (baz)		v Ctrl+D; Ctrl+E;F12	^ Hold middle, push right		(pic) circle
> > 		Primary:	[x] Default : Ctrl+D
> >   Q->				[ ] Custom: { None } <- a KKeyButton
> >   W		------------------------------------------------------------
> >   i		Alternate:	[ ] Default : Ctrl+T
> >   d				[x] Custom : { Ctrl+E }
> >   g		------------------------------------------------------------
> >   e		Extra 1:	[ ] Default : None
> >   t				[x] Custom : { F12 }
> >   !		------------------------------------------------------------
> >   v		Extra 2:	[x] Default : None
> > 				[ ] Custom : { None }
> >
> > (blah)	^ Ctrl+F			^ Hold middle, push left		(pic) triangle
> >
> >
> > There would always be one more shortcut configuration widget visible that
> > is set to "None". As soon as it is set to something, another one would
> > appear. Default and Custom could be put in the same row to save vertical
> > space.
> >
> > Ellen?
>
> IMO better don't offer this. Two alternative shortcuts should really be
> enough - the danger that too many keyboard shortcuts are taken by the
> system is really too high then.
>

Especially together with Jakob Petsovits' idea to redistribute all shortcuts 
and use a clear pattern this time, yes.
For things like the refresh action (F5, Ctrl+R, Refresh key) this could be 
handled like this:
- drop Ctrl+R, it's marginally easier to reach than F5 but much harder to 
remember because all applications use F5.
- assuming this wasn't the case: make keys like the "Refresh" special key 
fixed, not configurable, refuse to reassign them to anything else. Could be 
handled by a new function KShortcut::setFixedShortcut() without much effort.


> /el