From quanta-devel Fri Mar 04 14:13:04 2005 From: Paulo Moura Guedes Date: Fri, 04 Mar 2005 14:13:04 +0000 To: quanta-devel Subject: Re: [quanta-devel] What is next? Message-Id: <200503041413.04164.moura () kdewebdev ! org> X-MARC-Message: https://marc.info/?l=quanta-devel&m=110994559103413 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