Dakons blog

I like that model/view stuff. Really. Even if some of my last commits added lines of code it felt like I removed hundreds of lines as the new code is much more readable and straightforward. But there are some things that are simply not there (or they are hidden so good that I can't find them):

QTreeView::resizeColumnsToContent()

It simply does not exist. I have no idea why: resizeColumToContents(int) is there and both functions are in QTableView.

query sort settings

Yes, I know about QTreeView::sortByColumn(). But once you have set this (e.g. by clicking on the header) how can you find out which column is currently the sorting one? Or the direction? My current hack will probably just store it once the mymodel::lessThan() is called. But this is ugly. Really, really ugly. I mean, this stuff must be stored somewhere in the view. Why can't I simply query it?

After I finally managed it to get KGpg clean of K3Process I decided to take one step further: Q3Wizard. The first step was to rename Q3Wizard to QWizard in the ui file and see what happens. Well, it went rather well. Porting the code around that to QWizard was actually pretty fun. But for one reason or another I can't get the UI right. The Qt4.3 designer (at least the copy I got from openSuSE 10.3) does not care about QWizard at all. With the old one it was simple to add a page or something but the new one simply does nothing. And it seems that noone in the parts of trunk I usually check out and compile really uses QWizard. KPPP folks tried but it doesn't look from a quick glance that it worked too well for them.

So if anyone has a working example of how a Qt4 QWizard with 3 pages has to look like: come over and rescue me.

And now let's look if I owe SaroEngels one or two beers when he get's KGpg running on Windoze. Good luck man, I don't want your job. At least not as a hobby, it's pain enough to get paid for that.

Ich hatte echt befürchtet am Samstag Nachmittag Langeweile zu haben. Oder nicht zu wissen was ich mit meinem Geld anstellen soll. Und außerdem hatte ich heute morgen sowieso nichts besseres vor. Und ob die Speicherkarte die Linux-Tests überstanden hat wollte ich eigentlich nie herausfinden müssen. Einen Rant über eine unmögliche Sortierreihenfolge von Dateien auf der SD-Karte oder den nicht funktionierenden USB-Port wollte ich eigentlich auch niemals schreiben.

Verrotte in der Hölle, du Arsch!

Nein, keine Sorge, es geht diesmal nicht um unseren Rollstuhlmiehlke; da ist sowieso nichts mehr zu machen. Es geht eher um Beobachtungen wie von Scytale. Die Fahrt in öffentlichen Verkehrsmitteln sollte unbedingt mit Kopfhörern, Ohrstöpseln oder ohne Hörgerät erfolgen, ansonsten setzt man sich als normaler Mensch einem immensen Risiko aus.

Mein Erlebnis gestern Abend im Bus: Bei dir könnte ich mir echt vorstellen, dass du bei McDonalds heiratest. Au weia.

Judging from the fact that I'm not able to speak a single word French r757040 is probably the strangest commit I have ever made. But, hey, KGpg is my playground these days and if I cope around with encryption even simple things in French can't be impossible.

If you look very close you might say "hey, there is one new translation in that commit" but believe me: it's not. I added the context for this message for a good reason: to tell anyone where to copy that thing from. That of course includes myself ;)

I was trying to delete some items from my model. According to the documentation I tried it with beginRemoveRows() and endRemoveRows(). Well, it didn't work. Crashes everywhere.

The encapsulation of the insert and remove operations with these begin and end functions also enables the model to manage persistent model indexes correctly.

QAbstractItemModel Class Reference

Well, actually it doesn't. After one and a half day I found a way how to do it a way that it doesn't crash anymore. The last hour (well, it was after midnight) I really went mad because I shoot myself in the foot. I started with:

class KGpgRootNode: public KGpgNode {
protected:
	KGpgItemModel *m_model;
...
KGpgRootNode::KGpgRootNode(KGpgItemModel *model)
	: KGpgNode(NULL)
{
	m_model = model;
...

Every item is a child of this root node and now has access to the model. Since there are indirect clients the access was encapsulated in a function. Bad thing: when the root item is destructed the client items can't call upwards to invalidate themselfs. My fault. Next try:

class KGpgNode {
protected:
	KGpgItemModel *m_model;
...
KGpgNode::KGpgNode(KGpgNode *parent)
{
	if (parent != NULL)
		m_model = parent->m_model;
	else
		m_model = NULL;
...

Insert an hour of confusion and head-shaking here. Why the hell is m_model always NULL? Of course because I forgot to remove it from KGpgRootNode so it was hiding the member of KGpgNode. After this was found the rest was simple:

KGpgNode::~KGpgNode()
{
	m_model->invalidateIndexes(this);
}

void
KGpgItemModel::invalidateIndexes(KGpgNode *nd)
{
	for (int i = 0; i < persistentIndexList().count(); i++) {
		QModelIndex idx = persistentIndexList().at(i);

		KGpgNode *n = nodeForIndex(idx);

		if (n != nd)
			continue;

		changePersistentIndex(idx, QModelIndex());
	}
}

Gerade habe ich bei meinem Autoden Ölstand mal wieder in den normalen Bereich gebracht. Dabei ist mir wieder einmal aufgefallen wie sehr so ein Auto doch eine Black Box ist. Irgendwie erinnert mich das alles an einen Windows-Rechner. Alles funktioniert irgendwie solange es funktioniert und wenn nicht muss man wissen was man tut.

Ich vermisse bei einem Auto das Äquivalent zu free und top. Jeden Mist den man kontrollieren will muss man sich irgendwo zusammensuchen. So ein Nagios für Autos wäre ja schon eine tolle Sache. Das mir mein Auto eine Email schreibt wenn ich Depp mal wieder vergessen irgendwas nachzufüllen wäre schon irgendwie übertrieben. Aber mit vertretbarem Aufwand (d.h. ohne Werkstatt oder teures Zusatzgerät) gelegentlich etwas in der Richtung von "tail -f /var/log/messages" machen zu können wäre echt hilfreich.

I just have to say: this model/view stuff rocks. I spent the last day or so porting different parts of the key manager of KGpg to model/view interfaces. It's not even half way done but I like the direction it's going. Some important basic things are still missing, like everything that has to do with updating the model contents after the initial setup. But what I already was able to port over was just a walk through the park. A long one, but still at a reasonable pace while stopping here and there to watch was is besides your way.

Things like item sorting, implementing a filter or opening a context sensitive popup menu are really straight forward. One Qt3 compatibility class is already gone and the ported code looks somehow less obfuscated. What really amazes me is how fast it works, there is no flickering or anything. And some of the ported functions even work ;)

Nachdem ich gestern kurzfristig meine "Apollo", ihres Zeichens eine HP Apollo 705, zerlegt hatte musste ich mal wieder auf der Konsole ran. Dabei fiel mir ein Bug auf, der schon seit meinen ersten Versuchen auf der Maschine besteht. Wie ich gerade festgestellt habe besteht er scheinbar seit den allerersten Versuchen von überhaupt irgendjemandem auf so einer Maschine: die Konsole ist nicht weiß auf schwarz, sondern blau auf schwarz. Etwa zu dem Zeitpunkt an dem der Kernel den Framebuffer initialisiert wird die Schrift blau und bleibt so. Sollte es irgendjemand schaffen das mal zu richten lobe ich hiermit eine Kiste Bier dafür aus. Nicht das ich mehr als ein Mal im Jahr einen Bildschirm an die Kiste stecken würde, aber ich finde das gehört endlich mal gefixt.

1-2-3: ich komme! Los, raus aus euren Löchern! Ich darf Geld ausgeben, also nicht verstecken!

Was wir vorhaben ist eigentlich ganz simpel: wir bauen uns eine Asterisk-Telefonanlage. Nach außen geht es über mehrere ISDN-Leitungen, die natürlich irgendwie in den Rechner kommen müssen. Da ich keine Lust habe eine ganze Batterie von Karten in den Rechner zu stecken brauche ich also Karten, die mehr als einen S0-Bus verkraften. PCIe wäre toll, aber normales PCI ist auch ok. Dann wollen wir doch mal gucken:

AVM

Wenn der Begriff "ISDN-Karte" fällt ist mein erster Gedanke immer "AVM". Das nenne ich mal gutes Marketing. Mag vielleicht auch daran liegen, dass ich jahrelang selbst über eine AVM-Karte ins Netz gegangen bin. AVM hat jedenfalls aus mir völlig unerfindlichen Gründen nur noch Karten im Angebot, die lediglich einen einzigen S0-Bus verkraften (namentlich A1 und B1). Die ganzen "großen" Karten (C2, C4 und T1) sind aus dem Programm geflogen. Ok Leute, das war ja nichts.

Eicon

Wirklich zu tun hatte ich mit dem Laden nie, allerdings ist mir der Name in den entsprechenden Menüs im Kernel schon mal über den Weg gelaufen. Anscheinend ist der Laden mittlerweile aufgekauft oder sonstwie umbenannt worden. Und die ISDN-Karten scheinen auch dort Auslaufmodelle zu sein.

HST

Von dem Laden hatte ich noch nie was gehört, aber unser Händler schlug mir eine der Karten vor. Dank eines Links von ihm fand ich auch schnell den Linux-Treiber für deren Karten. Ich entwickle ja nicht umsonst hauptberuflich Gerätetreiber als das mich das nicht reizen würde. Also flugs runtergeladen und gestöhnt:

• schon auf den ersten Blick fällt auf das der Treiber offensichtlich sowohl Linux 2.4 als auch Linux 2.6 mit dem selben Code unterstützen will. Die Art und Weise wie Geräte erkannt, verwaltet und angesprochen werden hat sich ja auch nur grundlegend geändert :| Dieser Versuch erscheint mir so sinnvoll wie ein Versuch von VW für alle Golf-Modelle vom Golf I (1974) bis Golf V (2003) das selbe Getriebe zu benutzen. Kann man machen, muss man aber nicht.
• Auf den zweiten Blick wird klar das es sich bei dem Treiber um einen gemischten Treiber handelt, dessen eine Hälfte als Binärmodul, die andere im Quellcode vorliegt. Dies ist ein lizenzrechtlicher Kniff der Hersteller um interne Schnittstelleninformationen nicht offenlegen zu müssen. Häufig gehen damit aber Einschränkungen bei den unterstützten Kernelversionen einher.
• Der Coding-Style sieht überhaupt nicht Kernel-artig aus. Das allein wäre ja nicht so schlimm, der Treiber ist ja nicht Bestandteil des Kernels. Was mich aber wirklich nervt sind die Bezeichnungen für die Datentypen. Statt der üblichen C-Typen wie unsigned int verwendet man eigene Definitionen wie WORD, DWORD usw. . Das ganze sieht auf den ersten Blick ziemlich nach einem umgestrickten Windoze-Treiber aus. So etwas habe ich schon mal gesehen und ich weiß spätestens seitdem: das ist überhaupt keine gute Idee.
• Ich bin mir noch nicht sicher, aber ich will die Maschine möglicherweise im 64 Bit-Modus betreiben. Die Kombination der beiden vorherigen Punkte lässt da nichts gutes erahnen.
• Ach wie nett: das Interface für den Interrupt-Handler passt nicht mehr zu dem, der in aktuellen Kernels verwendet wird.
• Ich sehe da spezielle Definitionen für den Fall das der Kernel auf einer Multiprozessor-Maschine läuft oder nicht. Die typische Interpretation von soetwas ist: ihr habt das Locking verpfuscht.
• Das hier ist einfach zu hässlich um nicht zitiert zu werden: öffnet mal im Archiv die Datei sa_fio.c. Dort gleich in der ersten Funktion wird der Rückgabewert der Funktion filp_open() geprüft. filp_open() liefert (zumindest in aktuellen Kernels) einen Pointer zurück. Das Makro IS_ERR stammt aus dem Kernel und erlaubt herauszufinden ob der Rückgabewert einen Fehlercode enthält oder einen gültigen Pointer. Wenn jedoch ein Fehlercode zurückgegeben wird (IS_ERR() liefert wahr zurück) prüft man die zurückgegebene Adresse und lässt das ganze möglicherweise doch durch. Wenn man sich dann mal anguckt wie IS_ERR eigentlich definiert ist stellt man fest, dass es eigentlich genau das macht. Allerdings nur auf einer 32 Bit-Maschine. Warum wird hier ein Makro verwendet und anschließend mit ein wenig Voodoo das ganze nochmal so ähnlich (aber unportabel) implementiert? Die Funktion gibt dann im Fehlerfall einfach 1 zurück anstatt den codierten Fehlercode auszuwerten. Wer braucht denn auch schon Fehlercodes.
• Pointer werden einfach mal auf DWORDs gecastet und munter wieder zurück. Zum Glück ist der Typ auf unsigned long definiert, so dass da tatsächlich immer ein Pointer reinpasst. Warum man nicht einfach den Pointer herumreicht erschließt sich mir aber nicht. Die Variablen heißen ganz nebenbei auch noch handle und man hat sich einen eigenen Typ HANDLE definiert, der einem void-Pointer entspricht. Warum nicht den benutzen?

Insgesamt sieht das Zeug jedenfalls überhaupt nicht vertrauenserweckend aus, ganz abgesehen davon das es in unserem Rechner mit einem neuen Kernel nicht funktionieren wird. Gut, ihr bekommt also auch kein Geld von uns.

Digium

Diese Firma hat Asterisk entwickelt, wir können also davon ausgehen das die Karten mit Asterisk auch zusammenarbeiten. Mein Freund Jani sagte er hätte den Treiber auch im Quellcode, allerdings muss ich die Details da noch untersuchen. Wäre natürlich schön, denn das scheint im Moment so ziemlich unsere letzte Chance zu sein.

Kleines Detail am Rande: die entsprechenden ISDN-Karten kostet fast so viel wie der Rest des Rechners.