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

List:       quanta-devel
Subject:    Re: [quanta-devel] What is next?
From:       Nikolas Zimmermann <wildfox () kde ! org>
Date:       2005-03-04 12:51:32
Message-ID: 200503041351.33233.wildfox () kde ! org
[Download RAW message or body]

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

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

> - 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..
As I said I'd need more input to be able to give qualified comments...

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

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.

Bye
 Bye
  Niko



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