Aufwandsabschätzung: C++ Programm mit Python plugins

[Francesco]

Hallo, mich würde interessieren,

1) welcher Aufwand es wäre, zB (hypothetisch) den filemanager krusader mit einer Python plugin Schnittstelle auszustatten.

Ich habe mir den Gedit angesehen und finde es verwirrend. Anscheinend werden hier die "Schnittstellen C sourcen" generiert. Mit was weiß ich nicht.
( PyObject *, ...) Ich finde das verwirrend mit den Makefile.in, Makefile.am,
...

Hängt vielleicht auch damit zusammen, weil gedit sowohl c++ plugins als auch python plugins unterstützt.

2) PyQt. Das gesamte Programm ändern zu PyQt. (Werde ich natürlich nicht machen, aber mich würde eine Einschätzung interessieren. Das wäre schon sehr viel Arbeit, oder? Aber ich denke, im Prinzip müsste man (fast) alles in Python abbilden können

[Panke]

ich habe noch nie ein C++/Qt Programm auf PyQt portiert, kann zum Aufwand also nichts qualifiziertes Beitragen. Da Krusader aber ein KDE-Programm ist, solltest Du dir eventuell Kross angucken.

[Leonidas]

Ich habe mir den Gedit angesehen und finde es verwirrend. Anscheinend werden hier die "Schnittstellen C sourcen" generiert. Mit was weiß ich nicht.
( PyObject *, ...) Ich finde das verwirrend mit den Makefile.in, Makefile.am,
...

Naja, wie man Python embeddet steht in der Dokumentation und übermäßig schwer ist es nicht. Die in und am-Dateien gehören zu den Autotools, solltest du dir ggf. vorher mal ansehen.

2) PyQt. Das gesamte Programm ändern zu PyQt. (Werde ich natürlich nicht machen, aber mich würde eine Einschätzung interessieren. Das wäre schon sehr viel Arbeit, oder? Aber ich denke, im Prinzip müsste man (fast) alles in Python abbilden können

Vermutlich wäre das schon einiges an Aufwand. Mir ist der genaue Funktionsumfang des Programmes nicht bekannt und es hängt auch ab ob du von Null anfängst oder den Code einfach nur "übersetzt", Bleibt auch die Frage - wozu?

[Francesco]

Naja, wie man Python embeddet steht in der Dokumentation und übermäßig schwer ist es nicht. Die in und am-Dateien gehören zu den Autotools, solltest du dir ggf. vorher mal ansehen.

Ok. Ich bevorzuge immer ein konkretes Beispiel oder ein richtig abgeschlossenes Projekt, anstatt seitenweise zu lesen, wo man dann das meiste gar nicht braucht. Eben so eine gedit plugin architecture Doku wäre toll. Es steht zwar viel über plugins, wie programmieren aber der Hintergrund wäre eben für mich sehr interessant. Aber stimmt, da wird mir nicht ausbleiben, mir die (für mich sehr trockene Materie) der Autotools anzusehen, wenn ich da weiterkommen möchte.

Vermutlich wäre das schon einiges an Aufwand. Mir ist der genaue Funktionsumfang des Programmes nicht bekannt und es hängt auch ab ob du von Null anfängst oder den Code einfach nur "übersetzt", Bleibt auch die Frage - wozu?

Die Frage wozu. Weiß ich auch nicht. Wird natürlich schwierig zu sagen sein. Machen würde ich das eh nicht, nur interessieren. Einmal die Sysiphusarbeit, und ab dann würde die Weiterentwicklung viel schneller gehen. So wären meine Vorstellungen für eine Motivation. Ich meinte den Code "übersetzen".

[Francesco]

ich habe noch nie ein C++/Qt Programm auf PyQt portiert, kann zum Aufwand also nichts qualifiziertes Beitragen. Da Krusader aber ein KDE-Programm ist, solltest Du dir eventuell Kross angucken.

Danke für den Tip, das sieht interessant aus.

[mkesper]

Hmm, ich werde noch nicht so ganz schlau daraus, wieso man kross benutzen sollte statt PyQt bzw. PyKDE.

[lunar]

Hmm, ich werde noch nicht so ganz schlau daraus, wieso man kross benutzen sollte statt PyQt bzw. PyKDE.

Kross hat eine ganz andere Zielsetzung als PyQt und PyKDE zu tun. PyQt und PyKDE sind sprachspezifische Bibliotheksanbindungen, Kross dagegen ist eine per se sprachunabhängige Skripting-Schnittstelle für Anwendungen.

Kross baut quasi u.a. auf PyQt und PyKDE auf und bietet Anwendungen eine einfache Schnittstelle zur Einbettung eines Python-Interpreters und zum dynamischen Export eigener Objekte nach Python. Natürlich eigentlich sprachunabhängig …

[Francesco]

Ich kann dazu noch nichts sagen, weil ich kross noch nicht kenne/kannte.

Im Prinzip sind es zwei fragen, die ich gestellt habe. Wäre vielleicht besser gewesen, die auseinanderzuhalten und einen jeweils eigenen thread dazu zu öffnen. Also
1) "Übersetzen" einer Qt C++ Anwendung in python (qt). Das ist aber ncith so wichtig, weils eh nicht realistisch ist (weil der Aufwand wäre zu hoch)

2) Scriptable machen (am besten natürlich mit pyhton). Es geht mir um die "Umbauarbeiten". Den Aufwand möglichst klein zu halten (welch Überraschung) wäre gut und doch auf eine Vielzahl von Funktionen zugreifen zu können. Da ich mich im Dschungel der Automake nciht auskenne (soll ichmir das eigentlich antun, frage ich mich). Gibts da noch eine weitere (oder vielleicht einfachere) Variante mit SWIG (oder ist das aufwändiger/nicth zielführend)?

Das Kross hört sich ja sehr vielversprechend an:
Aus (http://techbase.kde.org/Development/Tut ... troduction):

The Kross scripting framework provides full Python, Ruby and KDE JavaScript scripting support. The goal was to limit the work needed on applications to have them fully scriptable and to provide a modular way to transparently integrate additional interpreters and in that way extend your application with a new scripting-backend without any new line of code and even without any recompile.

[Hyperion]

Hast Du Dir mal Kross angeguckt? Die Tutorials zeigen doch recht schön, wie das geht. Ich hatte mir das auch mal angeguckt, da ich mit dem Gedanken spielte Scribus damit auszustatten, aber das ganze aus Zeitmangel erst einmal weit hinten in meiner "will ich mal machen"-Queue eingereiht.

Du kannst natürlich weitersuchen, aber die Kross-Tutorials sahen mir sehr einfach aus.

Alternativ guck Dir eben Programme an und wie die das realisieren. Ich habs mir bei Scribus seinerzeit mal angeguckt und fands eher häßlich (Zumal die Python Schnittstelle auch mies aufgebaut ist; das ist alles extrem wenig pythonisch). Allerdings hatte ich es dennoch geschafft, die mir fehlenden Funktionalität einzubauen.

[Francesco]

Ja, ich finde sie auch gut. Und die Beispiele habe ich soeben probiert.

[Leonidas]

2) Scriptable machen (am besten natürlich mit pyhton). Es geht mir um die "Umbauarbeiten". Den Aufwand möglichst klein zu halten (welch Überraschung) wäre gut und doch auf eine Vielzahl von Funktionen zugreifen zu können. Da ich mich im Dschungel der Automake nciht auskenne (soll ichmir das eigentlich antun, frage ich mich). Gibts da noch eine weitere (oder vielleicht einfachere) Variante mit SWIG (oder ist das aufwändiger/nicth zielführend)?

Automake und SWIG sind ganz andere Sachen! Autotools generieren Makefiles mit denen das Programm gebaut werden kann, SWIG generiert Bindings zu C-Libraries für Python (Extending, was du aber suchst ist Embedding). Ich würde in der Hinsicht wohl auch am ehesten Kross ins Auge fassen.

[Francesco]

Ja danke, das ist ja einstimmig. Kross ist in der Tat interressant.

Ich habe schon ein wenig probiert. Qt ist wie gesagt noch ein Rätsel. Werd ich mir wohl ein bisschen anschauen müssen/können/dürfen. Anscheinend sind dann von Python aus nur Funktionen sichtbar, die mit public slots oder public Q_SLOTS definiert wurden.

Irgendwie finde ich das Qt eigenartig (wahrscheinlich stellt sich im nachhinein heraus, dass das Konzept sehr gut ist, wie ich auch schon nachlesen konnte). Zudem werden dann moc files erstellt, die compiliert werden. Na, dann werde ich einmal ein kompaktes Tutorial suchen, das eine kurze Übersicht darstellt und auch das Konzept dahinter (und das "warum so" interessiert mich immer am meisten) erklärt.

@Leonidas: Ja, schon wieder verwechselt. Ich brauche das (für den fall von plugins von "innen heraus") und swig wie in wxPython erweitert ja Python (extending). Hier ist das embeding.

[lunar]

"public slots" und "public Q_SLOTS" ist dasselbe. In Qt werden Methoden, die quasi in die Metainformationen der Klasse aufgenommen werden, "Slots". Nur diese Methoden kann man dann zur Laufzeit abfragen und dynamisch aufrufen. Aus diesem Grund können auch nur Slots über Kross exportiert werden.

Die moc-Dateien sind generierter Quelltext, denn Du wirklich absolut komplett ignorieren kannst. In diesem Quelltext stehen allerlei Metainformationen und unterstützender Quelltext, der von Qts Objektsystem benötigt wird. Ist alles nicht wichtig, nicht mal, wenn man viel mit C++ und Qt programmiert.

All das ist nötig, weil C++ anders als Python oder Java nur sehr schwache Unterstützung für Introspection bietet, weswegen Qt ein eigenes Objektsystem mit eigenen Objektmetadaten implementiert. Ob das gut ist, hängt von der Sichtweise ab. Für C++ ist es gut, aus Sicht von Python nur Ballast.

[Francesco]

Danke lunar, sehr interessant. Was ich jetzt noch gerne wissen würde. Das Kross ist ja nur für qt. Um vergleichbares für gtk oder wxPython zu haben, muss man das embedding manuell machen? Oder gibt es hierfür auch eine "Interfaceunterstützung"?

@bzgl. Leonidas. Bitte korrigieren, wenn ich falsch liege. Es geht ums Verständnis.

Also SWIG bietet für Python eine Zugriffsmöglichkeit zu C++ Programmen oder Modulen.

Wenn ich jetzt von C++ auf Python zugreifen will, und dieses Python script wiederrum C++ Methoden bzw. Objekte nützen will, sind das ja 'embedding' (also die Möglichkeit von C++ auf Python zuzugreifen) und 'exending' (Python kann dann darunterliegende Methoden von C++ verwenden) in einem.

Für den Teil von extending ist ja swig gedacht(?) Also verstehe ich die Aussage nicht ganz, dass SWIG etwas ganz anderes sei. Es ist die Teilmenge (also das was den Bereich extending abdeckt(?)

[Leonidas]

Um vergleichbares für gtk oder wxPython zu haben, muss man das embedding manuell machen? Oder gibt es hierfür auch eine "Interfaceunterstützung"?

Also weder GTK+ noch GNOME bieten Möglichkeiten wie Kross, da muss man (bisher?) die Interpreter selbst einbinden. Alternativ kann man vermutlich aucb Kross in GTK-Applikationen nutzen, aber das ist eher unüblich dass man zwei Toolkits gleichzeitig nutzt.

[Francesco]

Hmm, ja, ich meine z.B. Gedit. es ist nicht in pygtk sondern 'normales' c++ gtk. Ich habe mir das angesehen und finde es sehr kompliziert. So wäre meine frage, ob so etwas mit Swig oder Kross einfacher lösen zu wäre. Interessant ist jedenfalls, wenn Kross nicht nur auf qt beschränkt wäre. Vielleicht gings auch für wxWidgets Programme.

@lunar: Das hiesse auch, dass man quasi die interessanteren Methonden (von der man glaubt, dass sie von einer externen Scriptsprache verwendet werden können), als slot definierten muss (auch wenn man sie als slot selbst möglicherweise gar nciht benötigt)? Habe ich das richtig verstanden?

[Leonidas]

Hmm, ja, ich meine z.B. Gedit. es ist nicht in pygtk sondern 'normales' c++ gtk. Ich habe mir das angesehen und finde es sehr kompliziert.

Also erstens ist Gedit wie fast alle GNOME-Programme in C geschrieben und zweitens verstehe ich nicht ganz was du mit kompliziert meinst. Das der Code so lang ist, liegt daran dass C so lowlevel ist, da helfen die ganzen GLib-Funktionen auch nur bedingt (nicht umsonst gibt es C# und Vala für GNOME).

[Francesco]

Ok, wahrscheinlich hast du recht. Ja, da habe ich mich vertan, es ist C und nicht c++.

[lunar]

@Francesco: Ja. Jede Methode, deren Metainformationen (e.g. Name, Signatur, etc.) zur Laufzeit zur Verfügung stehen sollen, muss als Slot markiert werden. Das gilt nicht nur für Kross, sondern auch für andere Komponenten, die zur Laufzeit Objekte exportieren (e.g. QtDBus und QtScript).

[Francesco]

Super, danke euch allen, ihr habt mir sehr weitergeholfen.