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

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: KDOM
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-05-25 16:18:16
Message-ID: 200505251918.16394.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 25 May 2005 17:41, Paulo Moura Guedes wrote:
> On Wednesday 25 May 2005 07:17, Andras Mantia wrote:
> > So basicly KHTML is the limitations that disallows us to modify the
> > source from VPL and rebuild the tree, isn't it so?
>
> I don't understand this.

I always had the idea that the easiest and straightest way would be to 
*always* modify the source, where you do this modification. This is the 
same as Jens wrote: the source is the document, VPL, the tag dialogs 
and the attribute tree, the node tree is just a view. So if you enter 
"a" in VPL, it enters the source, rebuilds the tree and VPL gets 
updated. Nicolas said that this is slow and I'm saying that the 
slowness might be either from the Quanta node=>KHTML DOM tree building 
or in building the KHTML DOM tree and displaying it. This is why you 
modify now the KHTML DOM tree directly and synch back this to the 
Quanta node tree and the document source. And which is not so easy and 
can cause lots of problems.

So the real solution is to just modify everything in one place and 
update the others from there. This way there is no need for two-way 
synchronization. For me the natural place where you make a modification 
is the source, especially that when you are in source mode and the user 
types, you don't get his typing, but the modified document...

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

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