kxmlgui shortcuts regression

Andreas Pakulat apaku at gmx.de
Sat Sep 20 02:00:24 BST 2008

On 19.09.08 22:55:52, Michael Jansen wrote:
> On Friday 19 September 2008 13:56:24 Nick Shaforostoff wrote:
> > Hi.
> >
> > Shortcuts specified using QAction::setShortcut() (before calling
> > createGUI()/setupGUI()) stopped being respected:
> > actions show w/o any shortcut in application now. I saw this in
> > Lokalize and Gwenview.
> > Currently, only kstandardactions have shortcuts be default.
> I didn't understand what you meant with the above paragraph. annma kindly 
> showed me the problem. May i suggest next time to show exactly how to 
> reproduce the problem step by step?
> The problem is no regression in kde code. It's a problematic use of it. Even 
> if KAction inherits QAction it is not possible to override QActions 
> setShortcut method. It is not virtual. As lokalize sets the shortcuts using a 
> QAction* kdes code never had the chance to do things properly.
> NEVER DO THAT. Never call setShortcut over an QAction* if the action is a 
> KAction.

Damn, I knew I forgot something last night - when I read Nicks mail that
was my first idea. Can you print that in REALLY BIG LETTERS on the
frontpage of the KAction class documentation please.
> > Also, while I'm on this topic, I'd like to complain:
> > -If I change shortcut for some action from default to any other
> > (currently this is possibly only for kstandardaction -- see above),
> > then change it back to default not by selecting 'Default', but by
> > typing it, then
> > the 'Custom' field gets autocleared, although it stays selected
> > (while obvious behaviour would be to autoselect 'Default')
> You mean selected as in has the focus? That i can reproduce.
> Selected as in "the radio button is down" is defaults. Sorry i have no idea to 
> express this better.

I'm not seeing the behaviour that Nick see's, but something even worse.
I'm doing this in KWrite:

- Open Shortcuts editor
- Expand "Capitalize" (default shortcut is Ctrl+Alt+U)
- Set a custom shortcut, say "b"
- Again push the button to adjust the shortcut and type the default
- For me the "Default" entry is now selected - as in the radio button is
  checked and the button to change contains "None" again.
- However the button still has focus, indicated on my machine by having
  the letters in bold.
- Now I click Ok
- Re-Open the shortcuts editor and voila, Capitalize as _no_ shortcut
  set and the radio button upon expansion is set to "Custom <none>"

Thats really bad because you don't see this happen, unless you re-open
the dialog. If you don't have time to look into this anytime soon, I can
file a bugreport.

> > -I use KXmlGuiWindow::guiFactory()->addClient() and removeClient() to
> > embed other KXmlGuiWindows,
> > and when I change shortcuts for actions from subKXmlGuiWindows:
> > --currently: shortcuts stop being effective
> > --previous behaviour: changes get applied only after restart.
> Could you please give a use case? I have no idea what you are talking about. 
> But perhaps david can help you as in "know that beast kxmlguiclient".

Lets take KDevelop (though in theory even konqueror with multiple tabs
should do):

- open two file, you get two tabs. Lets say fileA and fileB
- Focus fileA and open shortcuts editor
- change a shortcut thats specific for the xmlgui-client - i.e. not part
  of the application. In my example I'm changing "Capitalize" which is
  a katepart shortcut, to Meta+Ctrl+C
- close the editor via "ok"
- check wether the shortcut works, for me it does
- Switch to fileB by clicking on the tab or using Alt+Left/Right,
  doesn't matter
- try the shortcut, it doesn't work. Go to the shortcuts editor and see
  that the shortcut for the action is back to Default, i.e. Ctrl+Alt+U
  in the case of Capitalize

Now I'm not sure where the error is in this case, wether its the xmlgui
framework not notifying its clients about changes in the shortcuts, or
the clients not doing the right thing or wether the app is responsible
for notifying the clients. But somethings wrong for sure.

Give thought to your reputation.  Consider changing name and moving to
a new town.

More information about the kde-core-devel mailing list