guiFactory() in KTextEditor::MainWindow

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Mon Jan 6 15:17:14 GMT 2020


Hi!

I'm currently in the process (long overdue) of getting kate plugins to
work in RKWard. One thing that is causing me a mild headache in this
context is the presence of
  KXMLGUIFactory* guiFactory()
in the KTextEditor::MainWindow interface. The problem here is, that I
would like to keep a bit more control about when an where plugins plug
their actions. E.g. right now, all views (including tool views) in
RKWard can be detached as separate windows, and re-attached to the main
window. Further, the menu actions of inactive views are hidden (client
is removed from the KXMLGUIFactory), and re-enabled when activated.

I'm not claiming either is the one-and-only right way to go, but I'd
certainly like to keep these features. That is a bit difficult if
plugins start modifying the UI, directly.

Now I am not entirely sure that I have found all uses of
KTextEditor::MainWindow::guiFactory(), but _almost_ all are either:
  guiFactory()->addClient(this);
  guiFactory()->removeClient(that);

The odd one out appears to be the externaltoolsplugin, which uses
guiFactory() to get a pointer to the "file_save_all"-action. This last
one looks a bit hackish to me in the first place, and could probably be
rewritten to use findChild<KActionCollection*>() on the top-level
window, instead.

For the regular usage, I would like to suggest to
1) Deprecate KTextEditor::MainWindow::guiFactory()
2) Add new interface functions
  KTextEditor::MainWindow::addClient(KXMLGUIClient *);
  KTextEditor::MainWindow::removeClient(KXMLGUIClient *);

With these, the embedding application would have the choice of either
passing to the KXMLGUIFactory as before, saving pointer to the clients
for later, adding them as children to other KXMLGUIClients (for
example), and possibly doing other fancy stuff such as modifying their
menu layout and shortcuts.

Long story, short question: If I were to create a patch / review
request for the above suggestion, would it stand any chance of being
accepted, or am I overlooking something.

Thanks!
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20200106/2482b604/attachment.sig>


More information about the KWrite-Devel mailing list