WebGadget als Ersatz für native GUI

Für allgemeine Fragen zur Programmierung mit PureBasic.
Benutzeravatar
Mijikai
Beiträge: 754
Registriert: 25.09.2016 01:42

Re: WebGadget als Ersatz für native GUI

Beitrag von Mijikai »

Das ganze hört sich schon interessant an. :o
Mit Javascript kenn ich mich leider überhaupt nicht aus. :roll:
Wenn das ganze jedoch Funktioniert würde ich mich über Beispiele freuen.
Benutzeravatar
uweb
Beiträge: 461
Registriert: 13.07.2005 08:39

Re: WebGadget als Ersatz für native GUI

Beitrag von uweb »

Wenn das ganze jedoch Funktioniert würde ich mich über Beispiele freuen.
Troax hat ja schon eine praktikable Lösung angeboten.
Hat er?
PBExpresServer - Lightweight PureBasic Webserver & Framework?
Das kam bei mir gar nicht so an. Ich dachte er hätte einen Weg zum Selbermachen aufgezeigt.
... wobei da doch noch um einiges mehr dran hängt.
Aber dann ist der Weg zu SSL, WebDAV, ... vielleicht auch nicht mehr weit...
:D

Ich fürchte kurzfristig sollten wir nicht all zu fest damit rechnen.
Vielleicht wäre ein einfacher (nur auf den Zweck gerichteter) Konfigurator&Manager für NGINX / Apache (portable?) in Verbindung mit z.B. PBElectron auf Basis von PBExpress realistischer?
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 »

Mein Konzept-Name dafür war allerdings PureLectron (damit es nicht immer PB ist :lol: ).

NGINX, Hiawatha oder Apache mitzuliefern ist meiner Meinung nach schlicht vollkommen overpowered. Noch dazu würde so auch immer ein zweiter Prozess mitlaufen und wenn der abfliegt, dann kann es zu unschönen Seiteneffekten kommen. Außerdem müssten dann die Routinen per CGI/FastCGI eingebunden werden, was dann zu einem dritten Prozess führt. Der Overhead ist unnötig. Der Server soll ja nur als Kommunikationsschnittstelle zwischen WebGadget und den Purebasic-Prozeduren arbeiten. Da kann man dann lieber einen eigenen Webserver schreiben der das erledigt und im gleichen Prozess arbeitet. Das ist viel handlicher. Und ein Webserver gehört nun wirklich nicht zu den komplexesten Themen (siehe Atomic-Webserver Example). Das Teil hat sogar ein integriertes Directory-Mapping, wenn auch gleich der Headerparser Müll ist :lol:

So lange der Webserver nur auf localhost hört, kommt da von außen niemand ran. Die Kommunikation findet Systemintern statt. SSL/TLS, WebDAV und Co. sind einfach nicht nötig. Einen PBEmbedableExpressServer (Was für ein Name :lol: ) ist da schon eine gute Idee. Und ein weiterer Vorteil: Er kann über den zurückgemeldeten Header die Same-Origin Regel für HTTP-Request innerhalb Javascript um eine selbstdefinierte Domain erweitern, wodurch sich aus dem Javascript-Kontext heraus auf externe Webservices zugreifen lässt. Die ganze Welt der API's steht einem offen ... Ok jetzt werde ich rallig. Ich glaube ich lege das PHP-Projekt nochmal zur Seite :lol: :bounce:
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
uweb
Beiträge: 461
Registriert: 13.07.2005 08:39

Re: WebGadget als Ersatz für native GUI

Beitrag von uweb »

:allright:

Ja, WebDAV steht auf meiner persönlichen Wunschliste bei einer ganz anderen Baustelle - passt nicht ganz zum Thema.

SSL wäre aber nicht nur dafür sinnvoll. Damit könnte man z.B. sein PB-Programm (auf dem Homeserver) unterwegs mit dem Handy steuern - bzw könnten es alle Familienmitglieder tun (Multi-Client - Multi-User).

Es gab ja schon einige Ansätze zur Web-GUI und auch schon SSL (cryptlib - engl. Forum) aber die rundum-sorglos Lösung habe ich noch nicht entdeckt. Also freue ich mich auf Deine Lösung und würde mich natürlich auch über Beispiele freuen.
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 »

Web-GUI für den Desktop ist da aber auch ein bisschen was anderes. WebDAV steht für sich allein und benötigt kein Backend. Man bekommt für z.B. NGINX ein Plugin, um WebDAV zu realisieren. Wenn man SSL nutzen will, dann baut man sich die Webanwendung mit CGI/FastCGI und lässt sie ebenfalls über NGINX und Co. Laufen. Da ist eine PB interne Lösung das Interface für einen Vollwertigen Webserver. Und dies existiert mit CGI/FastCGI bereits. ;)
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
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 jetzt noch etliche Gedanken gemacht und die Frage gestellt, warum es überhaupt das Webgadget sein muss. Was spricht dagegen, einfach den Default-Browser zu verwenden? Ich habe mal das ganze getestet. Wenn ich jetzt mit z.B. FastCGI eine kleine API schreibe und beim starten des FastCGI-Prozesses z.B. RunProgram("http://localhost:12345/") verwende, wird der Browser gestartet und holt dann direkt ein auf Webtechnologien basiertes UI ab. Die API des (noch) FastCGI-Server kann dann zur Interaktion eines nativen Backends genutzt werden. Nebenbei prüft der Server mit ProgramRunning ab, ob die Browser-Instanz noch läuft. Wird der Browser bzw. Tab (je nach Browser) geschlossen, wird der Server ebenfalls beendet.

Noch dazu stehen einem jede Menge Funktionen aus dem Browser zur Verfügung (Druckdialog, Screenshot-Tools etc.). Vielleicht wäre das eine etwas angenehmere Möglichkeit. Denn ich glaube nicht, das wir in den nächsten X Jahren mal unter Windows Webkit als Webgadget haben :lol:
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
Kiffi
Beiträge: 10621
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: WebGadget als Ersatz für native GUI

Beitrag von Kiffi »

TroaX hat geschrieben:Was spricht dagegen, einfach den Default-Browser zu verwenden?
in meinem Fall brauchte ich eine Kommunikation mit der seriellen Schnittstelle. Das lässt sich mit einem per RunProgram() gestarteten Browser nicht bewerkstelligen. Deshalb musste ich auf Electron ausweichen.

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 »

Die Verbindung mit der seriellen Schnittstelle baust du auch mit dem Backend auf und nicht mit dem Frontend. Genau deswegen brauchst du ja auch Electron. Electron liefert das Backend in Form von Node.JS direkt mit und genug Packages, die mit der seriellen Schnittstelle arbeiten können, gibt es genug im NPM.

Da Frontend und Backend strikt getrennt sind, läuft es mit meinen Versuchen auch nicht anders. Ich implementiere die Prozedur für die serielle Schnittstelle in Purebasic, verbinde sie mit dem Router (aktuell PBExpress), spreche sie mit einem Request aus dem Frontend heraus auf die Route an und das native Backend aus Purebasic verarbeitet die Informationen und liefert sie als JSON zurück ans Frontend. Es spricht also absolut nichts dagegen. Man muss sich nur verinnerlichen, das man die Routinen, die mit Hardware und Betriebssystem kommunizieren in Purebasic schreiben muss, während für das UI HTML, CSS und JS verwendet wird ;)

Der einzige wirkliche Unterschied ist, das Electron fertig ist, ein Chromium-Gadget und die V8-Engine verwendet und dadurch teils Frontend und Backend direkt kommunizieren können. Dafür kann nachher die PB-Variante deutlich schneller arbeiten, wenn man es denn richtig implementiert.
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
Kiffi
Beiträge: 10621
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Re: WebGadget als Ersatz für native GUI

Beitrag von Kiffi »

TroaX hat geschrieben:Der einzige wirkliche Unterschied ist, das Electron fertig ist
das reicht mir als Argument <)

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 »

Kiffi hat geschrieben:
TroaX hat geschrieben:Der einzige wirkliche Unterschied ist, das Electron fertig ist
das reicht mir als Argument <)

Grüße ... Peter
Zumindest fürs erste ;) :lol:
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
Antworten