This is a call to willing volunteers :

People following KDE developmment through PlanetKDE will probably notice that the image has already appeared there. I indeed took it from a blog post from a KWord hacker. It turns out that we are in a similar situation : after a couple of weeks, the dev team (caduel, which recently joined, and I) significantly improved the stability and usability of the app. This would be enough to call for testers before a 1.0 release, but there's more to it... 

Why ?

1. It was badly designed since the "core" code was split in to separate modules
   
2. It heavily used QObject-based class (every single node was a QObject...) which consummed a lot of memory
3. It had very stupid data storage and node sharing schemeswhich wasted memory and induced unnecessary complexity when creating new node classes
4. It did not allow a convenient, abstraction of project nodes vs "regular" nodes, thus making the tracking of the "active project" a bit complicated...

What then ?

1. I rewrote "core" infrastructure from scratch in a single module : QProjectModel 2
2. Nodes dropped QObject dependency, and a couple other classes as well
3. Data storage has been optimized by giving the possibility (to the coder hacking a new project parser) to simply return temporary data (e.g. QString extracted from a global string data) or to store it in any posible way (instead of using a QHash of item roles/item data)
4. The node sharing has been removed from the core but this need was kept in mind while re-designing the abstract node class, so as to allow the use of "visitor" nodes, allowing the use of interlaced data structures while keeping the editable in a transparent way (especially useful for qmake includes, which can be shared by several projects)
5. Proper abstraction of project nodes is working and the "active project" now changes properly every time the user selects a new item in the view (parent project becomes active, or the project itself if the clicked node is a project...)
6. The new qmake parser brings many improvements : speed, size of the code and of the run-time data structure...
7. The model class can now load projects on its own : it has a QProjectLoader, itself fed with a set of QProjectParser objects which are scanned for compatibility each time a project needs to be loaded.
8. Thanks to (7), projects of all types (e.g QMake, CMake(no parser yet...), KDevelop(idem), Code::Blocks(idem)) can be loaded at once in a single model and showed in a single view :)
   

The thing is, integrating these new paradigm, while bringing a lot of substantial benefits, forced some redesign of Edyuk core lib. The manager dock, for instance, has become unique. Has I had several ideas left, I took the opportunity to redesign everything that needed to be, since incremental API-breaking redesigns would have been way worse than a single huge API-breaking one IMO...

What's next?

1. The plugin system has been completely redesigned (actually it just switched to an existing one, designed for a transitionnal version of QCodeEdit, but it's still a breaking change as far as Edyuk is concerned...). Plugins now provide a set of components, accessible via a pair of strings (Type/ID) indicating the type and the name of each component (list of availables keys are of course provided by the plugin interface.
2. This new plugin system brought the need for a command line utility, which made it as a fourth sub-project, QPluginGenerator. Indeed, while being extremely simple to write, the plugin interface (which tells the app what components it provides) is quite tedious to maintain... The utility generates proper code from the XML config scheme of the plugin
3. The aforementioned config scheme is a brand new aspect of the plugin configuration paradigm : plugis provide an XML scheme file (within a resource) that is copied to a settings storage location ($HOME/.Edyuk-$EDYUK_VERSION/plugins currently). This file holds information about each components, allowing some sort of introspection, but also a config-related section that allows Edyuk to build generic config widget added to the config dialog. The XML file is then filled with the values taken by each config option
4. The class browsing had to evolve to follow the new scheme adopted by project management. Code parsers are loaded and used the exact same way as project parsers are. A single code model now holds class trees for all opened project and for all possible languages (yes, a project can now use files of any possible languages, as long as a parser exist the tree will be filled :) )
5. A new widget has been added to the manager dock : a Kate-like list of all opened file (no colors though) which allows a way easier browsing than the tab bar when dozens of files are opened at the same time
6. The build infrastructure evolved a lot to match the new design of project management and also to make it easier to add new options. Plugins can provide QBuilder objects, which are responsible for the transformation of a given input into a given output (e.g. qmake project into GNU Makefiles, or GNU makefiles into bins). There are two standard types : "project" (base input... completed by the isSupportedInput() method, which takes a filename as parameter) and "exec" (base output could be binary but script as well). All these "builders" are combined by the build engine, which creates the shortest possible build chain from a "project" to an "exec"utable. This allow, for instance to avoid the duplication of compiling code when several projects can be turned into a common type of makefile. Then, each builder provides a list of actions. Usually a single one for "intermediate" builders (whose output is not "exec") but any possible number for "final" ones. These actions are used to build the menu entries of the "Build" section of the menubar and toolbars.

There have been a lot more things done but the changes are big enough to require testers, both to reach stability and to ensure the usability is good enough. I must also mention that, in the process of redesign/clean up, completion, debuging and assistant integration and designer integration disappeared. They should be back within a month or two (sorry but I don't have much time since I went back to the university...)

I hope you'll like it and feed me back.

Yours, busy bee ;)

fullmetalcoder

p.s. : As always, I forgot to talk about the most important thinngs...

1. The code is available only in the SVN trunk (https://edyuk.svn.sourceforge.net/svnroot/edyuk/trunk), see Sf.net docs .
2. You'll need Qt 4.3 to get it compiling
3. You may face troubles if you're running gcc 3.3 or older (though removing the designer integration might spare you that pain...)
4. feedback is most welcome on edyuk-devel mailing list , where other members of the team will be able to read it, or on one of the trackers : WebIssues one (gotta get a client for this) or Sf.net one