Programmieren

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.