Architektur und Verzeichnisstruktur

Überblick

Das Projekt ist in mehrere Schichten gegliedert, damit UI, Protokolllogik, Plugins und Datenhaltung getrennt bleiben:

• UI und App-Binding im main-Bereich
• Protocol-/Core-Logik im libdino
• Erweiterungen in plugins
• Build/Tests in scripts und build-Artefakten

Warum diese Trennung wichtig ist

• Änderungen an der Oberfläche lassen sich gezielter testen.
• Plugin-Module (z. B. OMEMO/OpenPGP/MQTT) können isoliert validiert werden.
• Plattform-spezifische Aspekte (Linux/Windows) sind klarer auffindbar.

Datenfluss auf Sicht

1. Konto und Sitzung werden initialisiert.
2. XMPP-Module übernehmen Stream- und Sicherheitsfeatures.
3. UI reagiert auf Ereignisse aus den Modul- und Modellebenen.
4. Datenbank speichert verschlüsselt den persistenten Zustand.
5. Pluginpfade greifen bei Bedarf in Automatisierungs- und Integrationsbereiche ein.

Modulgruppen (Auswahl)

• plugins/openpgp: Schlüssel- und Signaturlogik.
• plugins/omemo: OMEMO-Stacks und Session-Handhabung.
• plugins/http-files: Dateitransfer via HTTP-Pfade.
• plugins/mqtt: MQTT-Interaktion.
• plugins/bot-features: Botmother-/Automatisierungspfad.

Wann du welcher Ebene prüfst

• UI-Verhalten: main, Dialoge, Ansichtskomponenten.
• Gesprächs- und MUC-Fehler: Core-Pfade in libdino + Plugin-Pfade.
• API-/Automatisierungsproblem: relevante plugins/*-Komponenten.
• Build-/Abhängigkeitsproblem: scripts und meson-Konfiguration.