Plugin vs krita/ui code

[Sven Langkamp]

On Wed, Feb 20, 2013 at 7:50 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Wednesday 20 February 2013 Feb, Sven Langkamp wrote:
>> Hi,
>>
>>
>> I have recently been looking through the plugins and I noticed that
>> most of the code is still in the krita/ui. Especially in various
>> managers we still have much action code. Beside that we have many
>> methods there which pass through something, so we have some cases
>> where a manager calls another manager. I think we should put more code
>> into the plugins e.g. methods which are just used by one plugin or
>> just have 1-2 lines of code. Even the other code should be moved to
>> action factories.
>>
>
> I think the main reason the managers have these actions was to enable/disable them, even though for instance the selection manager already had a workaround for that. And with your action manager, that's not needed at all anymore. On the other hand, with an eye to the future, I really want to get rid of all kparts-based plugins, and iirc, most of the view plugins are still kparts. I think that we need to sit down in Essen and make a real plan for getting rid of kparts, making plugins' actions reachable from other types of view than a KPart view and maybe even start thinking about getting rid of the dependency on KDialog and the widget/state conflation in filters and paintops.
>
> Lots of items on this list, but with the experience of krita sketch and so on, we should be able to come up with a plan.

Yes, the action manager it's already working towards that goal. I have
already created a new class KisViewPlugin which is currently a KParts
plugin, when we switch away from KParts plugins we only need to change
that. I have already moved most plugins to that. Going back to just
XMLGUI would be possible

In the long run I want to give every action, settings widget and the
implementation a unique id. That will allow us to dynamically switch
between different UIs at run time. We are almost at that point, we
already have KisAction we just need an additional id string, for the
execution we have KisUiActionFactory which already has it. The missing
link is just the UI part. I agree that we should split out dialogs and
widgets. I already have thought about a system that could do that and
was just waiting for the sprint to start with that. Currently I'm
cleaning up the code to prepare for that.