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

List:       quanta-devel
Subject:    [quanta-devel] Coding on Quanta
From:       Andras Mantia <amantia () kde ! org>
Date:       2009-12-07 19:44:57
Message-ID: 200912072145.05077.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,

(warning: long mail ahead)

 I sent this mail as you responded to my call for developer help or 
mentioned that you'd like to develop on Quanta before. I send it to you 
personally and to the quanta-devel mailing list. Please keep the replies 
onto the mailing list, unless it is something personal addressed to me.
 As you might know, development is stalled on Quanta for almost 2 years.
Development of Quanta related features did not stop though,  Niko Sams 
wrote a PHP plugin and worked on some code that originated from Quanta.
 Anyway, first my vision, next the details. What I would like to see is 
simple: developers who would like to work on KDE software and be famous. 
I slightly smiled when Eric said to me many years ago that I could be 
rich and famous by working on Quanta. Well, I'm not rich, but cannot 
complain, and maybe I'm not that famous as a rock star, but neverthless 
quite some people know my name. I even was asked at one conference to 
sit near some Quanta fans to take photos and sign autographs. :) You 
see, it is real, you can be famous by writing open source software.  In 
the 7 past years I worked almost continously on KDE and on Qt based 
applications. I got my job due to Quanta and my involvment into KDE (and 
I still do KDE development as part of my job).
 What did it take to come to this level? Lot of things, but one 
important was that I enjoyed working on the project and I enjoyed using 
Qt and KDE as a development platform. And I still do. When I started I 
had about 2 month Qt "experience" (C++ and general programmin much more 
though), so not having too much Qt knowledge shouldn't stop you working. 
If you would like to learn something interesting, work in a nice 
community, this is a good place.
 When I joined the Quanta "team", Quanta was pretty much - although in 
one sense different - in a state as it is now. It was abandoned, the 
original authors wanted it to die. But one person didn't wanted, and 
that was Eric. I got the source code of a full application where I 
started to fix bugs, and later to add new features. This was slightly 
before Qt3 and KDE3 appeared. What was the next step? To port Quanta 
from Qt2 to Qt3. The following months I did the port, rewrote it to use 
KatePart as the editor, wrote at least 3 instances of a HTML and PHP 
parser to replace the old simple, but dump one that was limiting us.
 And now? The last stable Quanta is KDE/Qt3 based. KDE is at version 4 
and Quanta needs a new parser. :)
 The situation is different though, as now I (and Eric) don't want it to 
die, and I even offer support as long as my time permits, to guide you 
with the development. Quite some code is already ported to KDE4, it 
doesn't have to be started from scratch. There is already a prototype of 
a new parser implemented. You have a better start, then I did. :)
 The project management model was quite simple: Eric had most of the 
ideas (as he was a user of Quanta as well, I wasn't a web developer), I 
coded it. How I do it was completely up to me. What I imagine now? We 
will tell what should be done IMO, but you choose what and how to do. As 
long as you enjoy and brings the project forward, that's great. If you 
don't want or can't decide what to do, we can come up with ideas, don't 
worry.
 The main goal is to have a working Quanta4 port for basic functionality 
for the next major KDE release, 4.5.  That is about 6 months ahead. It 
is an ambitious goal, I know. It depends only on the developers if they 
could do it. It is certainly possible. Basic functionality IMO would be:
- project management
- HTML, XML, PHP, CSS editing in source mode (autocompletion, document 
structure view, editing of tags in dialog boxes/in a treeview)
- file preview in a browser (embedded and external)
- upload (publishing) capabilities for the project

In terms of development goals:
- it should use the KDevelop platform
- the functionality should be provided as KDevelop plugins (unless it 
doesn't make sense). The reason is to make the Quanta core as light as 
possible and to reuse as much code as possible.


 Now the details... First, remember that I didn't touch the code in the 
past 1.5 years. KDevelop and the KDevPlatform progressed a lot meantime, 
and my knowledge is possible very outdated. Also my memory is not as 
good as when I was young, and of course I forgot many things from 
Quanta, even things I did in the last months of its development. :)
First of all you need the trunk (development) version of KDE and the 
KDevelop platform. Documentation about how to compile, install, set up 
trunk KDE can be found on http://techbase.kde.org . I can give advice 
about it, if asked, but I'd rather answer question related to Quanta, 
then related to general KDE. Not because I don't like to help, but 
because my free time is limited. Questions about the KDevplatform can be 
asked on the kdevelop mailing list (kdevelop-devel@barney.cs.uni-
potsdam.de). I'm really off the track about the current state, so even if 
I'd like, I mostly cannot answer.
  Quanta and KDevelopPlatform  is now in the extragear/sdk module. Once 
you have build KDE (kdesupport, kdelibs, kdepimlibs and kdebase is 
enough - kdebase might even be not required) , you need to build 
kdevplatform from extragear/sdk. Unfortunately there is some problem 
with the configuration files in the module, so you can't build everything 
together, but first you have to configure, build and install kdevplatform, 
and later you can configure, build and install the whole extragear/sdk. 
This might be fixed soon, though.
 Once you have everything in place, you can take a look at the Quanta 
code in extragear/sdk/quanta . 
 There is a DESIGN document, probably  outdated in some cases, but still 
it should give an idea. There is also a HACKING document with some 
coding style guide, but it is not followed strictly. 
 1) One thing I mentioned is the new parser. This is in 
quantacore/parsers. 
The code is using Qt's SAX parser to build an internal node tree from 
the html files. 
 The way it works is using state machines described in an xml file (these
are the parsing rules). There are even nice diagrams showing how the 
state machines work (quanta/data/statemachines/statemachine.odg). Now 
this works, and IIRC it even builds some kind of internal tree. The first 
idea was to use directly KHTML's or WebKit's DOM tree to store the 
result there, but at least when we evaluated, this wasn't good, as they 
are too strict. So the idea is similar to what Quanta3 has, store the 
parsing result inside our own node tree. In Quanta3 this tree was the 
heart of Quanta and I'd expect to be the same in Quanta4, after all this 
is why we parse the document. From the tree you can get information like 
where are you in the document (context), what you should show up when 
autocompletion is invoked (again, based on context), automatic insertion 
of closing tags, etc. The tree can be also used for validation. What is 
challenging to always keep the tree up-to-date as the user types in the 
document. 
 Quanta3 had a nice trick to rebuild only that part of the tree that 
changed. But this resulted in an uterly complicated code in the end, but 
I still think the idea is good and needed to have a responsive UI. 
Parsing in a different thread might be an idea, but then some thread 
synching and other issues might occur, sincerely I was afraid to dive 
into it.
 Once there is a parser and a node tree, the most important features of 
Quanta3 can be implemented (autocompletion, tag editing, error 
reporting, structure tree navigation).
 The first step would be to do just XML parsing and skip whatever is in 
PHP/CSS/whatever areas. The next step would be to either write state 
machines for these other languages or try to reuse the parser e.g for 
PHP from KDevelop. This should be coordinated with Niko Sams, who wrote 
the PHP plugin for KDevelop, he might have other, better ideas.
  Just so you know, the old parser worked like this:
- parse XML, find and mark areas that are not XML inside
- parse again (now by going through the node tree created in the first 
run, not through the file itself) and replace those marked areas with the 
parse result of the specific language.

2) There is a need for a new project manager. The whole idea how the 
information about the project files is stored needs a rethinking. Agaim, 
AFAIK Niko  had some idea about it.

3) the other functionality can be ported. Like tag editing, user 
toolbars (uploads, loadable toolbars from disk), etc. Some of them are 
already ported, and need just polishing, fixing. I know the user toolbars 
worked ~2 years ago, but don't know what is the state now.

4) anything else ;)

In case one of you starts to work on the parser, but doesn't like it and 
has better idea, I won't stop him to implement the new idea. :) But I 
have to admit, I liked the current design when we came up with it and 
coded with Jens Herden.

I hope I got your attention and you will get interested in this project. 
You can ask me on the Quanta devel list, or even on IRC (#quanta, 
#kdevelop, #kde channels are interesting), but give me some days to 
respond, I might be burried in other jobs or even traveling at the time 
you send me the mail. Communicating on mailing lists also tightens the 
community, the links between the people involved in the project.

Andras

PS: I let out the sponsoring part now, as that was covered in my other 
mail sent to the mailing lists.

["signature.asc" (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]