[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Karbon14] Out of order undos, tools
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-09-25 16:11:29
[Download RAW message or body]

> > What I would like to achieve is the possibility to "serialize" and
> > "de-serialize" the executed actions into a Karbon document, i.e. store
the
> > command history instead just the resulting DOM. This should be an
optional
> > feature, similar to the Quick Save option in e.g. an MS Office document.

> How is storing the commands to create an object any faster than storing
the
> DOM? You're still storing vertex data etc.

It isn't faster, but more flexible (at least IMHO).
If I just write out the DOM, i.e. the graphical objects which are to be
rendered, I loose the information about how the DOM tree was generated.
If I write the command history, I have a) persistend undoable history and b)
I can see what happened while the document was generated.

> I guess maybe because it's still in "efficient" internal structures right?
> without the overhead of xml compared to binary data?
No I think the commands should be serialized to XML too.

E.g.

If I currently create a star with the star tool and fill this star with
color red, I have as result a DOM which is internally represented by some
VComposites and VPaths, in XML it could look like

<?xml ... >
<DOC ...>
  <LAYER ...>
    <COMPOSITE ...>
      <STROKE lineWidth="1" lineJoin="0" lineCap="0" miterLimit="10">
        <COLOR v2="0" v3="0" opacity="1" colorspace="0" v1="0" />
      </STROKE>
      <FILL fillRule="1">
        <COLOR v2="0,0039" v3="0,0039" opacity="1" colorspace="0" v1="1" />
      </FILL>
      <PATH isClosed="1">
         <MOVE x="281" y="410" />
         <LINE x="246,37" y="410" />
         <LINE x="308,624" y="525,975" />
         <LINE x="241,418" y="530,282" />
         <LINE x="206,864" y="588,088" />
         <LINE x="182" y="525,5" />
         <LINE x="116,345" y="510,5" />
         <LINE x="168,187" y="467,512" />
         <LINE x="162,164" y="400,436" />
         <LINE x="219,068" y="436,456" />
         <LINE x="281" y="410" />
      </PATH>
    </COMPOSITE>
  </LAYER>
</DOC>

I would like to store the executed actions, like e.g. so

<?xml ... >
<DOC ...>
  <ACTIONS>
    <CREATE-STAR x="200" y="200" rotate="-30" scale="1,5" outer="25,28"
      inner="17,64" edges="5" id="1" />
    <CHANGE-FILL id="1" >
      <COLOR v2="0" v3="0" opacity="1" colorspace="0" v1="0" />
    </CHANGE>
  </ACTIONS>
</DOC>

> Why not put in a check on load that checks to make sure all needed
> plugins/tools to execute the stored commands to create the document. If
one
> is missing, ask the user what they want to do? (ignore it, find it,
etc...)

Yes, but you would still have to write the required plugins into the
document, like

<?xml ... >
<DOC ...>
  <REQUIRES-PLUGIN name="baseplugin" version="1" />
</DOC>

I don't suppose that you can create an action from a plugin you have't
installed...

> Do the same thing on the other end. Either in the configuration options
> ("prefer DOM to command history in quicksaves") and do some logic. If the
> plugin is something that is standard, don't be afraid to save using
command
> history. If its something 3'rd party that most people wont have, don't.

I think this is rather difficult.
The problem is that theoretically an action can change the complete DOM.
So with quick save you store the original DOM and the sequence of actions
which together build the result DOM.
Currently you just store the result DOM.

I don't think you can mix these two approaches easily (but you could store
the result DOM everytime, so that you still see the results, even you can't
replay the actions)
This, however, increases the size of the document considerably.

Regards
Dirk







_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]