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

List:       quanta-devel
Subject:    Re: [quanta-devel] What is next?
From:       Paulo Moura Guedes <moura () kdewebdev ! org>
Date:       2005-03-04 14:13:04
Message-ID: 200503041413.04164.moura () kdewebdev ! org
[Download RAW message or body]

On Friday 04 March 2005 12:51, you wrote:
> On Thursday 03 March 2005 20:43, you wrote:
> > IMHO, a lot in VPL should be rethinked:
> >
> > - Sometimes, Quanta's tree is changed first and then KHTML tree,
> > sometimes the opposite. Inconsistency.
>
> Can't say anything about that issue, without knowing more about the Quanta
> internals, you're surely not maintaining two "dom trees" - khtml does the
> dom stuff and you're keeping another tree for different purposes, I
> suppose...

Yes, the Quanta tree is for our own purposes. It's where we hold the document 
and it must reflect all changes made into the document. Currently, some 
changes (in VPL) are made first in the KHTML tree and then propagated into 
the Quanta tree because when the other way around is performed, the entire 
KHTML tree is rebuilt, which is not efficient. So, for simple operations like 
pressing a key we change/create the KHTML node first and then synchronize 
with Quanta tree. For more complex operations like copy/paste, for example, 
we change first our tree, using our convenience functions for operations on 
nodes (kafkacommon.cpp), and then rebuild all the KHTML tree.

> > - There should be a more clear interface between Quanta/VPL and the
> > engine(s) to use (in this case KHTML)
>
> VPL is the tree you mentioned above?

VPL stands for Visual Page Layout (aka WYSIWYG). I meant an interface between 
all that belongs to Quanta and the VPL subsystem (including the tree) and the 
engines to use, so it will be transparent to use KHTML or whatever. With only 
one tree the need for this separation would be much smaller.
>
> > - Until now when we need to give the VPL user some feedback we used HTML,
> > to draw a dotted border around forms, for example. I think this is very
> > limited and the right approach would be to draw directly into the (KHTML)
> > canvas. This would make possible table resizing, for example. IIUC, this
> > would be possible to do if KHTML would migrate to kdom.
>
> Well I'm quite sure it's impossible at all to influence the "rendering
> tree" of khtml directly, this should really be hidden to the "public API".
> Same applies to ksvg2, you shouldn't be able to directly influence it's
> canvas.. 

I don't know how other WYSIWYG editor do but it seems to me the only way to 
go...

> As I said I'd need more input to be able to give qualified 
> comments...

Feel free to ask anything.
>
> > And last but the most important:
> > Two incompatible trees that need to be manually synchronized.
> > This is a tremendous hack and IMO VPL won't be viable while this isn't
> > changed.
> > Maybe there is a solution.
> > We need to keep our great features like tag info, PHP completion, etc.
> > Perhaps we can achieve this, with the flexibility and extensibility of
> > kdom. We adapt what we have now to this new tree and if KHTML adopt kdom
> > (which I think it's a matter of time) then we could load our (kdom) tree
> > in the KHTML engine and avoid a second tree.
> > The question is, are the Quanta team, especially Andras, willing to do
> > such a thing, if we conclude it's the right step?
> > I guess the question must be yes, if we want VPL in Quanta.
> >
> > It would be nice if Niko could give us some insight here.
>
> I'll try to give some insight about kdom/ksvg2 and khtml2...
> Please use the above mail as reference, it pretty much
> describes kdom/ksvg2 (& KCanvas, which is unrelated for you though):
> http://mail.kde.org/pipermail/ksvg-devel/2005-January/000130.html
>
> To directly say the most important fact for you first:
> kdom is NOT tied to any specific parsing backend.
> We have qxml & libxml2 implementations currently, and once
> khtml will be based on kdom they will surely use their own
> "html tokenzier" - I imagine libkdomparserkhtml.
>
> With Quanta you seem to parse a lot more stuff (php tags),
> so you probably already use a custom parser right?
> If yes, this could be easily converted to be a kdom backend.

This are very good news.

> Very important fact is that our "internal API" is cleaned up
> and installed to $kde_prefix/kdom/impl. You can "override"
> any part of the API to adapt it for your specific needs...
>
> Hope that enlightens the situation a bit.

Yes it does :)
-- 
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]