Skip to content

Add KActionCollection::configureActions() to support adding actions at runtime

David Hurka requested to merge davidhurka/kxmlgui:second-try-configure-actions into master

This adds KActionCollection::configureActions(QList<QAction *>), which calls KXMLGUIFactory::refreshActionProperties.

refreshActionProperties gets a QList<QAction *> parameter, so it is possible to specify which actions to refresh. This shall avoid side effects on other actions.

KXMLGUIFactoryPrivate::refreshActionProperties() in turn is adjusted to respect this parameter. This has the bonus effect that KXMLGUIClient::plugActionList() will no longer refresh all actions, but only the newly plugged ones.

Example

graphics/okular!251 (closed) tries to construct actions at runtime. Then it used to call KXMLGUIFactory::refreshActionProperties() to apply user configured shortcuts on these actions.

For an unknown reason, this has unintended side effects on most other actions, resulting in resetting all other user configured shortcuts.

Without refreshActionProperties(), however, the newly constructed actions have no user configured shortcuts.

With KActionCollection::configureActions() it seems to work fine.

Another potential usage: graphics/okular!246 (closed) (Both use cases involve user configurable tool sets, that is why the action set changes at runtime. plugActionList() sounds interesting here, unfortunately I don’t know where to read about that concept.)

TODO

  • As noted in doxygen, configureActions() works only for KXMLGUIClient’s action collections. If this MR should actually land, it is probably desirable to make it work for “plain” action collections too, probably by adding a KConfigGroup parameter like in readSettings().
    • Configuring actions directly in addAction() seems inefficient to me. I could imagine that this makes sense anyway, because Kiosk authorization is done directly in addAction() too. Automatic configuration could happen e. g. in the next event loop.
  • I am still curious why refreshActionProperties() fails on actions which are not constructed at runtime, i. e. why it doesn’t know about user defined shortcuts when called at runtime. See Bug 384700 or Bug 411492.
    • Might this be related to merging XML descriptions of different clients? I. e. the merged XML knows about user defined shortcuts, while the clients’ XMLs are not updated until restart.
  • This is my first time inside KXMLGUI, I don’t really know how stuff works here. Feel free to give feedback. :)
    • To make this easier in the future, I would be happy to help improving documentation. Example: plugActionList().

Merge request reports