[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-03 19:43:44
Message-ID: 200503031943.44342.moura () kdewebdev ! org
[Download RAW message or body]

On Tuesday 01 March 2005 09:48, Jens Herden wrote:
> Hi,
>
> I would like to ask what the next steps for Quanta are?
>
> AFAIK there will be a KDE 3.5, so what is planned for Quanta 3.5?

IMHO, a lot in VPL should be rethinked:

- Sometimes, Quanta's tree is changed first and then KHTML tree, sometimes the 
opposite. Inconsistency.
- The undo/redo system is not object orientated. We should make any "command" 
a class that knows how to apply, reapply, unapply, etc. It's a know design 
pattern. Besides, it has the responsibility to update and synchronize the 
views, which shouldn't belong here. There is a lot more drawbacks which I 
won't describe here.
- There should be a more clear interface between Quanta/VPL and the engine(s) 
to use (in this case KHTML)
- There is not a clear abstraction about the DTD we're using. I guess it's a 
lot better than other editors but is still (X)HTML orientated.
- There is not yet the notion of stylesheet in VPL. This should be 
transparent, whether you are using CSS to arrange HTML or XSLT to edit XML.
- The indentation system is not flexible (and the way the code is generated 
from nodes)
- 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.

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