Dinge, Zeugs und Sachen

Geekigster Abend seit langem... Man nehme: eine gute Mischung aus Partyvolk und Geeks, Alkohol, ein Trinkspiel und eine blöde Idee. Man lasse auf jeden Fall weg: einen Würfel. Problem: für jenes spezielle Trinkspiel wird einer benötigt. Was macht der gemeine Geek, wenn er keinen Würfel hat? Richtig: er programmiert sich einen. Los ging es damit (aller Code in Python, das heute mal wieder seine Würdigkeit als RAD-Sprache gezeigt hat):

import random

print random.randint(1,6)

Nicht jeder Drink schmeckt...

Spiel­tisch

Irgendwann wurde das Partyvolk übermütig und verlangte nach einer Klicki-Bunti-Lösung. Da ich ja sowieso grad im PyQt-Wahn bin und nie Alkohol trinke, konnte ich ja programmieren. Das Ende vom Lied:

FeM möge uns 1000x verzeihen für den Mißbrauch ihres Logos.

Im Prinzip simpel: die Software sagt, wer als nächstes welches Glas wahlweise zu trinken oder zu füllen hat und gibt dafür zwei Minuten Zeit (der Balken am oberen Rand). Ist der Betreffende zu langsam, sieht er sich damit konfrontiert:

Lahme Ente!

Spätfolgen...

Die ganze Würfelei ist natürlich mit netten Animationen untermalt (die Herrschaften wollten schließlich was geboten haben!). Was hab ich mir nen Wolf programmiert...

Ach ja, zum Thema Spätfolgen: sie hat nichtmal mitgespielt. Der doofe Hut ist neu und daher toll. Oder so... Wo ist mein Bett?

P.S: Auf Wunsch einer einzelnen (mir unbekannten) Person gibt es den Quellcode zum Runterladen. Natürlich ohne den ganzen FeM-Kram darin. Zum Ausführen ist Python und PyQt4 notwendig. Alkohol ist von Vorteil. Auch für die Ansicht des Codes, der... naja, gewöhnungsbedürftig ist.

Nach zweitägiger Suche: Python und QT können manchmal sehr hässlich zusammenstoßen, wenn es um die Lebensdauer von Objekten geht. Folgender Code:

class MainWindow(QMainWindow):
    [...]
    def initTreeView(self, top_level_cats):
        model = CategoryModel(top_level_cats)
        self.treeview.setModel(model)
    [...]

Sieht an sich erstmal unverdächtig aus: ein Model wird erzeugt (wie auch immer geartet) und dem QTreeView als Model übergeben. Scheint alles wunderbar, bis man es ausführt. Aus irgendeinem Grund bleibt der QTreeView grundsätzlich leer. Es werden zwar von dem Model unter Umständen noch einige Funktionen aufgerufen (in meinem speziellen Fall waren das headerData() und columnCount(). Keine Ahnung, ob das immer so ist), aber die eigentlich Daten werden nie dargestellt. Soweit, so schlecht.

Ein winzig kleine Änderung des Codes bringt die Lösung. Hier fast die gleiche Funktion:

class MainWindow(QMainWindow):
    [...]
    def initTreeView(self, top_level_cats):
        self.model = CategoryModel(top_level_cats)
        self.treeview.setModel(self.model)
    [...]

Der einzige Unterschied: statt einer lokalen Variable ist model nun ein Feld der umgebenden Klasse. Und siehe da: plötzlich funktioniert es. Wie kommt's? (Fast) ganz einfach: man könnte zwar annehmen, dass self.treeview.setModel(...) sich das Model irgendwie speichert, wenn es noch benötigt wird, aber das scheint nicht der Fall zu sein. Anscheinend werden die entsprechenden Aufrufe nur von der dünnen Schicht von PyQt4 an die zugrundeliegende QT-Bibliothek durchgereicht und die entsprechenden Pythonobjekte dann nicht weiter beachtet. Am Ende der Funktion geht das Element im ersten Fall out-of-scope und wird dann irgendwann mal vernichtet. Blöd nur, wenn QT dann bei der Darstellung des Views plötzlich was von dem Model will, dessen Objekt zu dem Zeitpunkt nicht mehr existiert. Weißt man es hingegen einem Feld in der umgebenden Klasse (zum Beispiel dem Fenster) zu, so existiert es so lang, bis dieses vernichtet wird (und damit auch sein View). Dann kann die QT natürlich nach Herzenslust nach den Daten des Views fragen und wird immer auf unserem Model-Objekt landen, wie das gewünscht ist.

Eigentlich logisch. Wenn man's einmal weiß...

Der Titel sagt es schon: es geht um Eclipse Ganymede und Subversion. Beides meiner Meinung fantastische Tools zur Softwareentwicklung, in Kombination allerdings gerade etwas zickig. Das Problem: bei Eclipse Europa (3.3) wurde meist für die Subversion-Integration das Plugin Subclipse verwendet. Für Ganymede (3.4) gibt's das allerdings noch nicht. Dafür gibt es ein neues Plugin direkt im Ganymede-Repository: Subversive. Dieses Plugin soll wohl bald standardmäßig in Eclipse integriert werden. Es ist quasi deckungsgleich mit dem schon bestehenden CVS-Plugin und integriert sich sehr gut in die Oberfläche.

So schick das Plugin ist: mir scheint, die Eclipse-Jungs und -Mädels haben bei der Zusammenstellung von Ganymede gepennt. Dummerweise ist nämlich der eigentliche Team-Provider integriert, die Library zum Zugriff auf die SVN-Repositories allerdings nicht. Die darf man sich zu Fuß nachinstallieren. Dabei darf man sich dann auch noch entscheiden, welche man nimmt. Ich hab mich letztlich für SVNKit entschieden, weil mir die Idee gefällt, allen Kram gleich in Java abzuwickeln, statt externe Libs einbinden zu müssen. Dummerweise begrüßt mich mein Eclipse bei der Installation von SVNKit mit folgenden Zeilen:

Cannot find a solution where both Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.1.I20080612-1500,0.7.1.I20080612-1500]] and Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0)] can be satisfied. Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0) Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.polarion.eclipse.team.svn.connector.feature.group/0.0.0 Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0) Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.polarion.eclipse.team.svn.connector.feature.group/0.0.0 Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0)

Ja, diese Fehlermeldung ist auch im Original so unlesbar. Nach längerem Suchen bin ich in einem Blog auf die Lösung gestoßen: Seit 3. August möchte SVNKit eine neuere Version von Subversive haben (oder andersrum, so 100% schlau bin ich noch nicht draus geworden). Die ist dummerweise nicht in den Ganymede-Repositories, sondern muss unter http://download.eclipse.org/technology/subversive/0.7/update-site/ extra bezogen werden. Diese URL packt man in die Update-Site, muss sie dann noch einmalig via "Manage Sites..." aktivieren und schon kann man sich ein neueres Subversive installieren, was dann auch mit SVNKit spielen mag. Schade, dass die Standardintegration in Ganymede so kaputt ist. Bis zum Nachfolger dauert es ja doch ein wenig und bis dahin sind wahrscheinlich schon einige an Subversion und Eclipse verzweifelt und benutzen glatt wieder CVS *brrrr*...

Update: Wie Deka in den Kommentaren angemerkt hat scheint es mit Subclipse 1.4 wohl doch einen Release für Ganymede zu geben.

Beim Radfahren kam uns heute spontan die Idee, dass man ja mal wieder kochen könnte. Also spontan de.rec.mampf angeschmissen, ein paar Leute eingeladen, eingekauft und raus kam:

Korianderlendchen von der Pute mit Knoblauch-Chiligarnelen

Nachzulesen ist das Rezept beim ZDF bei Volle Kanne

Grad von meiner Holden geschickt bekommen: Chinesisches Wohlfühlpflaster für Männer. Ich hab gleich mal ne Packung bestellt...