Ich verwende ein PlugIn-System meist so, wie es viele Spiele machen: keine
DLL's, die nativen Code beinhalten, sondern das Hauptprogramm stellt alle für das PlugIn-System verfügbaren Funktionen als Lua-
API zur Verüfgung, auf die man dann Scripten kann.
Die Plugins selbst bestehen dann aus einer oder mehreren lua-Dateien (oder compilierte luac-files) und haben zusätzlich eine TOC-File mit z.b. Versions-Informationen, welche Dateien zusammengehören,
API-Version usw. Insgesamt so ähnlich wie z.B. das Addon-System von WoW.
Für mich war das ein gangbarer Weg für ein Plugin-System, da man so die volle Kontrolle vom Host hat, was ein Plugin darf und was nicht (keine Dlls, die geladen werden) Der Nachteil dabei ist natürlich, dass die interne
API alle möglichen Dinge abdecken muss wie z.B. neue
GUI-Elemente über die Lua-
API dynamisch erstellen, binden etc. Das macht das Ganze natürlich aufwändiger.
Die Host-Anwendungen sind bei mir dann auch meistens in vollständiger Modul-Bauweise gebaut und werden über ein "Core-Plugin" verbunden.
So ist man auch flexibel, die Reihenfolge beim Start der eigenen Anwendung vollständig selbst festzulegen, welche Fenster geöffnet werden, was initialisiert wird etc. und alles über das Core-Plugin zu ändern.
(dazu muss natürlich die
API jegliche
GUI-create-Funktionen, Initialisierungs-Routinen der Module, Berechungsfunktionen o.Ä. nach aussen porten und braucht zumindest eine kleine Schicht, die das Window-Management übernimmt)
Ich weiss nicht, ob so ein Ansatz für dich in Frage käme, ich bin damit bis jetzt eigentlich immer ganz gut gefahren.
Zitat
Baum-Darstellung
