After five weeks intensive work in Romania Quanta's main developer Andras Mantia together with Jens Herden finished the first major step of Quanta's port to the KDevelop framework. Being able to get this result in a relative short time was only possible because of the excellent framework provided by the KDevelop project and the support of KDE e.V..

Only with this support Jens Herden was able to travel from Cambodia, his current living place, to Romania. Being in Romania made it also possible to travel to Kiev to attend the KDevelop conference and meet the developers personally.

The goal of this new development is to divide up Quanta's code into several plugins for the KDevelop framework. Quanta will remain a separate application and keep its name.

Some benefits of this are:

Code sharing between both projects to avoid double efforts for the same functions.

New and old plugins can be used from both applications.

Quanta's code base will be much easier to understand and maintain.

The modular design allows the user to create his/her customised Quanta by disabling unwanted plugins or enabling plugins from other sources.

The new, plugin based Quanta will be released together with KDE 4.0. But we are confident to release a first preview version called "Kuanta" shortly after Quanta 3.5 is released.

Please excuse a troll to leave a comment while passing by...
I'm watching the Quanta+ project remotely for quite some time, without having the time and resources to actually use and test it, so please apologize for commenting without actually participating...

Please do *not* call the preview version "Kuanta", this is a butt ugly name. (I know, i know, this is due to tighter integration with a KDE core application but still.)

hold on, this is a preview name only. With the next release it will already be a thing of the past. Or do you still know the release name of KDE 3.3 ?

Other than that, great work. I suspect Eric has put a lot of effort into making this happen. Quanta and KDevelop were indeed seeing a lot of duplication. Now that the later is mature and can actually be used as a foundation for Quanta, there is chances for better web focus.

From KDevelop I have to expect more though. In fields unrelated to Web, C++ and Ada, the language integration is not up to speed yet. Are there plans to leverage on gcc 4.0 and its parser to better understand the languages?

"Are there plans to leverage on gcc 4.0 and its parser to better understand the languages?"

No.

And before you protest, yes, I know gcc 4.0 has the best c++ parser around. Yes, I know it _seems_ like it'd be a no-brainer to 'leverage' this for things like code completion and refactoring. Unfortunately, that is not how these things work and it is a naive assumption. A code completion parser requires the ability to parse incorrect code or half completed statements and not choke and throw an error.

That said, the new kdevelop _will_ have a brand new parser that will hopefully go a long way towards improving things. Cheers.

I do not reserve the right to protest. I have only asked and in no way intended to offend anybody involved.

I do reserve the right to be naive, despite being a "developer" what ever that means. :p

That said, I don't think that code completion and gcc 4.x are probably worth to marry. The gcc parser understands so many languages in near perfect ways. It gets some performance tuning and stuff that a separate parser engine would not have.

Even though it may be hard, maybe it's worthwhile? Do you know if somebody has actually tried it? I might be willing to try it myself...

You know it's rather easy to try too, and you will see it's not good. Take some half-finished code with errors and watch the gcc 4.x parser barf on it. Then try visualize how that can help you with code completion when writing the said code.

It is ok if you are not a developer, but just understand that what seems obvious to you is actually quite naive in actuality. Now, if I sounded hostile it is because there was a very long thread recently on kdevelop-devel that had a lot of _developers_ who were postulating the very same thing. All of them had never written or worked on a code-completion in kdevelop before.

And once again, I know you think it would 'probably worth to marry', but you would be WRONG. This is a naive belief that roughly goes:

"Hmm, we need a great C++ parser for code completion"
"Well, g++ is probably the most complete we could use"
"BINGO! That's a great idea, we should use g++!"

But, once again, this is WRONG!

The parser might be the best at parsing and compiling compilable code, but it sucks as a code completion parser. A code completion parser must be able to parse _incomplete_ uncompilable code. And it can't just produce an error and stop. Think about it...

In short, the g++ parser would have to be so heavily modified that it would lose the advantage of sharing code with the gnu folks. It would fork and diverge. Not only that, but the actual g++ parser would be a pain to retarget and modify -- and yes, I've looked and have actually hacked on both g++ and kdevelop's code completion and parser.

I have always thought that the best way to improve parsing of incorrect code would be to give the parser some memory of recent changes. For example, if the project started out as completely valid code and then you modified a method definition (without changing the code that callst the method), it would be hard to parse the resulting invalid code, but if the parser remembered that the old method used to exist it could make many simplifying assumptions as it parsed the new invalid code and give more helpful error messages too ("method foo has been changed to bar" instead of "unknown identifier 'foo'" or the like).

I don't know of any plans to do a parser like you describe. Parsers are tedious and involved code that takes a lot of time and debugging. As far as providing better error messages I think your example shows how much more complex it really is. For a relevent changed method message you would need persistant memory of changes for both files which would be like incorporating a revision system into a parser. It's an interesting idea, but parsers have to process so much data optimization is a key factor and making them revision aware would likely be a nightmare and slow. A more ideal system would be to offer the option to find and change the relevent method calls in the project or put them in an edit queue. My preference in adding automation is that it actively seeks to reduce errors.

BTW I am not aware of everything going on with the KDevelop parser, just what we've been doing with Quanta so far. That's the perspective I'm looking at. It will be exciting to review using their parser in places or possible integration and modular parsing concepts. We will have inherent differences as well as similarities.

'..but if the parser remembered that the old method used to exist it could make many simplifying assumptions'

You really talking about code refactoring here, where the IDE has parsed the source and formed an 'Abstract Syntax Tree' and symbol table of what the names used in the program code mean. Then because it knows about the structure of the code, and not just the correctness of the surface syntax, you could specify refactoring rules to transform the AST. For instance, you could add some text before or after a node, or you could move a node to another part of tree. Moving a method to another class, or renaming a method and fixing up all references to it in the code are examples of refactoring. The new parser generator and language parsers for KDevelop 4.0 will be able to use a common refactoring engine, which will work with ruby just as well as C++.

If a syntax checker was giving you errors based on what the code looked like 5 or 10 minutes ago it would just be really annoying, and feel more like the editor had only half saved your work. There's no way it would be possible to 'read you mind' to find out what you were intending to do. Hence, the need to work at a higher level than typing in lines of text, like using a refactoring engine.

> Other than that, great work. I suspect Eric has put a lot of effort into making this happen. Quanta and KDevelop were indeed seeing a lot of duplication. Now that the later is mature and can actually be used as a foundation for Quanta, there is chances for better web focus.

Actually Quanta 0.9x was basically a stripped version of KDevelop with an HTML preview and little else. When Andras came on and KDevelop 2x had a new more modular architecture I asked his opinion on adopting the framework but it did not appear practical with our resources. During aKademy last year Jens brought this idea up and it had pretty much fallen into the dust bin as nobody else was thinking about it at the time. Now we have more resources and much of the duplication of effort is more obvious. I think Jens was a little surprised how easily I agreed and we set up a meeting with KDevelop developers. What was really exciting is how eager they were to work with us. That totally changed the complexion of things and turned it into a "why didn't we do this sooner?" question.

As to who deserves credit for the effort to making this happen, I would say that credit goes to Jens Herden who was so dedicated to the cause from the start and who has put so much time and effort into it. We're very fortunate to have Jens on our team and I'd like to personally and publicly thank him for his initiative, skill and caring hard work on our project.

"In fields unrelated to Web, C++ and Ada, the language integration is not up to speed yet."

Not so. Ruby support in KDevelop 3.2 was improved quite a lot with a ruby debugger, Qt Designer integration, KDE project templates and an improved class parser. It is certainly 'up to speed', and at least as good as in other ruby IDEs.

Yes, that is a problem. The reason it starts the ruby code via a C++ stub is that it would be exactly the same whether it was a KPart project or a kicker applet. For those other project types there is no choice but to start via C++, as they have to be libraries dynamically loaded from a running KDE app.

The current automake based build system for KDE a way too complicated for ruby anyway. I think the best solution would be to have another application template with exactly the same ruby code, but using a simpler build/install system and no C++ top level stub.

"neverthelesse quite surprised when I tried the template and got a compiler error about a missing header"

Yes, in fact you have to run the usual 'make -f Makefile.cvs' and 'configure' commands via the GUI to install. So you get incomprehensible configure stuff for about 5 minutes.

Note that you've got the KDE problem where you can't actually debug you program until it's installed because it won't be able to find xmlgui menu items and so on. Or if you have a KPart project, it won't run until the KPart is installed. I really hope that's fixed in some way for KDE 4 for C++ and other languages like Ruby. Maybe there should be 'share/apps' directories under the KDevelop src dir with symbolic links from the subdirectories into the src dir, and the src dir added to $KDEDIRS. But I don't want to have a ruby specific work round, it needs to be sorted properly.

"Btw, if one has two Ruby KParts/Kicker applets, will the two calls to ruby_init be problematic"

It works fine if you call it twice - it just doesn't do anything the second time.