PC-Lüfter machen umso mehr Lärm, umso schneller sie laufen. Wenn man sie aber nur mit reduzierter Drehzahl laufen lässt, dann kühlen sie natürlich leider auch entsprechend weniger. Für meinen Desktop-PC habe ich mir darum einen 220mm-Lüfter besorgt, mit dem Gedanken, dass dieser auch bei halber Drehzahl noch soviel Luftstrom produziert wie zwei laute 80mm-Lüfter. Allerdings habe ich beim Kauf nicht darauf geachtet, dass er nur einen 4-pin-Molexstecker hat und mit diesem konstant auf 12V läuft. Darum habe ich einen alten 60mm-CPU-Lüfter um dessen Kabel erleichtert und an den neuen Fan gelötet:

So sollte er sich an die Lüfterregelung anschließen und regeln lassen. Hm, geht aber nicht, das Tachosignal fehlt. Und warum? Weil der Hersteller bei diesem Modell (AK-F2230SM-CB) 5 Cent gespart hat indem er einen Transistor und zwei Widerstände weggelassen hat. Toll. Den Hall-Sensor hingegen haben sie eingebaut. Na gut, was tut man dann als schnellen Workaround? → man lötet einen Kondensator zwischen Plus und Signal, dann ist auch die Lüfterregelung wieder glücklich:

Ich hatte einen 100nF-Kondensator zu Hand; ein etwas anderer Wert ist aber vermutlich auch nicht kritisch.

Wenn man in Qt eine Klasse implementiert, sollte man tunlichst darauf achten, dass alle instantiierten Attribute this als parent haben. Andernfalls kann es nämlich sein, dass irgendwann der Garbage-Kollektor auf das offenbar elternlose Kind-Objekt stößt und es im Sinne von "ist das Kunst oder kann das weg" in die Tonne wirft. Und dann hat man den Salat. Ist mir hiermit passiert: Das Elternelement hier ist XYPlot, welches ein Attribut der Klasse Measurement besitzt. Bei mir gab es unreproduzierbare SIGSEGV segmentation faults, was immer auf irgendein Problem mit ungültigem Pointer hinweist. Beim Debuggen habe ich dann festgestellt, dass kurz zuvor der Dekonstruktor von Measurement aufgerufen wurde - obwohl das zugehörige XYPlot-Objekt noch existierte. Woran lag es? ⇒ Ich hatte vergessen, dem Kind-Objekt zu sagen wer sein parent ist. Im Konstruktor der Elternklasse XYPlot also m_Measurement mit this instantiieren: Also besser gut aufpassen bei so was, sonst kann das Debugging richtig ätzend werden.

Wenn man ein Projekt aufsetzt, dann hat man meist eine Versionsnummer im Format a.b.c.d, mit

1. a = Hauptversionsnummer, ändert sich eigentlich nur bei massiven Änderungen
2. b = zeigt an, dass neue Features hinzugekommen sind
3. c = zeigt an, dass etwas gepatched bzw. geupdated wurde
4. d = gibt den Revisionsstand der Software im Versionsverwaltungssystem an.

Bei SVN gibt es die Möglichkeit sich per Code-Kommentar eine Revisionsnummer direkt in den Quelltext schreiben zu lassen. Das sieht dann beispielsweise so aus: Und wird von SVN beim Commit ersetzt zu Vorausgesetzt natürlich, dass die Datei die entsprechenden SVN-Keywords gesetzt hat:

So weit, so gut. In dem Beispiel oben ist die Revisionsnummer 178. Wenn es jetzt aber noch eine zweite Datei gibt und Änderungen an dieser comitted werden, dann bleibt in main.cpp die 178 stehen. Warum? Weil die SVN-Revisionsnummer dateibezogen ist - nicht projektbezogen! Das ist ja jetzt nicht ganz das, was wir haben wollten. Zum Glück, gibt es aber ein Tool, welches genau für unsere Zwecke gedacht ist: svnversion! Um eine globale Revisionsnummer zu erhalten erstellt man eine leere Datei revision.h, checkt sie nicht in SVN ein und schreibt folgendes in die *.pro-Projektdatei eines Qt-Projekts: Zur Erklärung: Als erstes wird qmake mitgeteilt, dass es eine zusätzliche Abhängigkeit gibt (PRE_TARGETDEPS, Zeile 1) - nämlich besagte revision.h-Datei. Dann werden ein paar Variablen mit den SVN-Revisionsinformationen gefüllt. Mit dem Kommando svnversion -n (Zeile 4) erhält man die SVN-Revisionsnummer. Der Parameter -n bewirkt, dass die Ausgabe keinen Zeilenumbruch enthält. Die Variable SVN_REVISION enthält somit die Ausgabe von svnversion, ausgehend vom Pfad, in der die Projektdatei liegt. Wenn die lokale Arbeitskopie allerdings modifiziert, unvollständig ausgecheckt oder zu einer anderen Revision geswitched wurde, ist die Revisionsnummer nicht einfach eine Zahl, sondern nach dem Schema [abc:]xyz[M|S|P] aufgebaut, wobei xyz die Headrevision ist (für Details einfach mal in der Konsole svnversion -help eingeben). Aus diesem Grund teilen wir die Ausgabe anhand des Trennzeichens ":" auf (Zeile 6), nehmen das letzte Element dieser Liste (Zeile 8) und entfernen alle M-, S- und P-Zeichen (Zeilen 10 - 14). In Zeile 16 wird qmake mitgeteilt, dass es ein zusätzliches Target revtarget gibt (QMAKE_EXTRA_TARGETS), welches die, im Unterordner /code befindliche, revision.h-Datei ist und welche stets neu zu erstellen ist (Zeile 39). Das Befüllen der revision.h erfolgt in den Zeilen 19 - 37. Zu beachten ist, dass die erste echo-Ausgabe mit einem einfachen > umgeleitet wird. Dadurch wird der der Inhalt der Datei überschrieben. Anhängen weiterer Zeilen erfolgt mit >>. Die echo-Anweisungen für Unix müssen übrigens deshalb extra escaped werden, weil ein echo /* generated file - do not edit */ erst alle Dateien unter / auflisten würde, dann "generated file - do not edit" ausgibt und dann alle Dateien im aktuellen Verzeichnis auflistet.

Ich habe Qt5 auf dem Raspberry Pi 2 kompiliert und installiert. Das war zwar ein bisschen umständlich, lief bis jetzt eigentlich ohne unüberwindbare Probleme. Aber jetzt hol' ich gleich die Kettensäge und geb' dem Drecksteil den Rest! Den Code des Küchencomputers portiere ich derzeit auf Qt5 und QtQuick 2.4 und mache ihn unabhängig von Plattform und Auflösung. Er läuft inzwischen gleichermaßen problemlos auf Windows 7 wie auf Debian Wheezy mit LXDE. Nur auf dem Raspberry nicht. Da werden manche Texte nicht angezeigt und das Layout ist verschoben. Und QML wirft mir unzählige Fehlermeldungen entgegen - allen gemein ist, dass sie mit string-Properties zu tun haben. Also habe ich in den letzten Stunden ein Minimalprojekt angelegt um das Problem nachzustellen, einzukreisen und dann eine passende Lösung zu entwickeln. So was kostet Zeit, funktioniert aber immer. Nur hier nicht. Dieser Mistcode bringt mich noch um den Verstand: import QtQuick 2.4 import QtQuick.Window 2.2 Window { id: myWindow width: 400 height: 200 visible: true Text { id: myText text: "12" } Text { x: 30 text: myText.text Component.onCompleted: { myText.text = "99" } } } Das funktioniert genau so, wie es soll. Wenn man aber "99" durch "34" ersetzt, bleibt der zweite Text leer und QML meldet Unable to assign [undefined] to QString in der Zeile text: myText.text. Allerdings nur auf dem Raspberry. Unter Windows und einem x86-Linux macht es, was es soll. Was zur Hölle soll das? Warum gerade "34"?? Warum nicht z.B. "42"??? Nerv! Ich spiele schon mit dem Gedanken wieder zurück auf Qt4.8 zu portieren ...