Embedded-App-Shell
hex-browser ist eine Embedded-App-Shell für Systeme, die eine stabile und zielgerichtete Benutzeroberfläche brauchen. Auf Basis des Qt-6/QML-Stacks unterstützt er mehrere Tabs und vereint natives Flutter, Web-Apps, QML-Apps, <so>-Plugins und RTSP-Streams, sodass Anwendungsteams in ihrem eigenen Ökosystem bleiben können, statt die komplette Embedded-UI für jedes Gerät neu aufzubauen.
hex-browser ist weniger als Browser-Wrapper zu verstehen, sondern vielmehr als Embedded App Shell und Kiosk-Starter. Web-Apps sind dabei nur ein unterstützter Inhaltspfad neben nativem Flutter, QML-Szenen, .so-Plugins und RTSP-Streams.
Dasselbe Deployment kann natives Flutter, Remote-Web-Anwendungen, lokale QML-Apps, pluginbasierten nativen Code und Live-Video-Feeds kombinieren, ohne die Shell zu wechseln.
Fullscreen-Verhalten, Rotation, Popup-Policy, persistenter Speicher, Navbar-Verhalten, Tastatur-Handling, Screenshots, VNC und Debug-Schalter werden zentral über die Konfiguration gesteuert. In Kombination mit ttmdaemon erweitert sich der steuerbare Konfigurationsumfang deutlich.
hex-browser passt zu Umgebungen, in denen Bediener einen dedizierten Ablauf, klare Zustände und vorhersagbares Recovery brauchen.
Maschinen-HMIs, Linien-Dashboards, Alarmzustände und touch-orientierte Bedienoberflächen für die Industrieautomation.
Wall Panels, Energie-Dashboards, Raumsteuerung und Orchestrierung vernetzter Geräte mit einer dedizierten Kiosk-Oberfläche.
Verschachtelte Web-Tools, Service-Konsolen und kontrollierte Popup-Flows innerhalb einer verwalteten Kiosk-Shell.
Eine saubere Bühne für Navigation, Tab-Wechsel, Plugin-Laden, Remote-Zugriff und weitere Browser-Funktionen in Bewegung.
hex-browser stellt einen nativen Plugin-Pfad bereit, damit Teams die Shell für ihre eigenen Geräte, Protokolle, Medienpfade und Anwendungsmodelle erweitern können.
Das öffentliche Beispiel-Repository zeigt den Einstiegspfad über das HexBrowserPluginInterface für native Erweiterungen und QML-basierte Plugin-UIs.
Beispiel-Repository öffnenFlutter wird als natives Plugin hinter der Shell integriert. Für das Anwendungsteam bleibt es eine Flutter-Anwendung und keine Browser-App.
Über <so> geladene Plugins erlauben die Integration von eigenen Protokollen, Geräte-Steuerung, Medienpipelines oder projektspezifischen Anwendungen in dieselbe Shell.
Die Routing-Schicht unterscheidet die wichtigsten Inhaltstypen direkt anhand der konfigurierten URL.
Diese Tabelle basiert auf den Schluesseln, die im aktuellen hex-browser-Sourcecode wirklich verdrahtet sind, nicht nur auf der Beispielkonfiguration. Sie deckt Startup-Keys, Tab-Parsing, Runtime-UI, WebEngine-Verhalten, Persistenz, VNC und Recovery-Schalter ab.
Source-Basis: gui/main.qml, gui/PanelView.qml, gui/Custom*View.qml, misc.cpp, StartupLogoResolver.cpp.
Diese Keys definieren, welche Tabs existieren und wie hex-browser jede konfigurierte Quelle auf Web-View, QML-View, natives Plugin oder RTSP-Player mappt.
Diese Keys formen die Kiosk-Shell selbst: Navigationsverhalten, visuelle Gestaltung, Tab-Icons und Bediener-Schaltflaechen.
Diese Keys justieren die virtuelle Tastatur, das Swipe-Modell und das Pointer-Verhalten fuer Touch-Geraete.
Diese Top-Level-Keys werden in jede erzeugte View geschrieben. Im aktuellen Sourcecode haben die meisten davon konkrete Wirkung auf Chromium-Web-Tabs; Plugin-, QML- und RTSP-Tabs spiegeln die gleiche Property-Oberflaeche vor allem der Konsistenz halber.
Diese Keys beeinflussen Persistenz, Screenshots, Backlight-Verhalten, Tab-Lifecycle und screensaverbezogene Timer.
Diese Keys werden frueh beziehungsweise beim Booten ausgewertet und beeinflussen Umgebungssetup, Rotation, Farbschema, Splash-Handling und Debugging.
Diese Keys steuern automatische Aktualisierung, Remote-Service-Zugriff und schwellenwertgesteuertes Recovery-Verhalten.
