According to our decision at irc here comes the local copy of Berkeley DB 3. Modern distributions does not include bdb <=4.0 and with higher versions code completion in KDevelop crashes every time so keeping our local copy is the only way to provide stable KDevelop.

It's not that entirely outdated;) it's stable and relatively small. Several people tried to fix the crash and failed. We don't have another good solution right now and without the fix KDevelop is unusable in all modern distributions.

The database is used for code completion. It seems that this feature doesn't work or crashes KDevelop unless you have a specific version of the database installed. Version 3.2.9a works, but versions 4, 4.1, 4.2 all act differently, making it difficult and complicated to maintain code that depends on it. And distributions ship with all of the above. So for the short term at least, the easiest fix is to include a working version with KDevelop. This illustrates the friction that comes with relying on libraries maintained by others. Maybe this will provide impetus for a KDE database library, or at least a wrapper, that could be used by the various projects. Read the thread on kdevelop-devel for more specifics

conversion to setupGUI()

So what does that mean? Looking at setupGUI in kdelibs/kdeui/kmainwindow.cpp, this routine sets up the key bindings, status bar, toolbar, autosavesettings and creates the GUI, either using the xml file passed to it or the standard rc file. As Albert Astals Cid says in this commit setupGUI, 7 lines less, 4432 bytes of binary less.

We're getting ready to do some fun things. I'll give you some perspective. After dreaming of what I wanted to do with it since 2000 (and even before) we have been working hard to get it to where it was at a base level of service for competent handling of the essentials. It's pretty much there now. Now we begin going into areas that are much more innovative, exciting and maybe a little scary for me because they are so innovative. So some of the upcoming changes will be rather interesting, like team development features, object templates and the next one that will appears soon... extending actions to an event model. We need to address the security issues but Quanta is going to become even more powerful and chameleon like. For instance you could set an XML file to do an XSLT on save, or run a script on the server on an upload. Currently we've been looking at security issues involved, but we feel we can address them.

Kommander is really getting a lot of attention, releasing a new alpha every week for the last four weeks. A lot of new features are being added like DCOP scripting of the widgets, associative arrays to make list boxes and combo boxes more like their HTML counterparts. Kommander can store and retrieve widget values, manage global variables and more. Next week we will be adding the ability to build KParts and we're working on a part viewer. We're working on extending the new widget plugin framework to make it easy for developers to register DCOP calls for their functionality. We're completing our first release of project creation and management tools within a few days. In the coming weeks the executor will have have a full parser that will enable better integration of the scripting languages of your choice with Kommander specials, and string functions and program logic. Currently you can run any scripting language in Kommander Alphas. Most of the released dialogs use bash just for compatibility reasons. Our objective is to enable a simple set of functions which are economical to write, but more compact than what is in kspread for instance, with a function wizard for assembling functions for newbies. Kommander will have plugin database widgets in a few weeks too. BTW both Quanta and Kommander will have an online resource repository using KStuff shortly as this is also in process.

It's worth watching this. I wrote a simple dialog to install programs from source using Kommander. It started out as a way to help my wife. By version 0.4 it was seeing a 78% approval rating at kde-apps.org... with only 80 lines of actual code. Some of those lines were "then", "fi" and "@widgetText". I released version 0.5 this week and was surprised to see it's ranking climb to 82%, higher than Kword, pushing toward the 50th highest spot in over 13,000 submissions. Of course Quanta is in the top five, down now to #4, but Kommander has just raised to 85% at #31. Wow! I'm really honored and a little surprised, but I think it says several things. Both applications are well liked in KDE by their users. OK. But what is interesting is that early in it's evolution Kommander can produce applications that can be built quickly and easily, and those applications can be highly regarded. Add it all up and what do you get? Easy to add KDE widgets as plugins, applications run without compiling, little or no scripting, the language of your choice, very fast internal DCOP scripting, KParts... and hopefully easy enough to ordinary people to use and admin level users to create applications. I'd really like to put out the call for testers and developers.

We should start looking for a groundswell of activity in Kommander development in the coming months, and we should get the word out. So I thought I'd bring it to your attention, because every week something exciting will be happening in kdewebdev CVS. Keep your eye out. ;-)

Version 0.5 Changelog:

• Added some configuration options for kiosktool itself.
• Save any pending changes on exit.
• Fixed reading of settings ("settings don't stick" problem).