KParts, KXMLGUI and nightmares

I would not want to say a word against the KDE application development framework, no, certainly not… And if Krita’s development has stagnated for a week or two, it’s entirely because I am too dim to grasp certain aspects completely. Especially the plugin/xml gui framework. Probably not because the framework is overdeveloped, underdocumented and designed for a quite different kind of application.

Consider the situation: Krita loads most of its functionality in the form of plugins. A lot of plugins, about thirty at the moment of writing, with more to come. Some of these plugins can be accessed from the GUI, with either a menu entry or a toolbar button.

A clear case for KParts and KXMLClient — and so it would be, if loading all those plugins every time a new view is created wasn’t so darn expensive. Besides, I want to manage the plugins. Be able to add comboboxes with all the filters and toolboxes with all the paint operations to dialogs and windows; and I don’t want to instantiate more objects than necessary.

But if I use the default KParts framework, every time a view is created, it looks as if all the plugins are searched, opened, loaded, created and added to the gui.

If I don’t use the default KParts framework, but load the plugins myself and keep a factory class in a pointer list, then when I create the plugins for a certain view, they are not added to the gui.

Now this problem isn’t unique. I have nosed around a bit, and it looks that at least Kate and Digikam have solved this problem, both by wildly divergent means, and I’m quite sure they are not the only KDE application that have hacked a plugin management layer around KParts.

Krita being a KOffice application complicates matters a lot, because a KOffice application is a complicated subclass of KXMLClient — and that appears to mean that adding dynamic menu entries is hard, too.

So now I’m faced with a hard decision: go back to the old code and tweak it to have al least the paint ops loaded as plugins, or try to slug it out, copy perhaps some code from Kate — I’m a bit desperate at the moment, because what I really want to do is create a new interface for Krita, one where there is a really small toolbox with the basic tools, and a QToolBox widget (like in Qt Designer) that holds all the nice stuff, such as brushes, fill types and filters for the filter tool. But to do that properly, I need to have the plugins working.

Or… Maybe if I just store the pointers to the plugins in my registry singletons for filters, color models, paint ops and all the rest… Must be worth a try.