Ga naar inhoud

Overzicht van de architectuur

Het plug-insubsysteem is uit drie onderdelen opgebouwd, alle onder Components/:

Onderdeel Zichtbaarheid Verantwoordelijkheid
PluginApi Publiek Zuiver abstracte interfaces + waardetypen. Geen Qt, geen Scintilla, geen interne header van MTE — alleen de standaardbibliotheek.
PluginHost Intern Laadt, bezit en verdeelt de plug-ins. Qt is hier een implementatiedetail (achter de schermen gebruikt het QPluginLoader).
Plugins Eigen makelij Voorbeeld- en ingebouwde plug-ins; elk een eigen CMake-doel dat alleen van PluginApi afhangt (en van Qt, wanneer de inheemse backend gebruikt wordt).

Ontwerpbeginselen

  • Backend-onafhankelijk contract. Alle typen van PluginApi wonen in namespace MTE::plugin en mogen geen enkele header van Qt, Scintilla of intern van MTE invoegen. Dat is wat een toekomstige Python-backend in staat stelt hetzelfde contract te vervullen zonder de weerstand van Qt.
  • Geen typen van derden door de publieke API heen. Plug-ins zien nooit typen van Scintilla of Qt; de host bemiddelt tussen de interne IEditorView en de publieke IEditorService.
  • Overal RAII. Een opdracht, een menu-item, een dokpaneel of een gebeurtenisinschrijving registreren levert een token of een inschrijvingsgreep op. Die vernietigen heft de registratie van de bijdrage op. Plug-ins houden hun tokens als leden vast, zodat in shutdown() alles automatisch afgebroken wordt.

Levenscyclus

Elke plug-in implementeert één interface, IPlugin:

class IPlugin {
public:
    virtual ~IPlugin() = default;
    virtual PluginInfo info() const = 0;
    virtual bool       initialize(IPluginContext& ctx) = 0;
    virtual void       shutdown() noexcept = 0;
};
  • info() levert POD-metagegevens op (id, name, version, vendor, description, apiVersion).
  • initialize(ctx) ontvangt een dienstenzoeker IPluginContext. De plug-in pakt de diensten die zij nodig heeft en registreert haar opdrachten, menu's, panelen en gebeurtenisinschrijvingen.
  • shutdown() draait bij het afsluiten; omdat bijdragen RAII-tokens zijn, komt het afbreken er meestal op neer dat u de leden laat vernietigen.

Geen herladen tijdens het draaien

Een plug-in inschakelen, uitschakelen, installeren en verwijderen worden alle bij de volgende start van kracht. De host laadt of ontlaadt tijdens het draaien nooit plug-incode — dat houdt het model eenvoudig en omzeilt het Windows-probleem «een geladen DLL kan niet verwijderd worden».

Vinden

De host doorloopt, op volgorde:

  1. <exe-dir>/Plugins/ — de meegeleverde plug-ins van eigen makelij.
  2. <AppLocalData>/Plugins/ — de installatiemap per gebruiker.
  3. Paden uit de omgevingsvariabele MTE_PLUGIN_PATH.

Elke map wordt doorzocht op losse bibliotheken en op één niveau van directe submappen (de indeling <id>/ per plug-in die een installatieprogramma oplevert). Het vinden gaat niet dieper.