Aufwandsabschätzung: C++ Programm mit Python plugins

[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.

[Francesco]

Ich bin noch an ein paar tote Punkte, oder wie ich sagen soll, angelangt bzw. ein paar Sachen, die so nicht hinzubekommen sind.

a) Also man kann nur Slot exportierte Funktionen einbinden
b) man hat dann keinen Zugriff auf andere Membervariablen von haus aus?
bsp: xxView *xView; Auch wenn das public definiert ist, dann ich auf den Zeiger nciht zugreifen. zB. Ich übergebe das App Objekt, dann kann ich nicht auf das darunterliegende (meist ein view object) zugreifen? So muss ich dem Python script die einzelnen Instanzen der Objekte mitgeben, die ich brauche? Sonst könnte ich eben mit den Pointern selbst im script die Objekte aufrufen.
c) wenn ich zb KrusaderView *GetMainView() {return mainView;} )wobei
mainView ein Pointer zu Krusaderview ist), im python script GetMainView aufrufen, bekomme ich nicht den KrusaderView pointer, sondern None

Das heisst ich müsste alle möglichen Objekte beim Python aufruf mitgeben?

bsp:

Code: Alles auswählen

    #code vorher
    Kross::Action action(this, "MyScript");
    filename = "<basisdir>/krusader/krusader/krosshello1.py"
   
    action.setFile(filename);
    action.addObject(App, "obj1l");
    action.addObject(mainView, "obj2");
    action.addObject(mainView->activePanel, "obj3");
   
    action.trigger();

Wo ich doch ein bisschen Zweifel habe, ob das dann wirklich dafür geeignet ist.
Vielleicht weiss noch jmd. etwas

[lunar]

@Francesco: Du kannst nur und ausschließlich Slots einbinden. Keine öffentlichen Member-Funktionen, keine öffentlichen Member-Variablen, usw. Für jede Variable muss ein Getter als Slot definiert sein, denn sowas wie eine „Variable“ existiert zur Laufzeit nicht mehr (C++ hat keine Introspection).

Zur Kross-spezifischen Frage kann ich nichts sagen, ich habe Kross nie benutzt.

[Francesco]

@Francesco: Du kannst nur und ausschließlich Slots einbinden. Keine öffentlichen Member-Funktionen, keine öffentlichen Member-Variablen, usw. Für jede Variable muss ein Getter als Slot definiert sein, denn sowas wie eine „Variable“ existiert zur Laufzeit nicht mehr (C++ hat keine Introspection).

Zur Kross-spezifischen Frage kann ich nichts sagen, ich habe Kross nie benutzt.

Ok, danke.
Dann ist das doch nicht so geeignet. Vielleicht für eingeschränktes Scripting, aber nicht in dem Stil von zb gedit.

Was mir einfach noch nicht eingeht, ist warum ich beim Funktionspointer (KrusaderView *) None zurückbekomme

Auch wenn ich das im .h file unter slots definiert habe

Code: Alles auswählen

public slots:
    KrusaderView *GetMainView() {return mainView;}

denn zB. folgendes funktioniert ja

Code: Alles auswählen

public slots:
    int  GetTestVar() {return 2;}

[lunar]

Ich habe keine Ahnung, was der Unterschied zwischen „eingeschränktem Scripting“ und dem „Stil von GEdit“ ist, aber Kross wird in verschiedenen KDE-Anwendungen für weitreichende Automatisierungsfunktionen verwendet. In KOffice und KTorrent kann man so ziemlich alles „skripten“ …

Und „KrusaderView *“ ist keine Funktionszeiger, sondern ein ganz normaler Zeiger auf ein Exemplar eines Typs. Müsste ich raten, würde ich einfach mal davon ausgehen, dass Kross Objekte nicht automatisch exportiert. Du musst den View halt auch exportieren. Dieses Verhalten würde ich zumindest erwarten, denn der automatische Export von Objekten wäre kaum sinnvoll zu implementieren.

[Francesco]

Ich habe keine Ahnung, was der Unterschied zwischen „eingeschränktem Scripting“ und dem „Stil von GEdit“ ist, aber Kross wird in verschiedenen KDE-Anwendungen für weitreichende Automatisierungsfunktionen verwendet. In KOffice und KTorrent kann man so ziemlich alles „skripten“ …

Das Problem ist, dass es zwar ganz kleine Beispiele bei kross gibt und die ganz großen wie Koffice. Ein mittleres wäre zum Anschauen schön. Auch wie die Plugin verwaltung funktioniert, wie scripts beim Startup geladen werden und sie sich "einnisten" (zB ins menü)

Und „KrusaderView *“ ist keine Funktionszeiger, sondern ein ganz normaler Zeiger auf ein Exemplar eines Typs. Müsste ich raten, würde ich einfach mal davon ausgehen, dass Kross Objekte nicht automatisch exportiert. Du musst den View halt auch exportieren. Dieses Verhalten würde ich zumindest erwarten, denn der automatische Export von Objekten wäre kaum sinnvoll zu implementieren.

Ok, das habe ich schon fast geahnt, das wäre zu einfach. Das Problem sehe ich bzw. man müsste von haus aus eine ganze Sammlung exportieren, damit die scripts gleich zugriff auf alle möglichen Objekte haben.

KTorrent sieht auch mit den Möglichkeiten interessant aus. Ist zwar groß genug, aber ich hoffe noch überschaubar. Der hat dann auch einen Scriptloader, den man ebenfalls brauchen könnte.