Welcome to KC KDE! The feature freeze for KDE 3.0 is now in effect. This is less restrictive than a code, GUI or message freeze but does mean that all the features that will be in KDE 3.0 are at least started in CVS. From here until the official release sometime in early 2002 the KDE developers will be focussing on stability and completeness.
Of interest to all the eye-candy junkies out there was the KDE3 theming meeting held on IRC. What effect that meeting will have on the final look of KDE3 is yet to be seen. Another development of interest is the Aegypten project sponsored by the German government to bring advanced crypto into KMail. It appears at this time that KMail will be seeing a new plugin mechanism to accommodate various mime and crypto solutions at runtime. A lot of effort and work is happening on that front and the KMail project is evolving to encompass the efforts of developers who until recently were outsiders to the project.
We hope you enjoy this week's summaries, and happy hacking!
Alternative language aficiandos will be pleased to know that C bindings for Qt and KDE, which are a gateway to easily supporting other languages, are being kept current. Richard Dale has taken on this task and recently checked in a new set of bindings for the KDE3 alpha. When asked how they were created Richard replied:
They use a hacked version of kdoc to generate them automatically. I keep any manual edits I need to make as a patch, so the next time I regenerate the bindings, I can just reapply that patch. The C bindings wrap about 800 classes, 13 000 methods with 200k LOC of C/C++ generated.
I would like to tidy up the kdoc code, call it something like 'kbindgen' and combine the C/Objective-C/Java bindings generation into the one tool. That's why I didn't check that in last night, the code isn't 'secret', and it works - it just looks a bit of a mess.
I haven't contacted the kdoc author, Sirtaj Singh Kang to see what he thinks yet. Although the code could perhaps go into the ordinary kdoc as a patch - generating an api is just another output format for a documentation tool like kdoc. But my perl isn't nearly as well written as Sirtaj's stuff, and it also does something which kdoc wasn't intended to do - parse methods down to the argument level, and uses a (hard coded) symbol table.
This is quite a lot of code to watch over, even if it is a mostly automated process.
In the words of Ian Reinhart Geiser:
I would like to take a moment to say YOU ROCK!
Some topics inspire impressive amounts of discussion no matter how many times
they come up. They usually remain that way until someone finally
makes a decision to implement a solution one way or the other. Bryce Nesbitt reawakened
one of those issues saying,
When I quit KDE, 99% of the time, it's because I also want to
suspend or shutdown the machine. Has the idea of adding these options
to the KDE logout been considered? Is there a reason not to?
This elicited the
usual flotilla of pros and cons including consideration for remote X sessions and the requirement
for root on some systems.
But nestled in amongst the rest of the emails in the thread was an email from
Oswald Buddenhagen in which he said,
you're about the 13,897,602,134th person requesting it. :)
reading the list archives and bug reports may sometimes help. ;)
yes, i'll commit the basis for this in a few days. two days later it may
be already working completely.
as george stated, in paranoia-mode this won't be allowed. :)
the remote terminals are another thing, but that's a minor concern.
DCOP is one of the core technologies that holds the KDE desktop together. But it is more
than an IPC mechanism: it can also be used to control and script applications from the command line.
There were limitations and annoyances with the DCOP tools available to users in KDE2 and
so Waldo Bastian and Ian Reinhart Geiser (along with others) took to improving these. Ian reported his work on
kdcop, the GUI DCOP frontend, saying, I gutted and redid some stuff with KDCOP. Please check it out and let me
know what people think. My hope is that no one notices a change, cause the
changes are all in the background. I have to finish adding some more data
types, but those should come later this week.
Meanwhile Waldo was creating a series of new DCOP utilities and announced their availability saying:
With Ian's hard work to expand the dcop-accessibility of many functions it
seems to be the right time to announce a new set of dcop command line
utilities. (Available from CVS HEAD)
The new utilities include dcopstart (which allows the starting of a KDE application and returns its ID), dcopfind (which finds a running KDE application), dcopref (which creates a DCOP reference), dcopclient (which gets a client ID given a reference), and dcopobject (which extracts objects given a reference). The existing dcop program was also extended to allow for more flexible scripting and usage of the new dcop tools.
Last week aRts gained support for IRIX. This week it was ALSA 0.9 that was getting attention. Commenting
on his efforts, Warren Turkal said,
I am working on alsa 0.9 support in arts. If I can get this working,
could someone look at the code and provide pointers?
Also, I cannot develop with CVS right now. I am basically using
debian source packages for KDE 2.2.1. Is this a problem?
My basic design is just going to be a rewrite of the current ALSA 0.5
stuff with some new things like the ability to pick a device in the
soundserver config panel.
Warren wasn't the only one working on this, however. Stefan Westerfeld replied
to Warren saying,
I got a patch for ALSA 0.9 support yesterday, so please wait until I have
integrated it intp the CVS, to avoid double work. The patch just does
adaptions to compile/work with ALSA-0.9, and doesn't contain advanced things
like "device picking", so after it is in, it would be great if you could
add these things.
I really prefer patches against the current CVS version, because it is less
work to integrate it. But if you are working on something that is basically
unmodified right now (like kcmarts), adapting from 2.2.1 to HEAD should be
possible.
One of the larger pieces missing from Konqueror's CSS implementation was support
for media definitions. This allows defining separate styles depending on the media that is
being used to view the content (e.g. computer screen versus printed page). Martijn Klingens
has been working on supporting this rather complicated aspect of CSS for some time. Approaching
success Martijn said, Ok, this is hopefully the definitive patch to add CSS2 media support to
KHTML. I applied all comments from Dirk regarding the previous patches
...
Dirk, Lars, please throughly review. Reviewing by others is also appreciated
(hint :-). I will commit next monday or say if I hear no objections or
approval. Earlier approval would be nice because it would allow me to switch
to a full KDE 3 environment earlier...
Marc Mutz and Simon Hausmann pointed out a few issues with the patch, but the bulk of
discussion centered on how to best use this new support in places such as KDE documentation,
KMail and Konq-e. Martijn posted a follow-up message saying,
Thanks to Dirk and Simon for reviewing, CSS2 Media support is now in CVS
(HEAD only, will _not_ be backported).
Vadim, could you update your CVS and run all your test suites on it? ;-) Note
that there are no ECMA bindings in place as of now, only normal HTML is
handled at the moment. I guess document.write( "<style ...>" ) will work, but
I don't call that ECMA bindings...
One of the benefits of the KIO architecture is that it is asynchronous. Of course, there is no such thing as a one-size-fits-all solution. As further proof of this axiom Charles Samuels announced the initial development release of a KIO wrapper that makes it synchronous. Along with the announcement he included a (preemptive?) list of FAQs, including:
Q. You reimplemented all those protocols?!
A. No, this uses the same kio slaves on your computer already.Q. Is it threadsafe
A. YES! (Kinda). This is different from the normal KIO in that it doesn't require an event loop. Getting data just requires reimplemting virtual functions. This means that you could use KIO in one thread, and UI processing in the main thread. (I could still use slots-n-signals, because they don't use the event loop, because I didn't, they're much slower.)Q. What's all the stuff in the tarball
A. "test" is a program that links to libkiosync and accepts two args. the command, and the URL. The commands "cat", "ls", and "stat" are supported, and do (more or less) what the shell tools do. Also is libkiosyms, which allows LD_PRELOADing!
Q. How complete is the implementation of the KIO protocol?
A. About 30%, I think. Redirections don't work, but gets, lists and stats do. No put or copy yet.Q. How fast is it?
A. In theory, it should be much faster than KIO for stuff like listing a directory (which sends lots of signals). Benchmark it if you will, but as I said, multiple jobs per dispatcher isn't a keen idea yet. I think KIO's bottleneck is the Qt signals, which are designed for high level things like button presses, not speed critical low level stuff like "A New file available, here is the mimetype data." I have no research to back this up.
Q. License?
A. Pure proprietary. You may only do this if you write [My name]'s Soul on a peice of paper, in your own handwriting, and mail it to me. Erhm, it's actually LGPL, but I havn't said so anywhere (in fact, contradict that by saying it's GPL here and there :)Q. I'm sold, how do I get it?
A. A check or money order to me for $40, I also accept credit cards. After you pay that, you can download it from http://www.derkarl.org/kio-sync-0.1.0.tar.bz2 (250kb)
Stephan Kulow was quick to point out that Qt signals are not the bottleneck in KIO as just one signal is emitted for each group of files. Still, it will be interesting to see how this library evolves and if it improves KIO for those situations where performance is critical.
"Plugins, plugins everywhere." The list of applications in KDE that have support for plugins is getting impressively long. There is even discussion of KMail having plugin support added to handle multiple crypto schemes. One of the more recent areas in KDE to get plugin support is the context (a.k.a. right mouse button) menu in Konqueror. Holger Freyther wrote to the Konqueror devel list along with a patch saying:
this patch adds a plugin interface to KonqPopupmenu. If found the current way was too static.
This PATCH consists of two parts.
The Plugin class has two choices. Either use KonqPopupMenu::addAction( ) or it can use KonqPopupMenu directly.
- It adds some public function to make information public to KonqPopupMenuPlugin Classes.
- it adds a new class called KonqPopupMenuPlugin. You need to inherit this one and KLibLoader to create your own plugins.
In some situations the XML GUI stuff is too limited then you could add a dummy entry and use the slotXMLGUIFinished() to manipulate the menu. A couple of plugins are still to come. One is a so called quick copy and quick move. It adds something similiar as the disknavigator to a popupmenu. Then you would right click go to the quick copy submenu and choose the path. I would be happy if this patch would be applied
After quite a bit of technical discussion with Simon Hausmann and David Faure, Holger posted a second version of his patch along with a promise to supply a sample plugin that can be used to create new plugins along with several functional plugins of his own.
Schedules in the world of open source software are often subject to change, as those waiting for the next stable release of KPilot are well aware. Knowing that the original intended release dates had not been met, Adriaan de Groot said:
the KDE 3.0 freeze is coming closer. Please check the release schedule (somewhere under developer.kde.org) to see if your favorite feature <B><FONT SIZE=+15>that can feasibly be implemented</FONT></B> (preferably by you) is on the list, and to see if I've left anything out there (like the generalized PDB viewer?).
As for the fabled KPilot 4.3.0 release for KDE 2.2, that's still what I'm aiming for, and yes, it really should be out Real Soon Now, assuming I can curb my enthusiasm for fiddling around with software RAID under freeBSD and new hardware and old hardware too (I've got a barcode scanner. What should I do with it?). Currently I'm really working on the address book conduit, and as soon as I get something together that can sync reliably using just that one conduit, I'll release KPilot 4.3.0 into the wild. 4.3.1 will then have the remaining conduits. I hope that will make it possible to get people using the new setup, and help find bugs in it, without having to fix all the conduits first. Of course, it will mean that KPilot will be kinda crippleware (one conduit? you gotta be kidding) for a short while.
The good news is that much has changed for the better in KPilot during this delay. The GUI has seen some much needed attention by David Bishop and Adriaan has been working hard to improve the internals of KPilot. In fact, Adriaan has lately taken to liberally assigning tasks to those new on the PIM devel list. So if you post to kde-pim@kde.org you just might come away with some coding, documentation or GUI design work to do.