[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: recording
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2012-05-12 14:54:52
Message-ID: CAEkBSfVbe5GEKqfiK6Dyes9-OMF-TzsBmzs2uGX7Ki9i9YWLbA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> The commands at I was talking about are not QUndoCommands. It's also not
> on the same level as the strokes framework.
>
> QUndoCommand is too low-level. Action might map undo commands that are
> missing information that is needed for recording e.g. the selection tools
> use a normal transaction. Beside that I don't want to add xml loading and
> saving code to every undo command.
>
I agree that QUndoCommand might be a bit too lowlevel thing. But I think it
can be (and should be) done in the constraints of the strokes framework as
far as possible. We don't have enough manpower to introduce one more huge
system on the top of the strokes.
What I want to say is that while designing this system I thought about the
recording as well. But there was one flaw: I was thinking about usual tool
strokes and processings mostly, and I didn't think about our command-based
actions that much. That is why the interface of the commands didn't change
much since the introduction of the strokes. As a result, the strokes fit
perfectly for recording of the tool strokes and processings, but there are
still several flaws with recording of commands and emitting commands'
dialogs (about both you wrote about).
Runners are on a much higher level than the strokes framework. For example
> a possible runner could be the current KisLayerManager.
>
The only thing that is higher than the strokes framework is configuration
Dialog for an action. All the rest is exactly what the framework was
designed for. Yes, currently, the commands are handled separately and you
would have to introduce toXML/fromXML methods for each command to record
them. I totally agree that this is not the best way to record it. But we
can easily change it to any way we need. This is a matter of adding one
strategy class to the strokes system. We just need to agree what we need
and design it.
> For example if you want to scale a layer:
> 1) Dialog saves the values into a KisPropertiesConfiguration of a command,
> id is set to e.g. "scaleLayer"
> 2) Command is then send to the "command switch", that looks at the and
> looks up the runner for id "scaleLayer"
> 3) Command is then send to the KisLayerManager, which reads command id
> "scaleLayer" from which is knows the function to call and the values to read
> 4) KisLayerManager reads the values and calls KisLayerManager::scaleLayer
>
> Recording happens in step 2, when the command goes through the "command
> switch". Recording can't happen in step 4 as we have just transactions at
> that point and no information about the original dialog values anymore.
>
Yes, it is a good point that we lose original dialog values. Still there is
no need to implement one new system as most of this can be done using
strokes. The point is that it does already implement most the terms you
wrote about. We just don't use it yet.
How it can be achieved in the constraints of the strokes [0]:
1) The caller asks KisStrokeStrategyFactoryRegistry for the factory of
"ScaleLayer" stroke.
2) The factory does the following: i) calls image->barrierLock() to fetch
right size information about the image; ii) calls image->unlock(); iii)
fires up the configuration dialog.
3) The factory creates the stroke strategy for the "ScaleLayer" stroke
(usual undo command based stroke)
4) The factory uploads the XML data about the stroke into the strategy
4) The factory starts a new stroke and populates it with commands
5) The strokes system calls the stroke strategy's method toXML, which saves
the data
Comment:
For each action we create one (!) class only: KisStrokeStrategyFactory. The
factory creates a simple undo-command-based stroke, forms XML, passes it to
the stroke strategy, then populates the strategy with the commands. Later,
when the stroke is finished, the framework asks the strategy for the XML
and it returns the value formed by the factory.
The advantage of this approach is that we shouldn't change anything and
only need to add one class per action. More than that this approach will
not demand us to add toXML/fromXML to the undo commands: you are right,
commands are too lowlevel for that.
Btw, take into account, that the strokes framework is capable of canceling
the tasks! It works right now (and is tested in unittests), but it isn't
connected anywhere to the UI because of the problems with shortcuts in our
tools.
If you agree that we implement it this way we can discuss it further and
assign the tasks ;). I can do the work of adding gathering the XML into the
stroke system (it shouldn't be much of work) and create base classes for
the factories.
[0] - http://community.kde.org/Krita/Recording_System
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>The \
commands at I was talking about are not QUndoCommands. It's also not on the same \
level as the strokes framework.<br> <br>QUndoCommand is too low-level. Action might \
map undo commands that are missing information that is needed for recording e.g. the \
selection tools use a normal transaction. Beside that I don't want to add xml \
loading and saving code to every undo command.<br> \
</div></div></blockquote><div><br>I agree that QUndoCommand might be a bit too \
lowlevel thing. But I think it can be (and should be) done in the constraints of the \
strokes framework as far as possible. We don't have enough manpower to introduce \
one more huge system on the top of the strokes.<br> <br>What I want to say is that \
while designing this system I thought about the recording as well. But there was one \
flaw: I was thinking about usual tool strokes and processings mostly, and I \
didn't think about our command-based actions that much. That is why the interface \
of the commands didn't change much since the introduction of the strokes. As a \
result, the strokes fit perfectly for recording of the tool strokes and processings, \
but there are still several flaws with recording of commands and emitting \
commands' dialogs (about both you wrote about).<br> <br><br></div><blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div> Runners are on a \
much higher level than the strokes framework. For example a possible runner could be \
the current KisLayerManager.<br></div></div></blockquote><div><br>The only thing that \
is higher than the strokes framework is configuration Dialog for an action. All the \
rest is exactly what the framework was designed for. Yes, currently, the commands are \
handled separately and you would have to introduce toXML/fromXML methods for each \
command to record them. I totally agree that this is not the best way to record it. \
But we can easily change it to any way we need. This is a matter of adding one \
strategy class to the strokes system. We just need to agree what we need and design \
it.<br> <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
class="gmail_quote"><div>For example if you want to scale a layer:<br>1) Dialog saves \
the values into a KisPropertiesConfiguration of a command, id is set to e.g. \
"scaleLayer"<br>
2) Command is then send to the "command switch", that looks at the and \
looks up the runner for id "scaleLayer"<br>3) Command is then send to the \
KisLayerManager, which reads command id "scaleLayer" from which is knows \
the function to call and the values to read<br>
4) KisLayerManager reads the values and calls \
KisLayerManager::scaleLayer<br><br>Recording happens in step 2, when the command goes \
through the "command switch". Recording can't happen in step 4 as we \
have just transactions at that point and no information about the original dialog \
values anymore.<br>
</div></div></blockquote></div><br>Yes, it is a good point that we lose original \
dialog values. Still there is no need to implement one new system as most of this can \
be done using strokes. The point is that it does already implement most the terms you \
wrote about. We just don't use it yet.<br> <br>How it can be achieved in the \
constraints of the strokes [0]:<br><br>1) The caller asks \
KisStrokeStrategyFactoryRegistry for the factory of "ScaleLayer" \
stroke.<br>2) The factory does the following: i) calls image->barrierLock() to \
fetch right size information about the image; ii) calls image->unlock(); iii) \
fires up the configuration dialog.<br> 3) The factory creates the stroke strategy for \
the "ScaleLayer" stroke (usual undo command based stroke)<br>4) The factory \
uploads the XML data about the stroke into the strategy<br>4) The factory starts a \
new stroke and populates it with commands<br> 5) The strokes system calls the stroke \
strategy's method toXML, which saves the data<br><br>Comment:<br><br>For each \
action we create one (!) class only: KisStrokeStrategyFactory. The factory creates a \
simple undo-command-based stroke, forms XML, passes it to the stroke strategy, then \
populates the strategy with the commands. Later, when the stroke is finished, the \
framework asks the strategy for the XML and it returns the value formed by the \
factory. <br> <br>The advantage of this approach is that we shouldn't change \
anything and only need to add one class per action. More than that this approach \
will not demand us to add toXML/fromXML to the undo commands: you are right,
commands are too lowlevel for that.<br>
<br>Btw, take into account, that the strokes framework is capable of canceling the \
tasks! It works right now (and is tested in unittests), but it isn't connected \
anywhere to the UI because of the problems with shortcuts in our tools.<br> <br>If \
you agree that we implement it this way we can discuss it further and assign the \
tasks ;). I can do the work of adding gathering the XML into the stroke system (it \
shouldn't be much of work) and create base classes for the factories.<br> \
<br><br>[0] - <a href="http://community.kde.org/Krita/Recording_System">http://community.kde.org/Krita/Recording_System</a><br><br>-- \
<br>Dmitry Kazakov<br>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic