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

List:       quanta-devel
Subject:    Re: [quanta-devel] Where to start
From:       Andras Mantia <amantia () kde ! org>
Date:       2006-12-31 11:08:05
Message-ID: 200612311308.09515.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 21 December 2006 11:19, Andras Mantia wrote:
> Tough question, but I will give you an answer soon. ;-)

Sorry, soon was not that soon, partly because of the holidays, partly 
because of my ear problems... I will give some background about what we 
have done with Quanta4, what is its status, and what could/need to be 
implemented there.

 Quanta4 is supposed to work with the KDevelop framework. The idea is 
that we split up the monolithic design of the current Quanta and create 
KDevelop plugins from the parts. This means that in theory a 
lightweight Quanta can be created with the help of profiles (load only 
some basic plugins), or a full blown Quanta can be created with lots of 
functionality if enable all the plugins. This also means that we can 
share code, like the one for version controlling system, search and 
replace and so on. Code is shared also in the backend as instead of 
needing two "shell" (framework) which handles the windows, toolviews, 
plugins, we have only one shell. We made quite a good progress with 
this porting against the KDevelop 3.3.x series before KDE4 was started.
This splitup and the design is described in kdewebdev/quanta/DESIGN. 
This was created at the time when we used KDevelop 3.3.x, but the idea 
described there still holds, altough some details might not be 100% 
correct. The TODO file in the same directory has a list of unfinished 
work and known issues.

 But KDevelop changed a lot for the KDE4 release and it is constantly 
changing, so it was hard to continue this splitting and porting work, 
so we have stopped with it and continued with another important change: 
rewriting the parser. The XML/HTML/script language parser in the 
current Quanta was basicly a one man work evoluating from the time of 
Quanta 3.1 (when a very simplistic parser was replaced). Altough it 
works in >90% of the cases, it has some severe bugs (memory gets 
corrupted from time to time in certain cases, causing weird crashes), 
the code is big and in some parts hard to understand even for myself. 
Starting to work on that code for another developer is hard as well.
So together with Jens we created a new parser, state machine based, with 
documented code from the start. The idea is to use the KHTML DOM tree 
instead of ours to store the parsed information and this way it will be 
easier to show a rendered version of the document in the WYSIWYG mode 
(VPL). Right now we have our tree, which needs to be translated to the 
KHTML DOM tree which is used by the VPL code. If changes are made in 
VPL, those have to be propagated back to our node tree and vice versa.
Unfortunately I'm still not 100% convinced that the KHTML DOM 
implementation is good for us.
But back to the parser itself, the state machine is described in 
kdewebdev/quanta/data/statemachines. There is a dtd file describing the 
xml-s used to define the states, and there is an OpenOffice.org 
document showing the XML parser state machine in detail. The code 
itself is in kdewebdev/quanta/quantacore/parsers. The old parser code 
is still there in parser.*, saparser.* and parsercommon.*, you can 
safely ignore them. Shortly how it works: the document is read char by 
char (there is some batch reading though for performance reasons), and 
according to the state machine, actions are executed and a builder 
builds a DOM tree.
 Now how to proceed? Ironically soon after we abandoned continuous 
porting to recent KDevelop changes, working on the KDevelop libraries 
slowed down a lot, I don't know when was the last commit there... So 
one issue would be to see if we can continue to port new functionality 
(or more correctly old functionality to the new platform) from Quanta3 
to the KDevelop platform. Other possibility is to work on the parser 
itself. It would be very important to bring it to a usable state 
instead of a proof of concept as it is now. Usable means that it can 
detect changes made to document and update the dom tree on the fly like 
the old parser did. Script parsing is also missing, probably a new 
state machine needs to created for each supported language. Luckily the 
code is generic enough that most probably this means more design and 
xml writing and less code changes.
 I repeat the old suggestion: look at the code, see what's there, and if 
you find some part interesting, you can work on it. It can be what I 
wrote up there, or anything else, as the most important is to enjoy 
what you do.

Andras

PS: Eric, did you get my mails I sent since Christmas??

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

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