[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 18:07:47
Message-ID: 200505251907.47245.moura () kdewebdev ! org
[Download RAW message or body]

On Wednesday 25 May 2005 17:18, Andras Mantia wrote:
> 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...

My view of a web authoring tool is that it should do more than just typing 
text. The rigth way to do it is manipulating nodes. Manipulating text 
directly is a hack and very limiting. You need to manipulate nodes, not only 
in VPL but also in any view, including source, if you want to do some 
operations. I know that the source view doesn't fit well in this model 
because you modify directly the text document (though you can and should have 
more complex operations available that would require node manipulation). In 
VPL is always the oposite way. So you have here two views that *must* work in 
two diferent ways. That's no way around it. 
What we could think of is a way of optimize this, if needed:

In VPL - Node tree -> Text
Update only the changed text areas.
Don't know if needed. Currently, all the text is generated and I don't much of 
a problem with that even in split mode.

In source - Text -> Node tree
Why can't we just update the node tree when needed:
- Change to the VPL view; rebuilding all the node tree is acceptable IMO.
- Before doing any node manipulation, which doesn't happen offteb in source 
mode.
- In split mode I also don't thing that it is problematic to update all the 
node tree in order to update VPL when editing in source.

So, I don't see other possible solution neither any real complicated issue to 
solve.

-- 
Paulo Moura Guedes

Linux Caixa Mágica  - http://caixamagica.org
KDE Web Development - 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]