WebGadget als Ersatz für native GUI

Für allgemeine Fragen zur Programmierung mit PureBasic.
Benutzeravatar
X0r
Beiträge: 2770
Registriert: 15.03.2007 21:47
Kontaktdaten:

WebGadget als Ersatz für native GUI

Beitrag von X0r »

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.
Benutzeravatar
RSBasic
Admin
Beiträge: 8022
Registriert: 05.10.2006 18:55
Wohnort: Gernsbach
Kontaktdaten:

Re: WebGadget als Ersatz für native GUI

Beitrag von RSBasic »

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.
Aus privaten Gründen habe ich leider nicht mehr so viel Zeit wie früher. Bitte habt Verständnis dafür.
Bild
Bild
Benutzeravatar
Kiffi
Beiträge: 10621
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: WebGadget als Ersatz für native GUI

Beitrag von Kiffi »

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
Hygge
Benutzeravatar
TroaX
Beiträge: 660
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: WebGadget als Ersatz für native GUI

Beitrag von TroaX »

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:

Code: Alles auswählen

<meta http-equiv='X-UA-Compatible' content='IE=edge'>
Damit du das nicht in jedes HTML einbinden musst, kannst du das auch über den Atomic über den HTTP-Header machen lassen:

Code: Alles auswählen

X-UA-Compatible: IE=edge
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.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
X0r
Beiträge: 2770
Registriert: 15.03.2007 21:47
Kontaktdaten:

Re: WebGadget als Ersatz für native GUI

Beitrag von X0r »

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.
Zuletzt geändert von X0r am 23.08.2017 15:39, insgesamt 1-mal geändert.
Benutzeravatar
RSBasic
Admin
Beiträge: 8022
Registriert: 05.10.2006 18:55
Wohnort: Gernsbach
Kontaktdaten:

Re: WebGadget als Ersatz für native GUI

Beitrag von RSBasic »

Du kannst im Thread PostEvent() nutzen, um anschließend aus dem Main-Code die Seite zu aktualisieren.
Aus privaten Gründen habe ich leider nicht mehr so viel Zeit wie früher. Bitte habt Verständnis dafür.
Bild
Bild
Benutzeravatar
X0r
Beiträge: 2770
Registriert: 15.03.2007 21:47
Kontaktdaten:

Re: WebGadget als Ersatz für native GUI

Beitrag von X0r »

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:

Code: Alles auswählen

SetGadgetText(#WebGadget,"javascript:MyFunction()")
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?
Benutzeravatar
Kiffi
Beiträge: 10621
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: WebGadget als Ersatz für native GUI

Beitrag von Kiffi »

versuch mal folgendes:

Code: Alles auswählen

SetGadgetText(#WebGadget,"javascript:void MyFunction()")
Grüße ... Peter
Hygge
Benutzeravatar
mk-soft
Beiträge: 3695
Registriert: 24.11.2004 13:12
Wohnort: Germany

Re: WebGadget als Ersatz für native GUI

Beitrag von mk-soft »

Weiss aber nicht wie das mit den Callback lösen möchtest.
'#PB_Web_NavigationCallback' gibt es nur bei Windows!
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Benutzeravatar
Shardik
Beiträge: 738
Registriert: 25.01.2005 12:19

Re: WebGadget als Ersatz für native GUI

Beitrag von Shardik »

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... :wink:
Antworten