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

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: KDOM
From:       Paulo Moura Guedes <moura () kdewebdev ! org>
Date:       2005-05-25 4:57:13
Message-ID: 200505250557.14067.moura () kdewebdev ! org
[Download RAW message or body]

On Wednesday 25 May 2005 04:25, Jens Herden wrote:
> > > > > 2. in order to preserve the user formatted source we should
> > > > > copy/cut/paste just in the textdocument. Then we can use the undo
> > > > > feature of the texteditor. We have to take care of syncing the dom
> > > > > tree though.
> > > >
> > > > Interesting thought... so you mean making the the changes in the node
> > > > tree and then synch the text editor. I see some disadvantages though:
> > > > 1. in VPL you'll have to rebuild all the tree when undoing.
> > >
> > > If we would be able to find the area in the text document that has
> > > changed we could avoid this. Maybe we need support from the Kate part
> > > for this?
> >
> > I'm not sure if I understand. The tool we have to make modifications in
> > the document is the node tree. Copy/Cut/Paste is just an example but we
> > have to do all kinds of operations that are only doable by manipulating
> > the DOM with editing comands.
>
> Here you got me, I am not as familiar with VPL as you are. Can you tell
> what kind of manipulation comes to your mind?

Operations with tags like adding, removing, removing without the children, 
surround nodes, style modifications, composite edit commands that undo/redo 
as one, merging similar nodes, finding and splitting the subtree for copying 
some selected nodes having inline/block nodes in consideration, manipulating 
node attributes, finding correct start and end limits of a selection, 
splitting text nodes... well, it's a myriad of things :)

>
> > > > So if count on the text to make changes to your document you'll soon
> > > > will find some limitations like the first point.
> > >
> > > Maybe, but I think it is worse to investigate this. Maybe the parser is
> > > fast enough so that this is not a problem at all.
> >
> > Don't count on it :)
>
> I said investigate :-)

Currently, all the VPL operations that change Quanta node tree and then 
propagate, implie rebuilding khtml node tree. Besides the performance issue, 
which is *very* noticieble even with not fat trees, it happens a refresh of 
all the canvas which is very unpleasant to see.

> > > > I don't think this is a good approach.
> > >
> > > I don't think that what we have now is a good approach ;-)
> >
> > I think that some things we have now are poorly designed but I don't know
> > precisely which one you are talking about.
>
> I miss the clear definition what the document and what the views are. Right
> now we have a mess between trees and text documents that is very hard to
> understand and change.

Currently, the document is the tree and all the rest is a view. Source is a 
view and VPL is a view. But I agree that things are a mess in the way that  
some operations use a text based approach and some other use node 
manipulation.

> I would like to have a clear definition what in the Quanta context is the
> document. I am not against your definition that the parsed tree is the
> document. This would mean we have to copy the whole text into the nodes to
> preserver user formatting. This is a wast of memory.

But if we wanna have VPL, it's the only way. We have to parse the document 
text into a tree that khtml understands. If we deliver a tree to khtml, whom 
text nodes doesn't have text, how could a document be rendered? For those 
kind of modifications we'd have to have other custom tree, which is exactly 
what we want to avoid.

> Therefore my thought 
> was to make the text document the document inside of Quanta and let the
> nodes have a reference inside of the document. Of course you are right the
> manipulation in VPL does change first the tree but VPL could translate this
> in a manipulation of the text. This would make it possible to us the undo
> feature of the texteditor.

Yes, that makes sense but I don't know if that translation won't be more 
difficult then implementing undo in the editing commands. It's also a 
deviation from the model of the node tree representing the document and make 
us dependent of a text editor, turning the code less reusable. WebCore has 
undo/redo implemented in there editing commands so we only have to write code 
for commands that we extend.

> This is just a first thought and maybe at the end I agree with you that
> this is not possible.

We should discuss this as much as possible, so we can reach a good solution 
and this turns clear as water in our minds :)
-- 
Paulo Moura Guedes

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