From kde-core-devel Thu Mar 29 16:52:19 2007 From: Andreas Hartmetz Date: Thu, 29 Mar 2007 16:52:19 +0000 To: kde-core-devel Subject: Re: KDE4 default shortcut theme Message-Id: <200703291852.19828.ahartmetz () gmail ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117518705916186 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). > > 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