<div class="gmail_quote">On Sun, Mar 25, 2012 at 6:36 PM, Cyrille Berger Skott <span dir="ltr"><<a href="mailto:cberger@cberger.net" target="_blank">cberger@cberger.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Sunday 25 Mar 2012, Dmitry Kazakov wrote:
> On Sun, Mar 25, 2012 at 3:33 PM, Boudewijn Rempt <<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>> wrote:<br>
> > On Sunday 25 March 2012 Mar, Cyrille Berger Skott wrote:<br>
> > > On Sunday 25 Mar 2012, Boudewijn Rempt wrote:<br>
> > > > This topic is getting too large... What I basically meant was that we<br>
> ><br>
> > need<br>
> ><br>
> > > > to find some way to automatically generate the code that does the<br>
> > > > recording/executing -- we cannot fix up all that code by hand!<br>
> > ><br>
> > > I don't really see how you can automate that.<br>
> ><br>
> > The only thing I can see is to generate code from a description -- but<br>
> > I'm not sure of the details yet.<br>
><br>
> I don't see how we can do that either<br>
</div></div>Or how it would be quicker...<br>
<br>
The way I see things, we need:<br>
<br>
1) unify the stroke and action recorder<br>
2) port everything to the united framework<br>
3) not allowed new action to be added if they don't make use of the united<br>
framework<br>
<br>
And 2) makes a nice junior job (for a few actions at a time, otherwise we<br>
would lose the new dev :) ).<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>Disadvantages or this:<br>1) Plugin calls directly, so we can intercept the call and record it<br>2) The UI is in a dialog and can usually not be reused in the macro editor<br>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<br>
4) For scripting the functionality needs generated bindings which is complicated and didn't work very well in the past<br><br>The new system looks like this:<br><a href="http://i.imgur.com/xU3Kd.png">http://i.imgur.com/xU3Kd.png</a><br>
<br>Explanation:<br><br>Command: A command is contains basically two things: 1) an id string to identify the command 2) a KisPropertiesConfiguration that contains the parameters<br><br>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.<br>
<br>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.<br>
<br>Command runner: The class or plugin that executes the command.<br><br><br>This solves the disadvantages I pointed out above:<br>1) We already know how to record filter and this is practically identical and compatible with the old recording framework<br>
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<br>3) Plugins can register runners that can then be used by other plugins<br>
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.<br><br>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.<br>
<br>Implementation:<br>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.<br>
<br>If you are not scared by this point, you should be ;)<br>Comments?<br><br><br>Sven<br><br><br></div></div>