From quanta-devel Sun Dec 31 11:08:05 2006 From: Andras Mantia Date: Sun, 31 Dec 2006 11:08:05 +0000 To: quanta-devel Subject: Re: [quanta-devel] Where to start Message-Id: <200612311308.09515.amantia () kde ! org> X-MARC-Message: https://marc.info/?l=quanta-devel&m=116756546018525 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0948861962==" --===============0948861962== Content-Type: multipart/signed; boundary="nextPart27157080.dyOH2iJN1Q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart27157080.dyOH2iJN1Q Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 because of my ear problems... I will give some background about what we=20 have done with Quanta4, what is its status, and what could/need to be=20 implemented there. Quanta4 is supposed to work with the KDevelop framework. The idea is=20 that we split up the monolithic design of the current Quanta and create=20 KDevelop plugins from the parts. This means that in theory a=20 lightweight Quanta can be created with the help of profiles (load only=20 some basic plugins), or a full blown Quanta can be created with lots of=20 functionality if enable all the plugins. This also means that we can=20 share code, like the one for version controlling system, search and=20 replace and so on. Code is shared also in the backend as instead of=20 needing two "shell" (framework) which handles the windows, toolviews,=20 plugins, we have only one shell. We made quite a good progress with=20 this porting against the KDevelop 3.3.x series before KDE4 was started. This splitup and the design is described in kdewebdev/quanta/DESIGN.=20 This was created at the time when we used KDevelop 3.3.x, but the idea=20 described there still holds, altough some details might not be 100%=20 correct. The TODO file in the same directory has a list of unfinished=20 work and known issues. But KDevelop changed a lot for the KDE4 release and it is constantly=20 changing, so it was hard to continue this splitting and porting work,=20 so we have stopped with it and continued with another important change:=20 rewriting the parser. The XML/HTML/script language parser in the=20 current Quanta was basicly a one man work evoluating from the time of=20 Quanta 3.1 (when a very simplistic parser was replaced). Altough it=20 works in >90% of the cases, it has some severe bugs (memory gets=20 corrupted from time to time in certain cases, causing weird crashes),=20 the code is big and in some parts hard to understand even for myself.=20 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=20 documented code from the start. The idea is to use the KHTML DOM tree=20 instead of ours to store the parsed information and this way it will be=20 easier to show a rendered version of the document in the WYSIWYG mode=20 (VPL). Right now we have our tree, which needs to be translated to the=20 KHTML DOM tree which is used by the VPL code. If changes are made in=20 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=20 implementation is good for us. But back to the parser itself, the state machine is described in=20 kdewebdev/quanta/data/statemachines. There is a dtd file describing the=20 xml-s used to define the states, and there is an OpenOffice.org=20 document showing the XML parser state machine in detail. The code=20 itself is in kdewebdev/quanta/quantacore/parsers. The old parser code=20 is still there in parser.*, saparser.* and parsercommon.*, you can=20 safely ignore them. Shortly how it works: the document is read char by=20 char (there is some batch reading though for performance reasons), and=20 according to the state machine, actions are executed and a builder=20 builds a DOM tree. Now how to proceed? Ironically soon after we abandoned continuous=20 porting to recent KDevelop changes, working on the KDevelop libraries=20 slowed down a lot, I don't know when was the last commit there... So=20 one issue would be to see if we can continue to port new functionality=20 (or more correctly old functionality to the new platform) from Quanta3=20 to the KDevelop platform. Other possibility is to work on the parser=20 itself. It would be very important to bring it to a usable state=20 instead of a proof of concept as it is now. Usable means that it can=20 detect changes made to document and update the dom tree on the fly like=20 the old parser did. Script parsing is also missing, probably a new=20 state machine needs to created for each supported language. Luckily the=20 code is generic enough that most probably this means more design and=20 xml writing and less code changes. I repeat the old suggestion: look at the code, see what's there, and if=20 you find some part interesting, you can work on it. It can be what I=20 wrote up there, or anything else, as the most important is to enjoy=20 what you do. Andras PS: Eric, did you get my mails I sent since Christmas?? =2D-=20 Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org --nextPart27157080.dyOH2iJN1Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFl5oZTQdfac6L/08RAjSFAKChD+3zpC9pwyH/gB9TUn4gIVH5aACdGa7r bMY796HUWDuqVtPvrrv1ytA= =38CX -----END PGP SIGNATURE----- --nextPart27157080.dyOH2iJN1Q-- --===============0948861962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ quanta-devel mailing list quanta-devel@kde.org https://mail.kde.org/mailman/listinfo/quanta-devel --===============0948861962==--