PureBoard

Moin Leute,

ich arbeite gerade an einem Projekt, bei dem ich dem Benutzer ermöglichen will, die Oberfläche der Anwendung nach eigenem Ermessen zu verändern bzw. eigene Themes/Skins zu erstellen. Das ganze soll zudem cross-plattform-fähig sein. Hierzu gibt es jetzt natürlich mehrere Möglichkeiten. Zum Einen kann man sich mit den APIs von Windows/Linux/OSX auseinandersetzen und über die nativen Funktionen das Erscheinungsbild sämtlicher Controls veränderbar machen. Der Aufwand hierfür dürfte allerdings enorm sein.
Eine weitere Möglichkeit wäre die Entwicklung einer eigenen GUI-Bibliothek auf Basis des CanvasGadgets. Auch hier wäre der Aufwand entsprechend hoch.

Deshalb würde ich gerne die Nutzung des WebGadgets in Erwägung ziehen. Benutzerinterkationen mit dem WebGadget kann man ja ganz leicht über einen Callback evaluieren. Um hingegen selbst Events auszulösen, könnte man sich JavaScript bedienen und über URL-Aufrufe (javascript:FunctionXYZ("...")) Daten an das WebGadget übermitteln und die Anzeige aktualisieren. Ich habe dazu bereits einen Prototypen entwickelt und es scheint, als würde diese Idee ganz gut funktionieren. Ich habe allerdings noch keine Erfahrungswerte bzgl. Stabilität und Schnelligkeit!

Gibt es zu dieser Idee bereits andere Implementierungen/Versuche/Erfahrungswerte in PureBasic? Bislang habe ich lediglich Versuche gesehen, bei denen zum Aktualisieren der Anzeige der gesamte Inhalt des WebGadgets über SetGadgetItemText aktualisiert wird, was ich als sehr unhandlich betrachte.

Hallo X0r,

ist es unbedingt notwendig, eigene Themes/Skins für das Programm erstellen zu müssen/können?
Wäre es nicht besser, die Designeinstellung dem Betriebssystem zu überlassen? Ich bin der Meinung, die Anwendungen müssen einheitlich aussehen.
Dann wäre auch kein Problem, die nativen Controls plattformunabhängig zu benutzen.
Es gibt natürlich auch Ausnahmen wie z.B. bei Videobearbeitungsprogrammen. Was ist das für ein Projekt, an dem du gerade arbeitest?

Bezüglich WebGadget und CanvasGadget: Ich würde auf jeden Fall CanvasGadget bevorzugen:

1. Standardmäßig wird beim WebGadget eine alte IE-Version verwendet. Du müsstest unter Windows auf jeden Fall in die Registry schreiben, um die neuste IE-Version verwenden zu können. Sonst hast du deutlich mehr Probleme und Aufwand. (CSS-Hacks, JS-Workarounds) Außerdem müsstest du unter IE ggf. Darstellungsfehler beheben, die du in anderen Browsern nicht hast.
2. CanvasGadget ist schneller, als WebGadget.
3. Du hast beim CanvasGadget mehr Möglichkeiten bezüglich Events, Designs und ist einfacher zu realisieren. Du kannst beim CanvasGadget direkt zugreifen ohne Umwege über JS-Events und WebGadgetCallback o.ä.
4. Du müsstest beim WebGadget vieles korrigieren wie z.B. das Abschalten des Kontextmenüs, der Scrollleisten oder des Klick-Sounds, wenn du sowas nicht haben möchtest.
5. Beim WebGadget bist du immer abhängig von der jeweiligen Browser-Bibliothek. Wenn eine IE-Sicherheitslücke gibt, ist deine Anwendung auch davon betroffen. CanvasGadget ist was eigenes, nativ und plattformunabhängig.

Ist nur meine Meinung. Zum reinen Anzeigen von HTML-Seiten würde ich WebGadget nehmen, aber für eine eigene Benutzeroberfläche würde ich lieber CanvasGadget nutzen.

Hallo X0r,

PureBasic und WebGadget ist so eine Sache. Für die Darstellung einfacher Seiten mag das passen, aber wenn es in Richtung moderne Web-Technologien geht, fangen die Probleme an.

Auf Windows-Seite nutzt PB eine relativ alte Instanz des IE (ich glaube maximal Version 7, wenn vorhanden). Um die neuesten Web-Features nutzen zu können, musst Du dafür sorgen, dass die aktuellste IE-Version verwendet wird (wohlgemerkt: die aktuellste Version, die auf dem Kundenrechner vorhanden ist). Das geht nicht ohne Registry-Manipulation. Des weiteren musst Du, um mit dem WebGadget vernünftig kommunizieren zu können, OS spezifische Api-Aufrufe verwenden.

Meine Empfehlung geht daher eher in Richtung SpiderBasic & Electron (https://electron.atom.io/) oder JavaFX (https://de.wikipedia.org/wiki/JavaFX).

Grüße ... Peter

Ich habe mir diesbezüglich schon einige Gedanken gemacht und auch schon ein grobes Konzept erdachht, mit dem das theoretisch möglich sein sollte. Da ich aber aktuell in einem größerem PHP-Projekt festsitze und auch noch berufstätig bin, hatte ich keine Zeit für die Umsetzung.

1. Kommunikation zwischen Gadget und Anwendung:
Eine moderne Webanwendung kommt ohne Javascript kaum noch aus. Auch Projekte wie Electron setzen extrem stark auf Javascript im Frontend. Aber Electron verwendet da einen Trick, wie das Chromium-Control mit dem Node-Backend kommuniziert. HTTP sowie Websockets. Javascript bzw. das Gadget dient als HTTP bzw. Websocket-Client, während das Backend Server für diese Protokolle zur Verfügung stellt. Diese hören ausschließlich auf "localhost" und verwenden einen Post über 1024. Dadurch bekommt der Nutzer keinen Prompt von der Firewall, um Zugriffe im Netzwerk zuzulassen.

Um einen Webserver in Purebasic zu integrieren, kann man den Atomic-Webserver aus dem Examples-Ordner verwenden. Du musst diesen nur entsprechend erweitern. Mit diesem kannst du dann problemlos über Javascript (oder wenn du ein unfassendes Routing für den Atomic schreiben willst) ohne JS nur mit der Navigation und den HTTP-Methoden kommunizieren. Um Daten strukturiert zu tauschen, kann man JSON nehmen.

2. Internet-Explorer Version
http://forums.purebasic.com/german/view ... 82#p339382 (PS: Mein Beitrag danach habe ich geschrieben, während der verlinkte gepostet wurde )
Du kannst theoretisch auch ohne Regsitry die Nutzung der neuesten IE-Version forcieren. Das folgende im HTML-Code forciert die Nutzung der neuesten IE-Version, die auf dem System installiert ist: Damit du das nicht in jedes HTML einbinden musst, kannst du das auch über den Atomic über den HTTP-Header machen lassen: Denn Meta-Angaben mit dem Attribut http-equiv sind nichts weiter als benutzerdefinierte HTTP-Header, die der Server nicht mitsendet. Da du aber den Atomic verwenden würdest, kannst du den Versand des Headers selbst veranlassen. Ob das zuverlässig funktioniert, konnte ich noch nicht testen. Anderes Projekt und so.

3. Kontext-Menü etc.
Das Kontext-Menü lässt sich mit SetGadgetAttribute(#Gedget,#PB_Web_BlockPopupMenu,#true) unterdrücken. Klicksounds kommen nur bei Browser-Navigationen zu stande. Schreibt man das Frontend asynchron (Ajax/Websockets), dann wird man die so gut wie garnicht hören. Aber interessanterweise gibt es mit dem WebBrowser-Example Code auch keine Klickgeräusche. Zumindest nicht unter Windows.

Wie gesagt nutze ruhig zur Kommunikation einen eigenen internen Server. Das machen alle Frameworks wie Electron und Co. Der Discord-Client hat einen, Slack hat einen, der Atom-Editor, Bracket oder auch VS Code haben einen. Das ist mit Abstand die eleganteste Art, es zu regeln. Vor allem, da am Ende keine Grenzen mehr gesetzt sind.

Kleiner Tip: Du kannst auch deine Anwendung ohne HTML-Files ausliefern und so den Umstand etwas verschleiern, in dem du die HTML, CSS oder JS Files per IncludeBinary in die Anwendung packst und diese dann mit dem Atomic ans Gadget auslieferst. Und Spiderbasic ist so ebenfalls nutzbar.

Moin,

erstmal vielen Dank für eure Beiträge. Eine Möglichkeit zum Skinnen der Anwendung ist zwingend erforderlich; ich richte mich da nach allgemeiner Nachfrage bzw. Benutzeranforderungen. Die Nutzung einer älteren IE-Version ist auch nicht weiter schlimm, da keine allzu hohen Anforderungen an die Gestaltungsmöglichkeit der GUI gestellt werden.

Du kannst im Thread PostEvent() nutzen, um anschließend aus dem Main-Code die Seite zu aktualisieren.

Ist mir auch eben eingefallen; funktioniert soweit bestens!
Damit dürfte der Nutzung eines WebGadget eigentlich nichts mehr im Weg stehen.

Edit:
Neues Problem...

Und zwar aktualisiere ich die Anzeige des WebGadget über folgende Funktion: Das schöne hierbei ist, dass der Inhalt der Seite nicht neu geladen werden muss. Dennoch erhalte ich auf Windows XP (ja, dieses Betriebssystem möchte ich unterstützen...) das bekannte Click-Geräusch. Gibt es hierzu eine Lösung?

versuch mal folgendes:
Grüße ... Peter

Weiss aber nicht wie das mit den Callback lösen möchtest.
'#PB_Web_NavigationCallback' gibt es nur bei Windows!

mk-soft hat geschrieben:Weiss aber nicht wie das mit den Callback lösen möchtest.
'#PB_Web_NavigationCallback' gibt es nur bei Windows!

Einfach meine Workarounds für Linux und MacOS aus meinem Feature Request von 2013 benutzen...