Wie realisiert Ihr Pluginfähige Anwendungen?

[guenni81]

Hallo zusammen,
mich würde einfach mal interessieren mit welchen Ansätzen Ihr selbst Pluginfähige Anwendungen realisiert. Bekanntlicherweise gibt es ja tausend Wege nach Rom.
Mir Persönlich gefällt hier der Weg den der QtCreator geht sehr gut (zumindest soweit ich dies bis jetzt Verstanden habe).

[RHBaum]

was willst du hoeren ?

wir haben 2 systeme parrallel.
eines COM basierend
eines mit reinem c++ Schnittstellenbasierend(Abstrakte klassen)

Ciao ...

[guenni81]

Mich interessieren die verschiedene Wege die es gibt um Anwendungen die Erweiterbarkeit über Plugins zu geben.

Ein mir bekanntes Beispiel hierfür wäre die Definition eines Interface (wobei dies ja immer definiert werden muß), das direkte Laden der .dll / .so und übergeben der Schnittstelle an das Plugin Host) damit dies dort seine Menüeinträge, etc. setzen kann.

Beim QtCreator wird dies z. B. ein wenig anderster abgearbeitet. Auch hier werden Schnittstellen definiert (diese werden ja immer benötigt). Die Exe Datei lädt zuerst das CorePlugin welches im Prinzip das Fenster und alle Standardfunktionen beinhaltet. Beim laden der gesamten Plugins geht der QtCreator ein Verzeichnis durch und parst die dort enthaltene xml (pluginspec) Dateien, prüft diese auf Ihre Abhänigkeiten und benötigten Versionsnummern. Erst anschließend wird die .dll / .so Datei geladen und initialisiert. Beim initialisieren bekommt das Plugin über eine statische Variable im Core Namespace Zugriff auf die Funktionalität des Coreplugins.

Ich hoffe mal das es eventuell jetzt Verständlicher wird was ich meine.

[franzf]

Beim QtCreator wird dies z. B. ein wenig anderster abgearbeitet. [usw.]

Aber das Prinzip ist doch das Gleiche! Wie das Laden jetzt stattfindet, welche Prüfungen durchgeführt werden müssen, usw. entscheidet der jeweilige spezifische Kontext. Wenn Plugins Abhängigkeiten haben können, muss das notiert und geprüft werden, wenn nicht ist eine Prüfung natürlich nicht notwendig. Gibt es Plugins/Interfaces/... auch noch in verschiedenen Versionen, muss natürlich auch das geprüft werden.

Du hast aber nach "Ansätzen" gefragt, und da denkt man zuerst an die Möglichkeiten der Erweiterung, und das ist halt
*) einfache Interfaces mit C++ + .so + usw. (ala Creator)
*) Interprozess (jedes Plugin ist ein eigener Prozess, Kommunikation via (z.B.) QProcess)
*) Scripting (QtScript, Python, ..)
*) usw.

[guenni81]

Da hast du natürlich Recht. Das mit den Ansätzen passt eigentlich auch soweit wie du es meinst. Der QtCreator war da wohl nicht unbedingt das beste Beispiel.

[RHBaum]

Wobei natuerlich auch vorlieben und technische besonderheiten zu beruecksichtigen sind:

Ich zum Beispiel bin Fan von C-Schnittstellen (ueber dll grenzen). Von meinen Kollegen werd ich deshalb gern als "unmodern" bezeichnet
Konnt mich leider ned durchsetzen. Nun darf ich bald C++ Schnittstellen nach python uebersetzen mit SWIG z.b.

Unsere Plugins mit Oeberflaeche malen selber auf "Devices". Meist nur simple konfigurationsdialoge.
Dazu bekommen sie nen Aufruf vom main ala showConfiguration und bekommen nen windows Handle mit uebergeben wo sie sich drauf zeichnen koennen. Das ist leider ned so problemlos !
Wenn ich es noch mal neu machen koennt, wuerd ich die grafik komplett aus den Plugins nehmen und nen mehr oder weniger komplexes oberflaechenfreies PropertySystem bauen.
Vom technischen her sicher nen verlockender weg, aber auch widerstand von anderer Seite !
Die Plugins werden teilweisse von anderen Firmen nach unseren Schnittstellen entwickelt, und nutzen diese Gestalterische Freiheit eben gern um die Dialoge mit Herstellerinformationen zu füttern MHO an falscher stelle ^^ diejenigen die die Dialoge bedienen werden wohl nie Einkaufsentscheidungen treffen ^^) und uns Ihr Corporate Identity zu präsentieren (was oft ned so gut mit unserem harmoniert).

Ciao ...