Plugininterface

[STEVMASTER]

weiß jmd, wie ich ein toolkitunabhängiges (GTK/Qt) Plugininterface auf die Beine stellen könnte, für einen Bildbetrachter?
Später soll es eine GTK- und Qt-Version geben, aber die Plugins sollen ohne neu kompilieren zu müssen austauschbar sein...
Jmd ne Idee?

[anda_skoa]

C oder C++?

Ciao,
_

[STEVMASTER]

->seit wann gibt es eine C-Schnittstelle für QT??

[peschmae]

-> seit wann kann man in einem C++-Programm keine C-Pluginschnittstelle einbauen?

MfG Peschmä

[anda_skoa]

Also C++

Ist im Grunde recht einfach:
wenn die Applikation Aufrufe am Plugin machen soll, braucht man eine Basisklasse für Plugins mit entsprechenden virtuellen Methoden.

Wenn die Plugins Aufrufe an der Applikation machen sollen, braucht man eine entsprechende Klasse, die dann die API für die Plugins bildet, am besten auch als Interface.

Dann brauch man ansich nur mehr eine Factory Funktion, die mit dlsym gefunden werden kann und bei Aufruf eine Plugin Implementation erzeugt.

Sagen wir zum Beispiel


class Application;

class Plugin
{
public:
Plugin(Application* app) : m_app(app) {}
virtual ~Plugin() {}

virtual char* loadImage(const std::string& filename, int& dataLength);

protected:
Application* m_app;
};




class Application
{
public:
virtual ~Application() {}

virtual void showError(const std::string& error);
};




#include "plugin.h"

class DummyPlugin : public Plugin
{
public:
DummyPlugin(Application* app) : Plugin(app) {}
virtual ~DummyPlugin() {}

virtual char* loadImage(const std::string& filename, int& dataLength);
};

extern "C"
{
Plugin* createPlugin(Application* app)
{
return new DummyPlugin(app);
}
}




#include "dummyplugin.h"

char* DummyPlugin::loadImage(const std::string& filename, int& dataLength)
{
dataLength = 0;
return 0;
}


Siehe auch: http://www.linuxjournal.com/article/3687

Ciao,
_

[STEVMASTER]

Danke, das hat mir schonma sehr geholfen...
Das Problem is nur, dass die PlugIns von QT nach GTK auch portabel sein sollten...
Nur alles in Klassen zu kapseln zu aufwändig ...Das Toolkit, das OpenOffice benutzt, kann soweit ich weiß, jetzt in der neuen Version sich jeweils an GTK- oder QT-Stil anpassen, aber ich glaube das is nich performant genug....
Das Programm selbst soll nativ in QT bzw. GTK implementiert werden, nur das Problem bei der PlugIn-Schnittstelle is dann, dass die Plugins nich austauschbar sind...
Ich hatte schonma überlegt, wie etwa bei Kommander die Oberfläche in XML-Dateien auszulagern, aber das is dann auch nich schnell, und löst immer noch nich das Problem, dass später alles gekapselt werden muss...
Oder weiß jmd. von nem Projekt, wo der SIGNAL/SLOT-Mechanismus von QT gekapselt wurde, sodass man ein einheitliches Interface hat und sich nur zu entscheiden braucht, ob QT oder GTK?
Meint ihr das ist möglich, oder sind GTK / QT doch zu verschieden voneinander?

[peschmae]

Danke, das hat mir schonma sehr geholfen...
Das Problem is nur, dass die PlugIns von QT nach GTK auch portabel sein sollten...
Nur alles in Klassen zu kapseln zu aufwändig ...

Heisst das die Plugins beinhalten auch Teile der GUI? Also nicht nur "Backend"-Funktionalität?


Das Toolkit, das OpenOffice benutzt, kann soweit ich weiß, jetzt in der neuen Version sich jeweils an GTK- oder QT-Stil anpassen, aber ich glaube das is nich performant genug....

Bei OpenOffice wird nur das Theme angepasst und die Icons. Aber das geschieht nicht automatisch passend - es gibt einfach Themes die den Defaults von KDE und Gnome sehr ähnlich sehen.

So was ähnliches (was dir ja nach dem was ich verstehe nicht weit genug reicht) kann man problemlos erreichen (Gtk-Qt Theme Engine und ähnliches).



Meint ihr das ist möglich, oder sind GTK / QT doch zu verschieden voneinander?

Es läuft - wenn du nicht irgendwo zu Kompromissen bereit bist - darauf hinaus das du halt alle Gui-Sachen zwei mal schreiben musst. Würe ich eher nicht ;)

Wenn IBM SWT für Qt freigegeben hätte (bzw. die Lizenzsituation das erlauben würde - wobei das tut sie afaik jetzt. SWT-Qt gibts trotzdem nicht. Hab den Überblick irgendwie nicht mehr ganz.) dann könntest du dich eventuell über den Umweg aus der Affäre ziehen. Da IBM das aber nicht getan hat bleibt das ein hypothetischer Ausweg.

MfG Peschmä

[STEVMASTER]

>Bei OpenOffice wird nur das Theme angepasst und die Icons. Aber das geschieht nicht >automatisch passend - es gibt einfach Themes die den Defaults von KDE und Gnome sehr >ähnlich sehen.
Ne, soweit ich weiß, wird Oo.org in der Version 2 das darunter liegende Toolkit verwenden, also GTK oda QT

>So was ähnliches (was dir ja nach dem was ich verstehe nicht weit genug reicht) kann man >problemlos erreichen (Gtk-Qt Theme Engine und ähnliches).
Stimmt. Ich möchte nicht, dass das Aussehen von nem andern Toolkit gezeichnet wird, um es besser zu integrieren, sondern dass das Toolkit unter der jeweiligen Oberfläche nativ ist...


>Es läuft - wenn du nicht irgendwo zu Kompromissen bereit bist - darauf hinaus das du halt alle >Gui-Sachen zwei mal schreiben musst. Würe ich eher nicht ;)
Dadurch müssten aber für GTK- und QT einzeln Plugins geschrieben werden, was nur zu einer Gabelung führt, sodass eines "der beiden Programme" am Ende schlechter weiterentwickelt wird...

[anda_skoa]

Danke, das hat mir schonma sehr geholfen...
Das Problem is nur, dass die PlugIns von QT nach GTK auch portabel sein sollten...

Um welche Art von Plugins geht es denn? Ist ja ein ziemlich allgemeiner Begriff.


Das Programm selbst soll nativ in QT bzw. GTK implementiert werden, nur das Problem bei der PlugIn-Schnittstelle is dann, dass die Plugins nich austauschbar sind...

Warum nicht?

Ciao,
_

[STEVMASTER]

Die Plugins sollen sehr flexibel sein.
Es soll solche geben, die sich in die Werlzeugleiste integrieren und solche in Form eines Dialogs. In jedem Fall wird die GUI im Plugin enthalten sein bzw. in eine Datei ausgegliedert sein, auf jeden Fall mit dem Plugin fest verbunden sein...
Das Problem ist, dass QT und GTK einander nicht kompatibel ist, d. h., wenn ich ein PlugIn für GTK schreibe, dass sich das nich in eine QT-Anwendung integrieren wird. Also müsste für QT und GTK einzeln PlugIns geschr. werden - was keine saubere Lösung ist.
Ich hatte vor, die GUI-Funktionen von QT und GTK in gleich aussehende Klassen zu kapseln, sodass es ein einheitliches GUI-PlugIn-Interface gibt und es von der verwendeten Version abhängt, ob in Wirklichkeit GTK oder QT verwendet wird, aber ich glaube das scheitert daran, dass GTK und QT zu verschieden sind...
->oder?

[anda_skoa]

Das sollte schon gehen, es spricht zum Beispiel technisch nichts dagegen, wxWidgets auf Basis von Qt zu implementieren, eine Implementation auf GTK2 Basis gäbe es da bereits.

Hat theoretisch sogar den Vorteil, dass wxWidgets so wie auf Window theorethisch auch auf die Desktop API implementiert werden könnte, also zum Beispiel GNOME und KDE.

Wenn du nur eine kleine Anzahl verschiedener GUI Möglichkeiten in den Plugins hast, ist eine eigene Abstraktion vielleicht schneller machbar als wxWidgets für Qt zu implementieren, muss aber auch selber gewartet werden.

Ciao,
_

[STEVMASTER]

Ich muss ma schaun' ob die Portierung nach QT von wXWidgets nich ne Nummer zu groß is..

[anda_skoa]

Sonst vielleicht XUL, das UI Framework von Mozilla.

Da gibt es zumindest Ansätze eines Interpreters für KDE
http://xul.sourceforge.net/post/2004/06/xul_titan_interview_george_staikos_of_xul_for_qtkd e_fame_part_i.html
http://xul.sourceforge.net/post/2004/06/xul_titan_interview_george_staikos_of_xul_for_qtkd e_fame_part_ii.html

In diesem Fall würde ich aber auf jeden Fall vorher die beteiligeten Entwickler kontaktieren, ob und wieviel da weiter entwickelt wird.

Ein wxWidgets Port auf Qt wäre natürlich cool, möglicherweise gibt es da auch andere Interessenten, die da mitarbeiten würden.

Ciao,
_

[STEVMASTER]

XUL kommt mir unter'm Mozilla irgendwie lahm vor, aber vielleicht liegt das nur an nem' langsamen Interpreter. So wie es aussieht, werde ich wohl doch keine vorhandene LIB verwenden, sondern meine eigene Abstraktion der Klassen erstellen, damit die Klassen usw. mehr meinen Programmiervorstellungen entsprechen und ich mich einfach wohler fühle, auch wenn das mindestens genauso viel Arbeit wird wie die Portierung von wxWidgets nach QT. Außerdem finde ich, dass bei der GTK-Version von wxWidgets sich nich alles "echt" GTK anfühlt, ich will dann auch, dass z.B. dass die Original-Iconloader von QT bzw. GTK verwendet wird, und dass trotz der Portabilität ein größtmögliches QT- bzw. GTK-Feeling erreicht wird.
Also - yet another toolkit-Toolkit ;-)

[anda_skoa]

XUL kommt mir unter'm Mozilla irgendwie lahm vor, aber vielleicht liegt das nur an nem' langsamen Interpreter.

Wenn ich das Interview mit George Staikos richtig verstehe "rendert" Mozilla das XUL.
Der Ansatz von Georges Bibliothek ist ja native Widgets zu benutzen.
Ließe sich sicher auch auf GTK+ übertragen.


Außerdem finde ich, dass bei der GTK-Version von wxWidgets sich nich alles "echt" GTK anfühlt, ich will dann auch, dass z.B. dass die Original-Iconloader von QT bzw. GTK verwendet wird, und dass trotz der Portabilität ein größtmögliches QT- bzw. GTK-Feeling erreicht wird.


Dabei muss man natürlich berücksichtigen, dass Qt und GTK nur Toolkits sind, also keine Desktop API.
Viel Look&Feel ist bei den großen DEs in deren Libs, also zB KDELibs.

Ich bin mir nicht ganz sicher, ob sich der Aufwand lohnt für ein paar Plugins eine eigene Abstraktion zu machen und sie anschliessend für alle Variationen zu implementieren und zu warten.

Kann man nicht vorher festlegen, welche UI Bedürfnisse die Plugins haben werden?

Ciao,
_

[BeS]

Hallo,
also von den Plugin sachen ansich habe ich nicht so viel Ahnung.
Aber wenn das Problem nur die signal/slots sind, was ich glaube aus einer der Beiträge herausgelesen zu haben.
Dann könntest du anstelle der Qt signal/slots libsigc++[1] nehmen um die Signale zwische plugin und Programm hin und her zu schicken, dass geht immer mit C++ unabhängig vom Toolkit.

[1] http://libsigc.sourceforge.net/

[STEVMASTER]

Die Problematik der Desktop-APIs hab' ich auch schon durchdacht..
Für mich ist es nicht wichtig, dass das Ganze später auf andere Betriebssysteme portabel ist (dazu reicht eine Lösung ala` wxWidget schon aus) , sondern dass unter der jeweiligen Desktop-Oberfläche unter Linux es sicht bestmöglich integriert bei möglichst wenig Lib-Abhängigkeiten. Ich denke aus diesem Grund werde ich meine Kapselung auf den KDE-LIBs anstatt auf reinen QT-Libs basieren lassen (sein wir mal ehrlich, wer QT drauf hat benutzt es fast nur für KDE, es gibt zwar auch WMs die QT nutzen, aber die sind längst nich soo verbreitet, und die meisten haben parallel trotzdem noch KDE), allerdings werde ich die andere Version auf reinem GTK aufbauen, da es nicht nur GNOME gibt, das auf GTK fußt, und viele deswegen auch nicht die GNOME-Libs installiert haben. Außerdem entspricht das Look&Feel von GNOME weitgehend dem von GTK, und die GNOME-Libs enthalten größtenteils Erweiterungen, die zur Vereinfachung dienen oder gar nichts mit der eigent. GUI zu tun haben....
Danke, libsigc++ ist n' guter Tipp...