On Wednesday 21 January 2004 09:52, Eric Laffoon wrote:

hi!

I'm back with a new internet access. I'm sorry i haven't followed the last events, but i think i've dealt with most of the things which needed to be done. Some are remaining, and i hope to fix this within 1 week or so. Ok, it isn't as smoothed as i expected, but i think it is usable ;-)

Now THE question : what is the difference between KDE_3_2_BRANCH and KDE_3_3_0_RELEASE and where should i commit?

I have deeply though of the next features to add, but first some comments of yours: - Visual table editor : you surely mean the existing dialog, and we could also have the list editor working in VPL. Or even the very-WYGIWYG way with little square around the table so that we can modify the size of the table by moving the little squares with the mouse. Well, actually both should be fine. - visual CSS : The current CSS editor could be (internally) modified to work in VPL, and i've some other ideas, like a new dialog displaying the CSS properties of a Tag, and the priority order of all the different values for a same properties, with of course an instant refresh when modifying one of these values. - XSLT translation layer : you surely mean using VPL with non (X)HTML DTD. This is very hard, and at the moment, i simply don't know how to do it. (the main problem is the translation of the VPL DOM Tree to Quanta Node tree i.e. the opposite thing of a XSLT stylesheet). - Script integration edit mode : something can surely be done, but it will need more deep script parsing, i.e. determining what the Nodes are doing. Currently only structures are separated.

Now to my baby ;-) I've told some time ago about making internally every modification on the Quanta Node tree, and not on the source directly. It's time to explain its main advantages now : - a modification in the internal Quanta Node tree can be propagated to every views (currently 3 : source, VPL and structTreeView), it avoid to internally rewrite a dialog because it is based on 1 view only, and every new dialog works for every view. - Being parsed, the tree provides much more useful information. A great example of it : the DTDInsertNode function I've made for VPL can apply for the source view e.g. clicking on the "em" toolbar item in the source view on: boo|oo<b>beurk</b><table><tr><td>kaa|aa.... would normally give : boo<em>oo<b>beurk</b><table><tr><td>kaa</em>aa.... but with the above function, it will give a much smarter output: boo<em>oo<b>beurk</b></em><table><tr><td><em>kaa</em>aa.... This is a nice idea for the toolbars. - Every modification can be logged into a common undo/redo system so that every modification made in one view can be undone in another view. The main drawbacks : - It is more likely to crash, needs more careful coding. - It is harder to handle (but i'm currently writing functions to make edition of the Node tree easier and smarter e.g. moving a XmlTag Node move also its closing tag.)

Next, making Kafka a KPart, as initially planned. It has changed because i needed almost all of the parser directory. But now i'd like to come to the original plan. This will require to move the parser directory in a separate library (i think you're right, andras), but it comes the question where and when. If we consider that kMail will use it to make HTML mail, then it(the parser library and the kafkapart) should be moved in kdenetwork, creating a dependance to kdenetwork (or the opposite? ;-))

Now the enhancements i thougt of: - an error reporter inside VPL showing where the error is, and the cause of it. It is a bit duplicating the current error reporter, but it shows more precisely where the error is. - A great idea of Eric : ask for the page with the PHP tags generated, and diffing its tree with the current tree, and highlighting the PHP-generated objects.(And, why not, be able to modify them). - And at last making the undo/redo system works.

It is not an big list, but considering all the ideas that will popping up during the year, i think it is largely sufficient ;-)

In priority, i think the first thing is to make the VPL widget itself works more nicely(insertion/deletion of tags, cursor navigation), then make the Kpart, then make the undo/redo system works, then all the rest.

++ Nicolas