kde-pim meeting.

sitting outside enjoying the summer at the KDE-PIM meeting
I paid a visit to the KDE-PIM
in Annahoeve in the south of the Netherlands last night (photos). It was a very nice evening:
The food was terrific (asparagus, salmon, icecream with strawberries), there was even white wine, a
Chardonnay which I liked (normally I prefer red wine), it was cool to meet a bunch of hackers and
playing “Konijntje, Konijntje” was fun (although I didn’t really know the rules).
Simon and I did some hacking on the guidance preview widget for displayconfig. When I had just put
the notebook away, danimo told me that QCanvas (which I was using) would be gone for good
in Qt4. It seems to be a good idea to drop the QCanvas stuff already and use a QPainter. I’ll
probably have more time to work on guidance during the next weeks, because I finished my exams for
this summer and only have to write one paper in the course of the upcoming week.
Meanwhile I’m
pondering if I should go to aKademy in late August,
plane tickets are not getting cheaper …


one of the bugs - history ;-)
Downloaded a PyKDE snapshot tonight in the hope to get the PyKDE / PyQT / Python 2.4 toolchain running in order to get a more clear idea
of problems loading guidance programs into kcontrol.
Finally got all the python 2.4 stuff to work, but according to apt there are still a couple
of things dependent on python 2.3, which I wanted to remove completely. Ow well…

I the course of compiling PyKDE, I encountered a compile error which was caused by refering
to a long gone qlist.h, removed that, stuff compiled, sebas was happy. Sent that as a patch to the
PyKDE mailinglist, hoping it’ll help someone, maybe it’ll even make it into the next release.
Finally I could get back to work on guidance, and I had my toolchain updated so I
could be a little more sure that the more obscure bugs can be fixed by myself and will not at some
point just vanish by installing a binary compatible package and noticing that three weeks later,
still not knowing what had been wrong.
The rest of the evening I tried to get clear what was
causing the problems, it boiled down to my system having been confused by our installation script.
Apparently not everything was quite ready for python 2.4. Well, now it should be. And then I found
the root of a problem which I was seeing for more than a month and which crashed the kcontrol module
upon switching to Administrator Mode. Not too interesting, boiled down to stricter type
checking which is generally a good thing.

Well, fixed a couple of bugs which had me bothered for quite some time already, which is
good. Let’s hope they don’t break too much … Ow, and last week it became more clear that we’re
making a good chance to get guidance into Kubuntu soonish,
which is very exciting. :-)

alsa software mixing.

A thread on the Linux kernel mailing list
drew my attention since it deals with a problem that had me annoyed for a long time: Not being able
to have two applications playing a sound at the same time on my notebook, which has an Intel AC97
Soundchip. The alsa kernel drivers do not support multiple streams on hardware that doesn’t do it,
so there hasn’t been software mixing available in kernel. The upcoming release of alsa however does
support these kind of advanced features *ahum*. Lee Revell promises:

This problem is fixed with the upcoming ALSA 1.0.9 release - dmix will
"just work".  It's been a big area of development lately.

I have been playing around with my alsa configuration a little in order to see if the
bits suggested there would work for me – and indeed – I now can have XMMS running and mplayer using
my sound chip (with the snd_intel_8x0 kernel driver) at the same time. The dmix setup didn’t pose to many problems
to me, but you can of course just wait until your favorite distributor does it right for you.
Now let’s push the skype– and [insert random software that
still doesn’t support alsa here]-
developers to use alsa since the OSS layer and also the alsa
OSS emulation don’t support all that shiny dmix magic. Mixing is done in userspace, so not using
alsa-lib means no fun.

peace ‘n stuff.

green again
I’ve been reading the yearbook of peace and security 2004 for the last few days
and it’s all quite depressing.

Israel is building a wall which causes great poverty in
Palestine and doesn’t really help to stop the violence on both sides. While the
International Court of Justice confirmed that Israel is breaking international law, The US
support Israel in building that wall.
Genocidal actions in Sudan have been nearly ignored by the
international community and the situation showed once again that noone is willing to help you,
unless it’s in the country’s direct national interest.
Central Asian states are becoming
increasingly unstable because of lack of water, corruption and religious extremism. At least there
seems to be a lot of oil beneath their ground so the US are already there, discussing with Russia
and China who’s going to have which part of the pie.
Not too surprising, in the
, the experienced threat of terrorism is as high as never before, while
the real level of threat is relatively low. Still, it’s the impact of terrorism that counts and the
dutch people seem to be very vulnerable in that light. Probably this is one of the countries where
terroristic incidents are the most efficient. :-(

On a positive sidenote, looking out of my window, the trees are fully green again and
the sun is shining on a more and more regular basis. Guess I shouldn’t forget that I must be pretty
damn lucky as long as I live in a secure and stable political environment …

3 distros and KDE.

Fedora Core 3 having smoked some crack
I downloaded a trial version of the new VMware 5.0
since my favorite computer magazine wrote me it would be good,
and it all works just fine. To test it all, I downloaded iso images of Fedora Core 3, SuSE Linux 9.2
and Kubuntu Linux to have a look at what KDE looks like in
different distros.

Fedora Core pleased my eyecandy fetish with a good looking graphical
install, and had a quite polished overall appearance although a couple of things really annoyed me.
It didn’t seem to remember that I would login into KDE but instead held GNOME as default. Yum, which
is supposed to be the online update tool did quite a bad job, it would take hours just to parse the
dependencies of all packages only to tell me that I’m out of diskspace. Trying to remove a couple of
packages which I wouldn’t need anyway, it wanted me to first install a couple of others. Oh well,
guess it must be me …
SuSE also was quite polished and much more a native KDE
distro, with all necessary tools integrated into kcontrol. The installer looked much less polished
than Fedora’s, it chose text-mode to do all necessary stuff, but that’s really only a cosmetical
thing. What also striked me is that it needed much more interaction than the others and left me with
a couple of necessary things left to do (setup network, setup X, both with graphical tools at
Kubuntu finally, which was actually the distro I began with installed
fast and smooth, needed only one CD iso (FC3 needed 3, SuSE was installed from a 3.2GB DVD iso since
the netinstall wouldn’t work (segfault in early boot)). Everything went fine during the install and
even updating to the development release Breezy Badger was fairly easy.

Guess I’ll keep Kubuntu then, which is what I’m running on my workstation anyway. Still
nice to see what other distros offer and that the grass is not always greener on the other
side. :-) (Although it would really come handy to have the PyKDE toolchain fixed at some point …)

guidance’s displayconfig mockup.

a mockup of displayconfig
Last night, I visited Simon in order to discuss some
new stuff we want to put into displayconfig, one of the applications in guidance.
Besides discussing some minor issues, we made good progress with respect to the user
interface and code design of displayconfig, especially of the configuration of multiheaded setups.
We discussed how we wanted to design the user interface, so that it’s not only possible to do
“simple” things, such as switching resolutions. We’re planning to implement functionality to
configure a dual screen Xorg setup from within KDE. One of the results of yesterday night’s session
is the screenshot of a mockup, that should give some idea how that’s going to look like.
Moreover, we had a look at different solutions to detect hardware. Basically we need to know
the number of graphics adapters, which is pretty simple since they’re attached via the PCI bus in
most cases. More complex is the problem of detecting the number of monitors attached, the actual
size of monitors, the technical capabilities of the screens (such as refresh and sync rates). There
are a couple of tools which can help with that, but all of them have their problems and limits.
Mandrake ships ddcxinfo, which did a pretty good job detecting Simon’s TFT display and its
capabilities, but it pretty much sucked on my notebook, which was in that case reporting a display
size of 90″ (!!). xresprobe, which is shipped by e.g. Debian and Kubuntu let my notebook
screen flicker, which scared me a little, and it only managed to return my native resolution, but
not for example the sync and refresh rates. Then, there’s ddcxinfo-kanotix – obviously not packaged
for Debian in that incarnation. It printed out a lot of modelines, which is probably not too bad,
but also not sufficient for what we need. In other words: We still need a good way to get an idea of
the hardware topology of all display-related devices, suggestions – of course – are welcome (contact).

Also the configuration of the X server is a pretty complex complex issue since a lot of the
setup depends on the driver used. The most generic solution for a dual screen setup is
Xinerama. However, Xinerama has the disadvantage of limiting 3D / hardware
acceleration capabilities. Vendors like nvidia and ATi work around that in their drivers by
providing support for e.g. proper window placement from “merged framebuffer” mode, which is
a quite different setup with respect to xorg.conf compared to traditional Xinerama. So we
have to decide which way we want to do the configuration for the user, depending on the driver used,
the resolutions chosen and so on (Xinerama does work with different resolutions and color depths on
the respective ‘heads’, merged framebuffer does not seem to be capable of that) …

All in all, sticking our heads together was quite productive. Things are much clearer now
and there’s lots of code to be written. Sounds like we’re making good progress. :-)

really simple syndication and other miscellanea.

really simple syndication and other miscellanea.
This month is my month of exams. But you don’t want to hear.
Besides that, I now have
put all my blog stuff in a RSS feed and wrote the
necessary scripts to put everything back in shape.

Even better: I’ve got my notebook back which had a broken LCD. Since it was out of warranty
for about 2 months, I expected that this would cost me lots of money, but it didn’t! The friendly
guys from Asus repaired it and sent it back to me – yet I didn’t have to pay for that. I’m a happy
customer of them, still. :-) Good to see that there are hardware manufacturers who actually care
about their products and seem to provide good service to their customers.

Ow, and I saw that “all” the freedesktop people
have cool South Park alter egoes. Well, arent’t we all freedesktoppers?!?