The family of KDE websites has got a new member, the site for the fine utilities applications from the module kdeutils. Despite being one of the first modules, kdeutils has always been without its own website. No longer. At utils.kde.org you can now find a lot of information about the KDE Utilities. See for yourself the details of the current set of programs below.

The module kdeutils is one of the modules that has been around since the very beginning of KDE. At the time of KDE 1.0 the module kdeutils was already well populated and consisted of KArm (now KTimeTracker), KCalc, KEdit, KFloppy, KHexedit, KJots, KLJetTool, KNotes, KTop (now KSysGuard) and KZip (now Ark). The observant will see that nearly all of these programs are still part of KDE and kicking. Only three of them are no longer in development: the very specialised program KLJetTool (used for configuring HP Laserjet printers) was removed from the development branch before KDE 3.1 due to being obsolete, and KEdit and KHexEdit were removed only recently before KDE 4.0, due to being unmaintained and with substitutes (KWrite and Okteta).

Over the times a younger module has drawn away some of the programs: KTimeTracker, KNotes, and with the upcoming KDE 4.1 also KJots are now part of the module kdepim. Any removal has been balanced with completely new programs. The two freshest members of kdeutils, which entered it in time for KDE 4.1, are Okteta and the Printer Applet. The latter also makes an interesting premiere, being the first program in the mainline KDE modules which is not written in C/C++, but in Python.

Each program has a description page, a page with an overview of the program's development (like activity or progress with translations) and a contact page. Over time more content will be added. If you are interested to help out with that, please get in contact with us.

If you have been developing a utility based on the KDE platform outside of the KDE repository and you think it would be a good addition to this module, do not hesitate to contact us. If you, contributor or user, are interested in some of these programs, go and find all information at http://utils.kde.org/.
Finally: Thanks a lot to our KDE sysadmins David, Dirk and Tom, who did all the work in the background to get the site running.

Comments

That's looking really good. Having a uniform look across all *.kde.org pages I think is really important, and you guys have done a fantastic job with this one.
The KDE Utilities site looks far better than most of the sites for the main KDE apps. I'm loving the overuse of "screenie" - it helps livening up the pages, and again the with the consistency across the sites.

Hopefully this will spark some more development across the other kde web pages. Especially doc.kde.org, that site could really do with a makeover.

So, is Python officially a dependency of KDE now? The Printer Applet, and I think J. Riddle wrote a System Settings module in Python recently that's been adopted. I'm planning on writing a System Settings module in the next few months for configuring backups, and I thought I would have to write it in C++ to have a chance of it being included with KDE proper, but if I could write it in Python, it would be so much easier. I know KDE used to insist on being pure Qt/C++ but has that changed now?

It is a 'soft' dependency, meaning that you can build and install the kdeutils without Python support. You just won't get the printer applet. One of the ideas that was floating about while leading up to KDE 4.0 was to have at least one non-trivial application to be in KDE and written in a language other than C++.

I say go for it if you want to write KDE software in Python. If you write something good but people don't want to run it because its in Python/Ruby/whatever, then it is their loss. A dependency on Python/Ruby/etc should just be viewed the same as any other dependency. Pros vs cons, reward vs cost. Language shouldn't be treated as a special case IMHO.

I personally don't think there is a compelling technical reason for any of the stuff in systemsettings not to be written in higher level language such as Python or Ruby. Same goes for much of the stuff in the kdeutils and kdeedu modules. It would certainly make it much easier for more people to contribute to KDE. Not to mention it is much easier to diagnose an error message and stacktrace from a user than a segfault. But that is a different post. =)

I know that is formally a part of KDE Multimedia, but I want to give credit to a little app that is, IMO, the best MIDI player ever for Linux. KMid has been with us since unknown times, and is STILL alive and kicking, despite the fact the last revision of it was in 1999 (release 1.7 for KDE 1)