KDE4 default shortcut theme

[Andreas Hartmetz]

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?

Cheers,
Andreas