Dakons blog

Ich wollte an dieser Stelle nur mitteilen, das mich am gestrigen Abend erneut die Polizei aus dem Haus gescheucht hat. Diesmal hat jemand in meiner Etage, aber in einem durch eine Brandschutztür abgetrennten anderen Flur, etwas Plastik auf dem Herd verschmoren lassen. Der beißende Qualm zog durch den Flur und die Herkunft war nicht so trivial zu entdecken. Bei der jetzt angeordneten brandschutztechnischen Untersuchung fällt dann hoffentlich auch mal die defekte Brandschutztür zum Treppenhaus auf.

Bei größeren Einsätzen in Ludwigshafen bin ich ja normalerweise nicht vor Ort, weil sowas meistens passiert wenn ich im Urlaub oder am Wochenende bei Anja bin. Heute ist mein Plus abgebrannt, der direkt im Nachbarhaus war. Das ganze Chaos, das insbesondere die Polizei hier veranstaltet hat, werde ich ein andernmal dokumentieren, aber für einen ersten Eindruck hier die kläglichen Überreste (vermutlich etwa 20 Minuten nach Brandausbruch).

Nachdem es mal meine Daten geschreddert hat (zu Zeiten von SuSE 8 oder so) habe ich von ReiserFS immer die Finger gelassen. Es gibt aber Behauptungen das noch schlimmere Dinge passieren können wenn man es einsetzt. Wobei ich mich der Meinung von Dick Johnson darüber anschließe.

After fregl gave a good tip how I could improve the models of KGpg I ran into some strange thing after a while. The Q_ASSERTS() in modeltest.cpp were not that hard to debug (although it took me 2 hours for 4 small fixes) but after this I ran into another one probably everyone has seen more than once:

ASSERT failure in QList<T>::at: "index out of range", file /usr/include/QtCore/qlist.h, line 393

Not particularly helpful in my minds. The bad thing is that you can attach a debugger on this, drkonqi doesn't come up and so you actually don't know more than before. Arguing on this on #kde-devel caused gkiagia to step up with a smart solution that is too useful to get lost:

static void qtMessageHandler(QtMsgType type, const char *msg)
{
	fprintf(stderr, "%s\n", msg);
	if (type == QtFatalMsg)
		abort();
}
				 
int main()
{
	qInstallMsgHandler(qtMessageHandler);
	...
}

After some programs from kdeutils were adopted we today had a meeting on #kde-utils to do some brainstorming about the further directions.

The biggest topic was a discussion about a successor of kwallet and how it could be brought to live. Things like PAM integration or not, rewrite the GUI from scratch and other ideas came up. I must confess I did not follow every detail since I had to visit my bank to pay for my new Linux toy.

To get at least something visible done lemma created a projects page for us. We decided to name him responsible for the web stuff so we can blame someone if there is work not done ;)

Finally, if you don't know what I want to say with the topic: some time we decided to make the life a bit easier for everyone and just switch the channel to German. Since everyone had that as first language anyway it was no big deal ;) A few minutes ago Riddel came in and we had to switch back (in fact, we didn't really do). We're flexible in this way. German, English, C++, I don't think anyone would argue ;)

Regardless of what release cycles we will have in future, the next release will come. Depending on how much time you can spend on hacking KDE it might also be there rather soon. Nevertheless the same things will happen for every major release: a bunch of new strings have to be translated.

While the translation teams for Greek, Ukrainian and Portugese are obviously competing for the 100% crown (go on, guys! *g*) other teams fell way behind them. That is not a problem yet, as trunk is still very much work in progress. But one or the other day the string freeze will come and then there is a bunch of work to do. Keep in mind that every percent is more than 1000 strings to translate.

While Germany has a great amount of KDE coders the number of strings untranslated e.g. in this team is big. Many modules from playground have noone actually caring about them. Worst example is playground-network with more than 2000 strings, which is completely untranslated. New translators are very welcome, also we have some requirements. I don't think the other language teams will send you home when you step up to help them, so ask them.

Translation is a good entry point if you want to contribute to KDE (the other one is writing documentation) and don't want to or are not able to do coding. Of course you have to know both english and the language you want to translate to rather well. Nevertheless it's a great help for the module translation maintainers if you even pick only the low hanging fruits and translate the trivial 20% of strings from a big module so he or she only needs to do a quick review. Many terms are rather common between many programs (think of the "File" menu entries and the descriptions in the about box) so you can just copy them from other places without making too much mistakes.

I found the way to the translation team by coding in KGpg. As I'm a native speaker of German I thought it would be best if I not only write the English strings, but the German ones, too. Since I exactly know what happens at certain points in code it was very easy for me to find a useful translation. Afterwards the translation team only went by and polished some wordings, but again I saved them some work that they could spend on other modules. So if you are a maintainer of a program and are a good writer in a non-English language: contact your translation team and ask if they need help for your program (or anywhere else).

And for all those that are not sure what the heck I meant in KGpg with one or the other string: just ask me. The number of string changes until the release should be rather small for KGpg, the work I plan to do is only internal and shouldn't normally touch the strings. So if you translate it now hopefully nothing of your work should get lost and you have some time for other modules later.

By the way: the translation results for the documentation are even worse than the GUI ones (hey Greek team, where are you there? *g*). Be extra careful if you want to work there to check if the documentation still matches the program features. If not mail the documentation author first with a patch to improve the English documentation or ask someone else to assist you with that. A good starting point is the #kde-docs channel on Freenode.

Gestern war Abendmahl. Das habe ich in der Bibel mal gelesen. Heute ist Konfirmation. Darüber habe ich nichts gefunden. Aber am Tag nach dem Abendmahl wäre eigentlich ein anderer Programmpunkt mit "K" an der Reihe gewesen: die Kreuzigung. Spielverderber.

Cebit is close. In fact this is like "in about an hour". While we still need some volunteers to help us at the booth I think it would be nice when even those who are at the fair for only one day would come over and say hello. I'll be there at the end of the week for some time.

As your favourite KGpg guy I will of course happily sign your keys if you are around. Close to us is as always the heise booth, one of Germanys biggest computer magazines. They will also sign your key for free.

For those in need of SSL certificates CAcert.org is near us and I also can give you some points if you like.

So, don't forget your fingerprint and at least one ID card with photo if you want to get your key signed. If you want to get assured for CAcert you need a second document with photo (like German drivers licence).

Ein an dieser Stelle nicht näher bezeichnetes System nervte uns seit einigen Tagen damit, dass wir von unseren Karten beim Starten keine verwertbaren Informationen mitgeteilt bekommen. Die Anmeldung eines PCI-Devices bei einem Betriebssystem läuft normalerweise so, dass man dem System mitteilt welche Art von Karten man unterstützen möchte, typischerweise bezeichnet durch die Hersteller- (Vendor) und Geräte-Kennung (Device). Zurück bekommt man dann eine Struktur, die alle möglichen Informationen über das Gerät enthält: Interrupt-Nummer, Adresse der Speicherbereiche, Länge der Speicherbereiche usw. .

Leider ist dieses Stück Software nicht normal. Das Gerät wurde gefunden, allerdings war die Struktur an nahezu allen Stellen leer. Wenn ich direkt das Gerät gefragt habe lieferte es mir aber zurück, dass z.B. ein Interrupt konfiguriert wurde. Zugriffe auf die Karte funktionierten auch einwandfrei. Interrupts waren jedoch trotz aller Tricks nicht möglich.

Schließlich änderten wir entnervt die Angabe zur Geräteklasse von "Coprocessor" nach "Data Acquisition" und aus dem Stand heraus funktionierte alles. Welche Angabe nun richtiger ist darüber lässt sich vermutlich streiten, fest steht: das Gerät kann beides (und es wird auch für beide Zwecke eingesetzt).

I'm trying to prepare KGpg for KDE 4.1. While there is still a lot of work behind the scenes that changes the way the application works there are a lot of places that only need some Qt/KDE knowledge and are not related to all this encryption stuff.

The big goal for KGpg 2.0 is to get rid of all this Qt3 compat stuff. After this it's time to take a look for the next big step. The decision is if KGpg should stay alone and integrate better with libgpgme or if it's a better step to integrate with Kleopatra.

For those who are interested in pushing KGpg into shape here are some things that could be done without much knowledge of the internals. If you are interested just drop me a mail or ask me when I'm hanging around on #kde-devel.

• Make the length of the keyid shown configurable: very simple, you just have to do the GUI stuff
• Port the wizard over to QWizard: I have some code to do the background stuff, someone just has to do the ui file
• Get rid of K3ListBox in conf_servers.ui: probably trivial
• Make searching in Keysmanager work again: you only need to know how to iterate over all visible items of a QTreeView