recording

[Sven Langkamp]

On Sun, Mar 25, 2012 at 6:36 PM, Cyrille Berger Skott
<cberger at cberger.net>wrote:

> On Sunday 25 Mar 2012, Dmitry Kazakov wrote: > On Sun, Mar 25, 2012 at
> 3:33 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> > > On Sunday 25 March 2012 Mar, Cyrille Berger Skott wrote:
> > > > On Sunday 25 Mar 2012, Boudewijn Rempt wrote:
> > > > > This topic is getting too large... What I basically meant was that
> we
> > >
> > > need
> > >
> > > > > to find some way to automatically generate the code that does the
> > > > > recording/executing -- we cannot fix up all that code by hand!
> > > >
> > > > I don't really see how you can automate that.
> > >
> > > The only thing I can see is to generate code from a description -- but
> > > I'm not sure of the details yet.
> >
> > I don't see how we can do that either
> Or how it would be quicker...
>
> The way I see things, we need:
>
> 1) unify the stroke and action recorder
> 2) port everything to the united framework
> 3) not allowed new action to be added if they don't make use of the united
> framework
>
> And 2) makes a nice junior job (for a few actions at a time, otherwise we
> would lose the new dev :) ).
>

I have thought about that and a new system to do it. The basic idea is to
use KisPropertiesConfiguration for every action in Krita that isn't
recorded currently.

Currently we have this situation: Usually that is either a simple action
that the users hits or an action that is caused by larger dialog (also
tools). The the dialog or plugin calls some method e.g. in some manager
which then runs some stuff.

Disadvantages or this:
1) Plugin calls directly, so we can intercept the call and record it
2) The UI is in a dialog and can usually not be reused in the macro editor
3) Plugins can only call methods in the plugin or the krita image/ui, but
not other functionality from other plugins so we can't turn more things
into plugins
4) For scripting the functionality needs generated bindings which is
complicated and didn't work very well in the past

The new system looks like this:
http://i.imgur.com/xU3Kd.png

Explanation:

Command: A command is contains basically two things: 1) an id string to
identify the command 2) a KisPropertiesConfiguration that contains the
parameters

Command Widget: That's the ui for the command like the current dialog, but
closer the filter widgets (and paintop options). It writes the input of the
UI into the KisPropertiesConfiguration like we do for filter. Then the
command is send to the command switch.

Command switch: This is like a normal network switch. A command comes in
and the switch looks at the id and passes it to the command runner that is
associated with the id of the command. It's also a big registry for command
runners, which are registered by Krita or plugins.

Command runner: The class or plugin that executes the command.


This solves the disadvantages I pointed out above:
1) We already know how to record filter and this is practically identical
and compatible with the old recording framework
2) Like the filter widgets we can read and write from a
KisPropertiesConfiguration, splitting the widgets from the dialogs from the
dialogs is a lot of work so I would start with just saving
3) Plugins can register runners that can then be used by other plugins
4) Scripting would be easier as we would just have to map everything on a
KisPropertiesConfiguration. Although it's not as convenient as a real
binding.

There is also a small disadvantage as the call gets a bit slower because we
need to write/read the configuration and lookup the runner. Though it's
unlikely that you would ever notice that.

Implementation:
I haven't started yet as obviously this would be quite a big change
(probably bigger than I imagine ;). There is no way to do that
automatically, I think. Every action needs to be split and then added the
configuration code manually.

If you are not scared by this point, you should be ;)
Comments?


Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120507/8d47687c/attachment.html>