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

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: KDOM
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-05-25 3:25:44
Message-ID: 200505251025.44445.jens () kdewebdev ! org
[Download RAW message or body]


> > I do not understand this.
>
> We need to take care of indentation when working in VPL or we end with a
> document that is a mess. Currently this is taken care by adding line breaks
> and space in the tag strings but I'm sure we can arrange a smarter way.

Got it, thanks.

> > > > 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?

> > > 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 :-)


> > > 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. 
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. 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.  
This is just a first thought and maybe at the end I agree with you that this 
is not possible.


> > > It would apply the Quanta formating. See above. Eric want's custom
> > > indentation and I would like to implement that so I think it would be
> > > more an advantage that the opposite.
> >
> > I am not aware about what Eric wants.
>
> See the mailing list for topics like "Indentation rules" and "Indentation
> in VPL" in 2004-12. They are pretty explicit. I can't give you more details
> now because I don't have the emails saved in this computer.

I have to apologise, sorry. Obviously I missed to read or to understand and 
save this in my memory.  

> > And until it is not discussed in the
> > public his wishes are non existent for me, sorry. A am not able to take
> > care of things I do not know. My abilities of mind reading are
> > unfortunately very limited.
>
> I didn't discuss anything in private, please don't be sarcastic. I wouldn't
> miss you opinion which, sincerely, I consider very valuable.

Pleased to read this :-)

Jens
_______________________________________________
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]