Shortcut Scheme support

Andreas Pakulat apaku at
Sun Sep 28 22:55:03 BST 2008

On 28.09.08 22:15:11, Ingo Klöcker wrote:
> On Sunday 28 September 2008, Michael Jansen wrote:
> > > > But we talk about many applications here. I would say all.
> > >
> > > I'd say its not all, in particular KDevelop, kwrite and kate do not
> > > suffer from this. And I think (not 100% sure though) kpat, ksudoku
> > > and lskat also not.
> > >
> > > > It's the difference
> > > > between worked - - not correct, but no one noticed - against does
> > > > not work anymore and nothing was changed on their side. It's a
> > > > gross behavioural change and as such not acceptable if you ask
> > > > me. It worked. It should keep doing that.
> > >
> > > Now I'm confused. I thought it never worked reliably, at least
> > > thats what
> >
> > The code should set the default shortcut. But using
> > QAction::setShortcut you set the active shortcut. The code works as
> > in the action can be triggered with the shortcut. It fails in
> > providing a default shortcut. If the user ever changes the shortcut
> > he cannot reset it with the global shortcutseditor to the default
> > value. It could be even weirder in that it is possible to get it back
> > after an application restart. I don't care enough to test that.
> KDE applications written for KDE 4.0 or 4.1 are supposed to work with 
> all versions of KDE. Breaking this contract by such a major behavioral 
> change is IMO a no-go.

There never ever was a contract that QAction::setShortcut would work
properly in a KDE app. So there's no contract being broken. We just expose
the brokeness of apps more now, instead of hiding it in subtle
hard-to-debug bugs.

> I mean it's not as if the change fixes a major bug. AFAIU, if anything
> then it fixes a minor weirdness.

No, actually the change thats being discussed implements a really needed
feature, overriding a kpart's shortcut setting in a kpart-embedding

> So I suggest to note it down for KDE 5 and revert it for KDE 4 unless you
> can come up with a clever workaround for all the third party KDE
> applications we do not even know about.

So, you say its better to have shortcuts in applications behave in weird
ways when they use QAction::setShortcut is better than them exposing a
clearly visible bug? I disagree completely, a visible bug is always better
than subtle weird behaviour thats not easily spotted - IMHO.


Abandon the search for Truth; settle for a good fantasy.

More information about the kde-core-devel mailing list