Programm für "moderne und ansehnliche" PC-GUI

Python + Qt (PyQt) geht relativ fix, aber ein bisschen Programmierarbeit 
ist das schon.

Was ist ein Desktop Widget? Diese Vista-mäßigen Applets auf dem Desktop, 
die 2 Jahre lang mal hip waren und die davor und danach nie wieder 
jemand gesehen hat?

Lazarus, auch wenn Pascal nicht jedermanns Sache ist.

Gtk wenn man in c Programmieren möchte

Mike schrieb:
> Ich arbeite gerade an einem Projekt, an dem ich vom PC aus über USB bzw.
> RS232 mit einem µC kommuniziere und unterschiedliche Werte auslese.
> Das ganze möchte ich am PC über eine "moderne und visuell ansprechende"
> Benutzeroberfläche tun.
> [...]
> Habt ihr Tipps für Programme, IDEs oder
> Software-Rapid-Prototyping-Tools,
> mit denen ich das machen könnte?

Du möchtest eine moderne, schicke GUI? Vergiß' den ollen Quark, bau' ein 
Webinterface, für lokale User dazu noch einen Minimalbrowser...

Mithilfe moderner Webtechniken und -Frameworks ist das jetzt auch keine 
Raketenwissenschaft. Und es hat massive Vorteile: Du hast die komplette 
Kontrolle über alles, von der Darstellung bis hin zum Backend. Du kannst 
mithilfe von Websockets eine Near-Realtime-Kommunikation bauen. Du 
kannst Deine Software entweder lokal installieren, oder mit wenigen 
Handgriffen netzwerkweit und zentral installiert deployen, und hast 
überall dasselbe Look'n'Feel, plattformunabhängig, ...

Und ich befinde mich in guter Gesellschaft: die PostgreSQL-Leute haben 
PgAdmin3 durch das PgAdmin4 abgelöst, das auf Python und Flask basiert, 
Microsoft bietet das webbasierte Office365 an, und sogar Qlik hat seine 
FatClient-Software auf eine webbasierte umgestellt. Warum? Weil es ganz 
unabhängig von Hard- und Software immer einen gemeinsamen Nenner gibt, 
nämlich einen Webbrowser. Und weil es abseits von Privatanwendern immer 
einfacher ist, Software zentral zu installieren und zu pflegen als auf 
einzelnen Clientrechnern. ;-)

Sheeva P. schrieb:
> Warum? Weil es ganz
> unabhängig von Hard- und Software immer einen gemeinsamen Nenner gibt,
> nämlich einen Webbrowser.

sagtest du "unabhängig von Software" und "einen" Webbrowser?

Mike schrieb:

> Habt ihr Tipps für Programme, IDEs oder
> Software-Rapid-Prototyping-Tools,
> mit denen ich das machen könnte?

Xcode? :-)

Sheeva P. schrieb:
> PgAdmin3 durch das PgAdmin4 abgelöst

ja und es ist jetzt total lahm und kacke :D

Udo K. schrieb:
> Wenn das unter Windows laufen soll, warum nicht .NET?

Wollte ich auch gerade sagen. War vor ein paar Jahren vor dem gleichen
Problem und habe mich dazumal für Visual C# unter Visual Studio 20xx 
Community Edition entschieden. Habs bis jetzt nicht bereut.
Ein grosser Vorteil war/ist meines Erachtens die riesige Fanbase. Du
findest praktisch zu jedem Teil/Problem Tutorials/Dokus und hunderte 
Code-Beispiele. Das hat mir sehr geholfen.

>Bedienbarkeit sollte ganz oben stehen, nicht "modern"

Ach... "Form folgt Funktion" ist doch sowas von 90´er

Stefan ⛄ F. schrieb:
> Sheeva P. schrieb:
>> Mithilfe moderner Webtechniken und -Frameworks ist das jetzt auch keine
>> Raketenwissenschaft.
>
> Man braucht dazu "nur"
>
> - Einen Web basierten Applikationsserver
> - Ein Applikations-Framework
> - Eine Programmiersprache auf dem Server (in meinem Umfeld ist das Java)

Python's Flask hat das alles schon eingebaut. Und, sorry, Java würde ich 
heutzutage nicht mehr für Websoftware benutzen. Einerseits wegen der 
neuen Lizenzen durch Oracle, die Fragen nach der Zukunftssicherheit 
aufwerfen. Aber andererseits kenne ich kaum eine Sprache, die so schwer 
ins Web zu bringen ist wie Java. Diese ganzen Application Server und die 
zugehörigen Standards sind ja auf dem Papier eine ganz nette Idee. Aber 
in der Praxis gibt es keinen nicht-kommerziellen Java Web Application 
Server mehr, der den einschlägigen Standards genügt und den man im 
freien Netz einsetzen will. Und was die Standards angeht, ist es ja 
toll, daß es sie gibt, aber wenn jeder Vendor sie anders versteht und 
umsetzt, relativiert sich die Praxistauglichkeit eines Standards leider 
sehr schnell.

Naja, ich hoffe ja weiterhin auf Thorntail... ;-)

> - Kenntnisse in HTML
> - Kenntnisse in CSS
> - Kenntnisse in Javascript
> - Kenntnisse in der DOM Struktur des Browsers
> - Meist ein Framework für die Programmierung des Browsers

Für ein einfaches Webfrontend mit ein paar Meßdaten muß man das 
sicherlich nicht alles bis ins letzte Detail wissen, und für das meiste 
gibts bereits fertige Frameworks -- zum Plotten von Grafen etwa Flot 
oder jqPlot.

> - Kenntnisse über HTTP
> - Kenntnisse über HTTPS
> - Kenntnisse über Security Themen im Netzwerk

Für eine lokale Installation?

> Wie lange soll er denn lernen, bis seine erste Anwendung fertig ist?

Ich weiß nicht viel über die Vorkenntnisse des TO, womöglich kann er ein 
paar der genannten Dinge ja schon. Und ansonsten, naja... klar wäre es 
prima, sich das alles detailliert zu erschließen, aber für eine 
einfache, kleine, lokal laufende Webanwendung muß man das wohl nicht. 
Abgesehen davon ist die Aneignung speziell dieses Wissens vermutlich 
eine viel lohnendere Investition, als sich jetzt etwas herauszusuchen, 
es zu lernen -- Qt und C++ (oder auch Pascal/Lazarus/...) sind ebenfalls 
kein kleiner Schritt, nur: damit kann man dann eben vornehmlich 
FatClients schreiben. Mit dem, was ich vorgeschlage, kann man aber 
sowohl webbasierte Pseudofatclients entwickeln, sondern eben auch 
richtige Webapplikationen, mithin: mein Lösungsansatz ist diesbezüglich 
flexibler und vielseitiger, so daß sich eine Investition in diese 
Kenntnisse womöglich eher lohnt.

Letzten Endes ist die Frage ja nicht, Webstandards lernen versus nichts 
lernen, sondern Webstandards lernen versus ein ausgewachsenes 
GUI-Framework wie Qt, GTK, wxWidgets oder <whatever>. Und da sieht die 
Sache mit den Webstandards auf einmal gar nicht mehr so abschreckend 
aus, methinks -- YMMV.

Walter S. schrieb:
> Sheeva P. schrieb:
>> Warum? Weil es ganz
>> unabhängig von Hard- und Software immer einen gemeinsamen Nenner gibt,
>> nämlich einen Webbrowser.
>
> sagtest du "unabhängig von Software" und "einen" Webbrowser?

Ja, Walter, das sagte ich. Für eine Webapplikation ist es nämlich 
ziemlich egal, ob sie auf einem Mozilla Firefox, Google Chrome, Apple 
Safari oder Microsoft Edge dargestellt wird -- oder auf welchem 
Betriebssystem dieser Brauser läuft, oder ob er auf einem PC, Laptop, 
Netbook oder Tablet. Oder Mibiltelefon oder SBC oder... you get the 
idea.

Sven B. schrieb:
> Sheeva P. schrieb:
>> PgAdmin3 durch das PgAdmin4 abgelöst
>
> ja und es ist jetzt total lahm und kacke :D

Also bei mir sehe ich keinen großen Unterschied, nicht einmal auf meinem 
nun wirklich uralten Q9650.

Sheeva P. schrieb:
>> Sheeva P. schrieb:
>>> PgAdmin3 durch das PgAdmin4 abgelöst
>>
>> ja und es ist jetzt total lahm und kacke :D
>
> Also bei mir sehe ich keinen großen Unterschied, nicht einmal auf meinem
> nun wirklich uralten Q9650.

Ok, fairerweise war auch die alte Variante schon ziemlich lahm und 
kacke. :/

Ist ein bisschen her dass ich das benutzt habe, aber die Performance und 
Bequemlichkeit um so eine Tabelle anzuschauen erinnerte mich ziemlich an 
PhpMyAdmin von 2004. Selbst der olle sqlitebrowser ist da jedenfalls 
eine ganz andere Kategorie ...

Bin heute zufällig auf imgui gestoßen, einem C++ GUI mit relativ wenig 
Abhängigkeiten:
https://github.com/ocornut/imgui

Das dürfte vor allem unter Grafik/Game Entwicklern als schneller 
Tooling-Prototype sehr beliebt sein. Die Liste an Sponsoren liest sich 
auch wie ein who's who der Spielebranche.

Die Mischung modern-retro der Demo find ich extrem sexy.

Hier wird Tcl/Tk für Oberflächen (und mehr) verwendet.

Wer Tcl nicht mag: Tk gibt es auch für Python

Viel schneller kann man nicht zu einem guten Ergebnis kommen - auch ohne 
große Vorkenntnisse.

Dazu ist das Ganze sehr ressourcensparend.

Stefan ⛄ F. schrieb:
> Weil die Standards (du meinst Java EE) inzwischen maßlos aufgebläht
> sind. Man muss nicht alles benutzen, was Sun/Oracle sich ausgedacht hat.

Wenn man seine Software im Enterprise-Umfeld verhökern will, ... denn:

> Java EE ist zweifellos ätzend. Aber es ist im Enterprise Umfeld sehr
> gefragt.

;-) Naja, klar, eine Frage der Zielgruppe...

> Wenn du das drauf hast, hast du langfristig keine Sorgen um deinen Job.

Hab' ich eh nicht.

> Genau. Beides wird gebraucht, wobei nach meiner Beobachtung die
> Entscheidung oft fürs Web fällt, wenn beides geeignet ist. Aber das ist
> halt auch komplizierter.

Das sehe ich, ehrlich gesagt, nicht ganz so schlimm. Ja, Web hat ein 
paar mehr Technologien (HTTP(S), HTML, CSS, JS, SVG...), aber die 
meisten sind IMHO relativ einfach, verglichen mit einer 
Programmiersprache -- wobei ich Java- bzw. ECMAScript primär als DSL 
fürs interaktive Web sehe. Und es gibt für alles kostenlose 
Lernressourcen, Libraries und Frameworks, das ist bei klassischen 
Sprachen ja bedauerlicherweise nicht immer so...

Wenn man dann bei diesem Web-Gedönse mit einer modernen Skriptsprache 
wie Python, Ruby oder Perl arbeitet, hat man sofort eine umfangreiche 
und produktionstaugliche Infrastruktur, anstatt sich für jeden Mist eine 
eigene Library suchen (und womöglich auch noch kaufen) zu müssen. Meine 
Erfahrung sowohl mit C++, als auch mit Java ist: da verplempert man die 
beim Lernen eingesparte Zeit dann für die Suche nach Libraries, und ich 
da ja so meine Zweifel, ob das am Ende tatsächlich produktiver ist und 
ähnlich viel Spaß macht... (Wobei, nunja: wer eine Aversion gegen das 
Lernen pflegt, sollte vermutlich ohnehin besser nicht gerade 
Softwareentwickler werden...)

Und, nicht vergessen: GUI-Frameworks haben auch ihre Komplexität, und 
zum Beispiel im Falle von Qt eine, die deutlich übers reine GUI-Building 
hinaus geht. Qt verkapselt ja so ziemlich alles in eigene Klassen, auch 
Netzwerk, Datenbanken und so weiter etc., so daß auch erfahrene 
C++-Entwickler hier vieles neu lernen oder ständig hin- und 
herkonvertieren müssen.

Als ganz netten Ansatz empfinde ich übrigens noch das Webtoolkit [1], 
das Webapplikationen mit den Konstrukten üblicher C++-GUI-Frameworks 
möglich machen soll. Hab' aber bisher leider noch nicht die Zeit 
gefunden, mir das intensiver anzuschauen -- und abseits meines 
technischen Interesses bislang auch keine Notwendigkeit. Python und 
Flask sind ja prima für sowas, auch für GUIs, und wenn ich mir damit 
wirklich mal Gedanken über Performance machen muß, ist das ja entweder 
leicht skalierbar oder mit Boost.Python schnell durch eine 
C++-Implementierung der performancekritischen Bereiche schnell und 
einfach erledigt. Dennoch, den Ansatz von Webtoolkit find ich 
ausgesprochen interessant.

[1] https://www.webtoolkit.eu/wt

Sven B. schrieb:
> Sheeva P. schrieb:
>>>> PgAdmin3 durch das PgAdmin4 abgelöst
>
> Ok, fairerweise war auch die alte Variante schon ziemlich lahm und
> kacke. :/
>
> Ist ein bisschen her dass ich das benutzt habe, aber die Performance und
> Bequemlichkeit um so eine Tabelle anzuschauen

Naja, eigentlich ist das ja auch ein Werkzeug für die Administration der 
Datenbank, und kein Frontend für deren Inhalte, und das galt auch schon 
für PgAdmin3... wobei auch ich finde, daß man da durchaus auch einen 
besseren Viewer hätte einbauen dürfen. "\(".)/"

Sheeva P. schrieb:
> Für eine Webapplikation ist es nämlich
> ziemlich egal, ob sie auf einem Mozilla Firefox, Google Chrome, Apple
> Safari oder Microsoft Edge dargestellt wird -- oder auf welchem
> Betriebssystem dieser Brauser läuft

Und während ein kleines Prog in Qt oder GDK selbst auf dem Raspi nur 
0.1% Rechnerleistung frisst und sich mit ein paar 100kB zufriedengibt - 
muss da ne WebApp mit Server und Browser laufen, wo schon allein der 
Firefox-Tab 1GB Speicher braucht und regelmäßig einen Prozessorkern 
auslastet. Aber macht ja nix, wenn der Rechner zu lahm ist muss er halt 
nen neuen kaufen.

MaWin schrieb:
> Mike schrieb:
>> moderne und visuell ansprechende
>
> Ich möchte lieber eine funktionale und bedienbare Oberfläche.

Kann man denn nur eines von den beiden haben?

> Und dazu gehört, daß Buttons sich von Labels unterscheiden und nicht
> einfach bloss Text in Rechtecken sind (also bloss kein Win10 Style,
> brüher hatten Buttons wegnisgtens eine 3d Effelt, noch früher aufwändige
> runde Ecken),

Microsoft war noch nie wirklich Vorreiter für vernünftiges GUI-Design. 
Es gab regelmäßig krasse Änderungen im Look&Feel, die aber alle nie so 
richtig überzeugen konnten.

Sheeva P. schrieb:
>> sagtest du "unabhängig von Software" und "einen" Webbrowser?
>
> Ja, Walter, das sagte ich. Für eine Webapplikation ist es nämlich
> ziemlich egal, ob sie auf einem Mozilla Firefox, Google Chrome, Apple
> Safari oder Microsoft Edge dargestellt wird -- oder auf welchem
> Betriebssystem dieser Brauser läuft, oder ob er auf einem PC, Laptop,
> Netbook oder Tablet. Oder Mibiltelefon

Unter dem Stichwort "Browserweiche" findet man:
"Browserweichen sind Techniken, um Unterschiede in der Darstellung von 
Webseiten in verschiedenen Webbrowsern zu umgehen, indem für 
unterschiedliche Browser unterschiedlicher Code angeboten wird."

und man kann vielleicht jede Seite auf einem Mobiltelefon anzeigen, aber 
man mag sie nicht unbedingt lesen oder bedienen

Mein Kollege hat so eine Anwendung (Datenbankoberfläche) am MAC 
programmiert:
zuerst brauchte es einige Durchläufe bis es auf Linux auch ging, 
(windows geht immer noch nicht richtig) und als Browser ist zwingend 
Firefox vorgeschrieben.
Bei neuen Versionen von Firefox waren auch schon Nachbesserungen 
notwendig.
Also ganz so easy ist es doch nicht.

Karl K. schrieb:
> Sheeva P. schrieb:
>> Für eine Webapplikation ist es nämlich
>> ziemlich egal, ob sie auf einem Mozilla Firefox, Google Chrome, Apple
>> Safari oder Microsoft Edge dargestellt wird -- oder auf welchem
>> Betriebssystem dieser Brauser läuft
>
> Und während ein kleines Prog in Qt oder GDK selbst auf dem Raspi nur
> 0.1% Rechnerleistung frisst und sich mit ein paar 100kB zufriedengibt

Klar, wenn man die Shared Objects nicht mitrechnet...

> muss da ne WebApp mit Server und Browser laufen, wo schon allein der
> Firefox-Tab 1GB Speicher braucht und regelmäßig einen Prozessorkern
> auslastet.

Ob man nun einen dicken Firefox benutzt oder etwas Schlankeres benutzt 
-- etwa ein kleines GTK-, Qt- oder wxWidgets-Programm mit 
Browserkomponente, wie es die PgAdmin4-Entwickler für lokale Nutzer 
machen, ist ja am Ende einem selbst überlassen. Und, schau mal, kleine 
und leichtgewichtige Webbrowser existieren -- sogar so viele, daß die 
englische Wikipedia eine eingene Kategorie dafür hat: [1]. Such' Dir 
halt einen aus, dann geht's auch mit dem Raspberry Pi.

[1] https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_browsers

> Aber macht ja nix, wenn der Rechner zu lahm ist muss er halt
> nen neuen kaufen.

Mit einer Webapplikation kann man die beiden Dinge -- die Datenhaltung 
und -Aufbereitung und die Darstellung andererseits sogar wunderbar 
entkoppeln, weißt Du. Und wenn Dein Computer es nicht schafft, die Daten 
gleichzeitig vorzuhalten, zu selektieren, aufzubereiten und 
darzustellen, dann kommt er auch mit Qt- oder GTK-Lösungen mächtig ins 
Schwitzen... die teuren Sachen müssen die GUI-Frameworks nämlich auch 
alle machen, natürlich.

Insofern danke ich Dir herzlich für Deinen Beitrag, wenngleich er den TO 
keinen Mikrometer weiterbringt und ich darin leider etwas wie wenigstens 
halbwegs seriöse Argumente vermisse. ;-)

Walter S. schrieb:
> Sheeva P. schrieb:
>>> sagtest du "unabhängig von Software" und "einen" Webbrowser?
>>
>> Ja, Walter, das sagte ich. Für eine Webapplikation ist es nämlich
>> ziemlich egal, ob sie auf einem Mozilla Firefox, Google Chrome, Apple
>> Safari oder Microsoft Edge dargestellt wird -- oder auf welchem
>> Betriebssystem dieser Brauser läuft, oder ob er auf einem PC, Laptop,
>> Netbook oder Tablet. Oder Mibiltelefon
>
> Unter dem Stichwort "Browserweiche" findet man:

Unter dem Begriff "Peitschenmacher" findet man einen alten Beruf, der 
heutzutage weitestgehend ausgestorben ist, weil kein Bedarf mehr dafür 
besteht. Ganz ähnlich verhält es sich auch mit Browserweichen.

> und man kann vielleicht jede Seite auf einem Mobiltelefon anzeigen, aber
> man mag sie nicht unbedingt lesen oder bedienen

Auch dafür gibt es Lösungen -- jedenfalls, solange die Datenmengen nicht 
allzu riesig sind.

> Mein Kollege hat so eine Anwendung (Datenbankoberfläche) am MAC
> programmiert:
> zuerst brauchte es einige Durchläufe bis es auf Linux auch ging,
> (windows geht immer noch nicht richtig) und als Browser ist zwingend
> Firefox vorgeschrieben.
> Bei neuen Versionen von Firefox waren auch schon Nachbesserungen
> notwendig.

Seltsam: auf dem MAC-Firefox läuft es, aber auf dem Linux- und dem 
Windows-Firefox nicht? Was macht Dein Kollege denn da für komische 
Sachen?

> Also ganz so easy ist es doch nicht.

Das hat ja auch niemand behauptet, aber eine Anwendung mit einem 
modernen GUI-Framework zu entwickeln -- und zwar so, daß sie auf 
verschiedenen Plattformen und über verschiedene Versionen des Framework 
hinweg korrekt funktioniert -- ist auch alles andere als easy. Das liegt 
im Wesentlichen daran, daß Anwendungsentwicklung nun einmal per se nicht 
easy ist, weißt Du. Man kann dabei eine Menge falsch machen, auch bei 
Webapplikationen, aber dann ist das Problem trotzdem nicht die 
Technologie, sondern immer noch das klassische PEBKAC.

Sheeva P. schrieb:
> Karl K. schrieb:
>> Sheeva P. schrieb:
>>> Für eine Webapplikation ist es nämlich
>>> ziemlich egal, ob sie auf einem Mozilla Firefox, Google Chrome, Apple
>>> Safari oder Microsoft Edge dargestellt wird -- oder auf welchem
>>> Betriebssystem dieser Brauser läuft
>>
>> Und während ein kleines Prog in Qt oder GDK selbst auf dem Raspi nur
>> 0.1% Rechnerleistung frisst und sich mit ein paar 100kB zufriedengibt
>
> Klar, wenn man die Shared Objects nicht mitrechnet...

Wenn man die mitrechnet stimmt der Vergleich immer noch. 
Qt5Core+Widgets+Gui ist ein Bruchteil von so einer Browser-Engine. Und 
das Client-Framework fängt dann erst an.

> -- etwa ein kleines GTK-, Qt- oder wxWidgets-Programm mit
> Browserkomponente, wie es die PgAdmin4-Entwickler für lokale Nutzer
> machen,

Aha, machen die das? Welche Browserkomponente soll das sein? Bei mir 
geht das im Firefox auf.

> ist ja am Ende einem selbst überlassen. Und, schau mal, kleine
> und leichtgewichtige Webbrowser existieren -- sogar so viele, daß die
> englische Wikipedia eine eingene Kategorie dafür hat

Ja, nur funktioniert keiner davon auch nur so grob, der nicht eine der 
2-3 großen Engines benutzt und ein paar Buttons draufklebt. Oder kannst 
du mir einen aus der Liste zeigen, der eine schlanke Engine hat und 
zumindest so ein paar aktuelle Webseiten halbwegs fehlerfrei anzeigen 
kann? -> kannst du alles vergessen. Es gibt im Moment nur die paar 
Riesen-Engines, die irgendwie brauchbar sind.

> Mit einer Webapplikation kann man die beiden Dinge -- die Datenhaltung
> und -Aufbereitung und die Darstellung andererseits sogar wunderbar
> entkoppeln, weißt Du.

Man kann mit allem gute Anwendungen schreiben. So richtig ideal ist aber 
das HTML/JS-Zeug definitiv nicht, um z.B. Tabellen mit einigen Millionen 
Zeilen anzuzeigen und zu durchsuchen. Mit QtWidgets geht das relativ gut 
ohne sich groß zu verbiegen.

Rolf M. schrieb:
> Microsoft war noch nie wirklich Vorreiter für vernünftiges GUI-Design.

Was wäre denn ein Beispiel für "vernünftiges" Design?

Die grundlegenden Elemente hatte schon meine Amiga Workbench. Und die 
schwerwiegendste Änderung bei Windows war, den Schließen Button von 3.11 
auf 95 oben rechts hinzupflanzen.

Bei Win 10 nervt halt, dass die GUI Elemente sich kaum noch abheben.

Sheeva P. schrieb:
> Und, schau mal, kleine
> und leichtgewichtige Webbrowser existieren

Ja klar, und auf denen läuft dann das JS nicht oder er kann keine PNGs 
darstellen oder was weiß ich.

Komm hör auf, hab ich alles durch.

Sheeva P. schrieb:
> Mit einer Webapplikation kann man die beiden Dinge -- die Datenhaltung
> und -Aufbereitung und die Darstellung andererseits sogar wunderbar
> entkoppeln, weißt Du.

Ja klar, so wie die GUI von node RED - läuft wunderbar im Browser auf 
dem PC, aber ach auf dem Tablet brauchts dann 20sec um einen Tab 
umzuschalten und auf dem Raspi schmiert es komplett ab.

Was die Entwickler dieser tollen Lösungen regelmäßig übersehen: Nicht 
jeder hat wie sie den schnellsten, neuesten und mit Unmengen RAM 
ausgestatteten Rechner dastehen.

Sheeva P. schrieb:
> Das hat ja auch niemand behauptet, aber eine Anwendung mit einem
> modernen GUI-Framework zu entwickeln -- und zwar so, daß sie auf
> verschiedenen Plattformen und über verschiedene Versionen des Framework
> hinweg korrekt funktioniert

Vielleicht bist Du auch einfach zu abgehoben unterwegs.

Ich schreib einen Uart-Datalogger in Lazarus / Freepascal mit grafischer 
Oberfläche, kompiliere den für Windows, Linux und Arm Linux und ohne 
auch nur eine verschissene Codezeile zu ändern läuft der problemlos auf 
Win-PC, Linux-PC und Raspberry. Den Switch zwischen WinApi und GTK macht 
der Compiler.

Gut, GTK sieht halt immer aus wie letztes Jahrhundert, aber das ist halt 
GTK.

Stefan ⛄ F. schrieb:
> Sehbehinderte stellen unter Linux oder Android gerne mal sehr große
> Schrift ein (Windows kann das gar nicht). Auch damit versagen viele
> Anwendungen.

Ich weiß ja nicht, was bei Dir sehr große Schrift ist, aber hier kann 
Win7 bis 500% skalieren.

Dass das nicht alle Anwendungen können - liegt halt daran dass die 
Programmierer nicht wissen was High DPI awareness ist. Kann Windows seit 
Vista.

Muss man sich halt auch angewöhnen GUI Elemente nicht fix per 
x-y-Position zu setzen, sondern flexibel mit Ankern. Hilft auch ungemein 
bei der Übertragung auf andere OS mit anderem Widgetset.

Udo K. schrieb:
> Sheeva P. schrieb:
>> [1] https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_browsers
>
> Die Tabelle ist ein schlechter Witz, für die meisten Browser dort
> gibt es seit Jahren kein Update!

Ich zähle sechs, deren letztes Update vor weniger als einem Jahr war.

Sheeva P. schrieb:
> Udo K. schrieb:
>> Sheeva P. schrieb:
>>> [1] https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_browsers
>>
>> Die Tabelle ist ein schlechter Witz, für die meisten Browser dort
>> gibt es seit Jahren kein Update!
>
> Ich zähle sechs, deren letztes Update vor weniger als einem Jahr war.

Die Tabelle ist ein Witz, Sheeva. Sag mir einen auch nur ansatzweise 
brauchbaren Browser darin, der nicht auf der WebKit- oder Gecko-Engine 
basiert. Dillo ist von 2015, die Links-Engine ist ein 
nach-ASCII-Spaß-Renderer, NetSurf hab ich mir mal angeschaut und das 
rendert ungefähr wie der IE6, w3m ist auch eine ASCII-Spaß-Engine und 
sonst gibts da nix.

Also mach dich nicht zum Depp und versuche anhand dessen die total 
sinnfreie These zu vertreten, es gäbe brauchbare "schlanke" 
Browser-Engines.

Bzw. kann sein dass es die gibt, aber ich kenne keine und in der Tabelle 
steht definitiv auch keine.

Nur so mal als Referenz, auf welchem Niveau sich die 
nicht-Webkit/Gecko-Engines bewegen.

Sven B. schrieb:
> Sheeva P. schrieb:
>> Karl K. schrieb:
>>> Und während ein kleines Prog in Qt oder GDK selbst auf dem Raspi nur
>>> 0.1% Rechnerleistung frisst und sich mit ein paar 100kB zufriedengibt
>>
>> Klar, wenn man die Shared Objects nicht mitrechnet...
>
> Wenn man die mitrechnet stimmt der Vergleich immer noch.
> Qt5Core+Widgets+Gui ist ein Bruchteil von so einer Browser-Engine.

Bitte komm' mal auf den Boden der Tatsachen, ja? Erfreulicherweise hat 
sich schon jemand die Mühe gemacht, entsprechende Messungen angestellt, 
und sie dokumentiert, seine Ergebnisse findest Du hier: [1]. Dabei 
QtWebKit und QtWebEngine mit Freya gemessen, einem Werkzeug aus der 
Valgrind-Suite, jeweils nach dem Laden ausgewählter Webseiten.

Die Ergebnisse sind relativ eindeutig, finde ich: ja, natürlich ist Qt 
alleine wesentlich kleiner als eine Webengine (die ja auch erheblich 
mehr kann), aber mit den behaupteten "ein paar 100 kB" ist es eben auch 
nicht getan. Im Maximalfall haben die Browser etwa 200, im Minimalfall 
dagegen nur knapp 30 MB RAM belegt; es kommt also offensichtlich auch 
sehr darauf an, welche Engine man benutzt und welche Seite(n) man 
besucht. (Wobei es hier aber nichtmal um einen richtigen Webbrowser im 
Internet geht, sondern zunächst mal nur um eine Minimalimplementierung 
für ein paar Plots...)

[1] https://trello.com/c/IU71cz0b/241-memory-measurement

>> -- etwa ein kleines GTK-, Qt- oder wxWidgets-Programm mit
>> Browserkomponente, wie es die PgAdmin4-Entwickler für lokale Nutzer
>> machen,
>
> Aha, machen die das? Welche Browserkomponente soll das sein? Bei mir
> geht das im Firefox auf.

Ja, machen sie. Sagt jedenfalls Dave Page [1], einer der Core-Entwickler 
von PostgreSQL. Und ich selbst bin dem Ding auch schon begegnet, als ich 
PgAdmin4 in einen Docker-Container eingebaut habe.

[1] 
https://pgsnake.blogspot.com/2016/04/pgadmin-4-elephant-nears-finish-line.html

>> ist ja am Ende einem selbst überlassen. Und, schau mal, kleine
>> und leichtgewichtige Webbrowser existieren -- sogar so viele, daß die
>> englische Wikipedia eine eingene Kategorie dafür hat
>
> Ja, nur funktioniert keiner davon auch nur so grob, der nicht eine der
> 2-3 großen Engines benutzt

Wenn Du genauer in die Tabelle schaust, wirst Du sehen, daß die meisten 
dieser Browser tatsächlich eine der "großen" Webengines benutzen: Gecko 
(Firefox), WebKit (Safari), oder WebEngine (Chromium).

>> Mit einer Webapplikation kann man die beiden Dinge -- die Datenhaltung
>> und -Aufbereitung und die Darstellung andererseits sogar wunderbar
>> entkoppeln, weißt Du.
>
> Man kann mit allem gute Anwendungen schreiben. So richtig ideal ist aber
> das HTML/JS-Zeug definitiv nicht, um z.B. Tabellen mit einigen Millionen
> Zeilen anzuzeigen und zu durchsuchen. Mit QtWidgets geht das relativ gut
> ohne sich groß zu verbiegen.

Bitte probier' das mal, BTDT. Mit sowas haben sogar darauf 
spezialisierte Werkeuge wie LibreOffice, Gnumeric etc. erhebliche 
Probleme. Vermutlich ist das der Grund dafür, daß viele professionelle 
Werkzeuge aus diesem Bereich ihre Daten lieber on-demand laden, also 
dann, wenn der Benutzer in den betreffenden Bereich scrollt. Das kann 
man aber auch mit einer Webapp oder mit einem GUI-Framework, da sind die 
Unterschiede dann nicht so groß. Und wer solche Datenmengen darstellen 
will, sollte das lieber nicht auf einem Raspberry Pi oder Odroid Xu4 
probieren... ;-)

Insofern, bitte, was soll denn diese verbissene Diskussion? Tatsache 
ist, daß sogar umfangreiche Applikationen wie Office 365 als 
Webapplikationen implementiert sind, und daß Webapplikationen in 
verschiedenen Punkten wie Plattform- und Geräteunabhängigkeit, zentraler 
Wartung und Pflege, und am Ende auch bei der Verteilung von Rechen- und 
Renderinglast viele Vorteile haben. Daß man sie sauber implementieren 
muß, geschenkt, denn das muß man mit GUI-Applikationen schließlich 
genauso.

MaWin schrieb:
> Sheeva P. schrieb:
>> Unter dem Begriff "Peitschenmacher" findet man einen alten Beruf, der
>> heutzutage weitestgehend ausgestorben ist, weil kein Bedarf mehr dafür
>> besteht. Ganz ähnlich verhält es sich auch mit Browserweichen
>
> Du meinst, deine Seite lässt sich auf dem bei dir installierten Chrome
> mit deinen Browsereinstellungen darstellen, und das reicht ?

Nein. Unsere Hauptapplikationen werden jede Nacht installiert, 
gestartet, und dann werden sie mithilfe von Jenkins, Zalenium, Selenium 
und AutoIt sehr umfangreichen Tests unterzogen, das dauert jede Nacht 
etwa acht bis zehn Stunden. Meine internen Webapplikationen werden 
täglich von etwa 80 Kollegen in unserem Geschäftsbereich und etwa 400 
weiteren Kollegen aus anderen Geschäftsbereichen genutzt, dabei gibt es 
keinerlei Vorgaben in Bezug auf Betriebssystem oder Webbrowser, dabei 
werden von Firefox über Chrome und Chromium bis hin zu Safari und Edge 
unter den verschiedensten Versionen und Varianten von Windows, Linux, 
und MacOS/X benutzt.

Es kommt natürlich vor, daß meine Anwendungen mal einen Fehler haben und 
nicht so funktionieren, wie die Kollegen das wünschen. Aber daß ich 
dabei in eine Browserinkompatibilität gelaufen wäre, ist schon sehr, 
sehr, sehr  lange her -- so lange, daß ich mich nichtmal mehr erinnern 
kann.

Dein übriges Getrolle ist natürlich keiner Antwort wert.

Karl K. schrieb:
> Sheeva P. schrieb:
>> Und, schau mal, kleine
>> und leichtgewichtige Webbrowser existieren
>
> Ja klar, und auf denen läuft dann das JS nicht oder er kann keine PNGs
> darstellen oder was weiß ich.

Also Du weißt es nicht. Worüber genau wollest Du denn jetzt diskutieren? 
Über Dein Nichtwissen? Ach so.

Schau, Karl, Du magst mich nicht. Ist ja auch ok, damit kann ich 
wunderbar leben und ich hoffe, Du auch. Aber wenn Du keine Ahnung von 
etwas hast, von denen ich etwas verstehe... warum nagelst Du mir dann 
eine "Diskussion" ans Knie? Warte doch einfach ab, bis ich wiedermal 
über etwas schreibe, bei dem Du wenigstens den Hauch einer Ahnung und 
damit eine Diskussionsgrundlage hast. Mir nur zu widersprechen, weil Du 
mich nicht magst und mir deswegen unbedingt widersprechen möchtest, das 
ist doch ziemlich fruchtlos und auch intellektuell ein bisschen 
unterirdisch, findest Du nicht?

Sheeva P. schrieb:
> Sven B. schrieb:
>> Sheeva P. schrieb:
>>> Karl K. schrieb:
>> Wenn man die mitrechnet stimmt der Vergleich immer noch.
>> Qt5Core+Widgets+Gui ist ein Bruchteil von so einer Browser-Engine.
>
> Bitte komm' mal auf den Boden der Tatsachen, ja?
> ...
> Die Ergebnisse sind relativ eindeutig, finde ich: ja, natürlich ist Qt
> alleine wesentlich kleiner als eine Webengine (die ja auch erheblich
> mehr kann)

Dann bin ich denke ich auf dem Boden der Tatsachen, nichts anderes habe 
ich gesagt: QtWidgets hat einen Bruchteil der Komplexität und Größe von 
so einer Web-Engine. Das äußert sich z.B. auch in der Anzahl der 
Code-Zeilen, die es hat.

> aber mit den behaupteten "ein paar 100 kB" ist es eben auch
> nicht getan.

Habe ich nie behauptet.

> [1] https://trello.com/c/IU71cz0b/241-memory-measurement
>
>>> -- etwa ein kleines GTK-, Qt- oder wxWidgets-Programm mit
>>> Browserkomponente, wie es die PgAdmin4-Entwickler für lokale Nutzer
>>> machen,
>>
>> Aha, machen die das? Welche Browserkomponente soll das sein? Bei mir
>> geht das im Firefox auf.
>
> Ja, machen sie. Sagt jedenfalls Dave Page [1], einer der Core-Entwickler
> von PostgreSQL. Und ich selbst bin dem Ding auch schon begegnet, als ich
> PgAdmin4 in einen Docker-Container eingebaut habe.

Ich kriege es hier nicht dazu das zu tun, --help gibt es nicht und gegen 
irgendwas in der Richtung gelinkt ist es auch nicht. Ich wäre aber sehr 
überrascht, wenn es nicht einfach QtWebEngine laden würde. Was soll es 
denn sonst tun?


>> Ja, nur funktioniert keiner davon auch nur so grob, der nicht eine der
>> 2-3 großen Engines benutzt
>
> Wenn Du genauer in die Tabelle schaust, wirst Du sehen, daß die meisten
> dieser Browser tatsächlich eine der "großen" Webengines benutzen: Gecko
> (Firefox), WebKit (Safari), oder WebEngine (Chromium).

Hä, das ist doch die ganze Zeit mein Punkt. Es gibt 3 ultra-komplexe 
Monster-Engines und 500 kleine die aber alle real nicht funktionieren.


>>> Mit einer Webapplikation kann man die beiden Dinge -- die Datenhaltung
>>> und -Aufbereitung und die Darstellung andererseits sogar wunderbar
>>> entkoppeln, weißt Du.
>>
>> Man kann mit allem gute Anwendungen schreiben. So richtig ideal ist aber
>> das HTML/JS-Zeug definitiv nicht, um z.B. Tabellen mit einigen Millionen
>> Zeilen anzuzeigen und zu durchsuchen. Mit QtWidgets geht das relativ gut
>> ohne sich groß zu verbiegen.
>
> Bitte probier' das mal, BTDT. Mit sowas haben sogar darauf
> spezialisierte Werkeuge wie LibreOffice

Hab ich schon oft genug gemacht, geht eigentlich ziemlich gut, weil 
sowas wie QAbstractItemModel erstmal nicht mit der Anzahl der Zeilen 
skaliert. Klar, von QSortFilterProxyModel sollte man dann eher absehen, 
das ist für >20k Rows eher nicht mehr geeignet.

Sicherlich kann ich mir sowas im Browser bauen. Hab ich aber nie 
gesehen, nur so Kack der beim herunterscrollen dann 5 Zeilen nachlädt 
mit Spinner und dann den Scrollbalken entsprechend resized. Meh. Was ist 
denn jetzt, wenn ich die letzte Zeile sehen will?

> Insofern, bitte, was soll denn diese verbissene Diskussion?

Die kommt daher, dass mir die Web-basierten Anwendungen, die ich 
verwende, überdurchschnittlich oft als schlecht optimiert und schlecht 
benutzbar (da z.B. keine Verwendung von Standard-GUI-Elementen mit 
entsprechenden Shortcuts etc.) auffallen. Das fürchterliche Skype zum 
Beispiel.

Sven B. schrieb:
> Sheeva P. schrieb:
>> Udo K. schrieb:
>>> Sheeva P. schrieb:
>>>> [1] https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_browsers
>
> Die Tabelle ist ein Witz, Sheeva. Sag mir einen auch nur ansatzweise
> brauchbaren Browser darin, der nicht auf der WebKit- oder Gecko-Engine
> basiert.

Ich hab' ganz gute Erfahrungen mit Midori und K-Meleon gemacht. Ja, die 
basieren alle auf "fetten" Webengines, und ja, für ein bisschen Plotting 
(mithin das, was der OP IMHO machen wollte) reichen die dicke aus. Zumal 
unser OP ja bei einer lokal laufenden Webapp dir volle Kontrolle darüber 
hätte, was sein Webserver ausliefert.

> Also mach dich nicht zum Depp und versuche anhand dessen die total
> sinnfreie These zu vertreten, es gäbe brauchbare "schlanke"
> Browser-Engines.

Bitte entschuldige, aber ich habe gesagt, daß es brauchbare, schlanke 
Browser gibt. Aber selbst wenn: ob das für den Anwendungsfall unseres TO 
tatsächlich eine Rolle spielt, weiß nur er selbst... vielleicht mag er 
ja noch etwas zu diesem Thema sagen, ansonsten ist die Diskussion 
mittlerweile nämlich nur noch hypothetisch und somit irrelevant.

Sven B. schrieb:
> Nur so mal als Referenz, auf welchem Niveau sich die
> nicht-Webkit/Gecko-Engines bewegen.

Und für das Plotten von ein paar Daten ist das nicht ausreichend? Ach 
komm', Sven, das wissen wir beide besser.

Sven B. schrieb:
> Sheeva P. schrieb:
>> aber mit den behaupteten "ein paar 100 kB" ist es eben auch
>> nicht getan.
>
> Habe ich nie behauptet.

Nein, das hast Du nicht, aber Du hast dem inhärent zugestimmt. Aber 
genau das war der Punkt, dem ich widersprochen hatte... ;-)

>> Ja, machen sie. Sagt jedenfalls Dave Page [1], einer der Core-Entwickler
>> von PostgreSQL. Und ich selbst bin dem Ding auch schon begegnet, als ich
>> PgAdmin4 in einen Docker-Container eingebaut habe.
>
> Ich kriege es hier nicht dazu das zu tun, --help gibt es nicht und gegen
> irgendwas in der Richtung gelinkt ist es auch nicht. Ich wäre aber sehr
> überrascht, wenn es nicht einfach QtWebEngine laden würde. Was soll es
> denn sonst tun?

QtWebKit laden, zum Beispiel. ;-)

>> Wenn Du genauer in die Tabelle schaust, wirst Du sehen, daß die meisten
>> dieser Browser tatsächlich eine der "großen" Webengines benutzen: Gecko
>> (Firefox), WebKit (Safari), oder WebEngine (Chromium).
>
> Hä, das ist doch die ganze Zeit mein Punkt.

Aber eben nicht meiner. Tatsache ist nämlich, daß die "großen" Browser 
zusätzlich zur inhärenten Komplexität und dem Ressourcenverbrauch ihrer 
Engines -- die ich keineswegs bestreite -- noch viele andere Dinge tun. 
Beispielsweise führen sie üblicherweise eine History, die, wenn man den 
Back-Button des Browsers benutzt, wieder genau an jene Stelle springt, 
welche man vorher hatte. Dabei müssen zum Teil ziemlich komplizierte 
Zustände gespeichert -- und im Falle des Falles wiederhergestellt -- 
werden. Daß die dann regelmäßig auch noch tief in einem von drölfzig 
genutzten JavaScript-Frameworks, Ad- und anderen Datensammlerskripts 
vergraben sind... Ich weiß nicht, ob Du Dich in Deinem Leben mal mit 
Serialisierungen von Binärobjekten (Arbeitsspeicherinhalten) befassen 
mußtest, aber aus meiner Erfahrung kann ich sagen: das ist teuer, mit 
zunehmender Komplexität sogar richtig teuer.

> Es gibt 3 ultra-komplexe
> Monster-Engines und 500 kleine die aber alle real nicht funktionieren.

Ja, genau, es gibt drei komplexe Monster-Engines, und die übrigen 
sind... naja, allenfalls manchmal brauchbar. Das liegt aber nicht an den 
Engines, sondern an den Anforderungen, die an sie gestellt werden: denn 
sie sollen
HTML, CSS und JavaScript in verschiedenen Versionen und Varianten sauber 
parsen, rendern und darstellen, natürlich unbedingt sicher sein, und 
dazu obendrein auch noch fehlertolerant sein, weil manche Leute nicht 
fähig sind, einen <li>-Tag auch mit </li> zu schließen -- und das ist 
noch ein eher einfacher Fehler.

>> Insofern, bitte, was soll denn diese verbissene Diskussion?
>
> Die kommt daher, dass mir die Web-basierten Anwendungen, die ich
> verwende, überdurchschnittlich oft als schlecht optimiert und schlecht
> benutzbar (da z.B. keine Verwendung von Standard-GUI-Elementen mit
> entsprechenden Shortcuts etc.) auffallen. Das fürchterliche Skype zum
> Beispiel.

Das sehe ich ganz ähnlich wie Du, und die Reihe übler Webapplikationen 
ist lang, sehr lang. OS- oder XtCommerce? Nagios? OTRS? Und intern kenne 
ich noch einen Haufen wesentlich übleres Zeugs...

Aber daß es besch...eidene Webseiten und -Interfaces gibt, macht ja noch 
nicht die ganze Technologie schlecht, oder? Zumal es auch gute Beispiele 
gibt, mir fallen da auf Anhieb Kibana, AWX und die Produkte von 
Atlassian ein. Google Docs. Die Webschnittstellen zum Provisioning bei 
AWS und GCP. Gitlab, Mattermost, Artifactory, Prometheus, Grafana... you 
get the idea.

Die zeigen: es geht. Man muß es nur richtig machen. Und in diesem 
fucking Punkt unterscheiden sich Webschnittstellen in überhaupt exakt 
gar nichts von klassischen FatClients. Und wenn ein Entwickler keine 
Ahnung von so Themen wie Usability, Ergonomie, Workflows, Styleguides, 
solchen Dingen hat... wir wissen beide, was dabei 'rauskommt. Leider. 
;-)

Sheeva P. schrieb:
> Schau, Karl, Du magst mich nicht. Ist ja auch ok, damit kann ich
> wunderbar leben...

Hast du keine Argumente mehr oder warum glaubst du mich persönlich 
angehen zu müssen, Troll?

Sheeva P. schrieb:
> Sven B. schrieb:
>> Nur so mal als Referenz, auf welchem Niveau sich die
>> nicht-Webkit/Gecko-Engines bewegen.
>
> Und für das Plotten von ein paar Daten ist das nicht ausreichend? Ach
> komm', Sven, das wissen wir beide besser.

Nein, ist es nicht. Nimm mal irgendeine JS-Bibliothek und versuche die 
da auszuführen. Es wird nicht gehen.

> Dabei müssen zum Teil ziemlich komplizierte
> Zustände gespeichert -- und im Falle des Falles wiederhergestellt --
> werden.

Real funktioniert das manchmal für die Scrollposition und so gut wie nie 
für den Inhalt des Formulars, das ich gerade ausgefüllt habe.

> Aber daß es besch...eidene Webseiten und -Interfaces gibt, macht ja noch
> nicht die ganze Technologie schlecht, oder?

Da hast du natürlich recht. Nur irgendwie kommt es mir so vor, als ob 
die Positivbeispiele bestenfalls "akzeptabel" sind, und eben nicht 
"gut". Vielleicht bin ich da biased -- aber auch sowas wie Google Docs, 
klar, technisch eindrucksvoll, aber so richtig flüssig und schön fühlt 
sich das nicht an. Fängt mit so Unsinn an wie dass die Accelerator-Keys 
für das Menu nicht gehen und nur die Hälfte der Shortcuts, etc ...
Auch mit den Atlassian-Tools habe ich so meine Dinge, die mich ärgern. 
Klar, die gibt es bei jedem Tool, aber bei den Web-Tools sind es oft 
dieselben Problemkategorien -- Dinge, die sich beim Seitenaufbau 
verschieben und mir den Button unter der Maus vertauschen den ich gerade 
klicken wollte, zum Beispiel.

Stefan ⛄ F. schrieb:
> Auf mobilen Geräten geht der Trend seltsamerweise sogar in die
> umgekehrte Richtung - von Web zu Apps.

True, aber dabei geht es primär um etwas gänzlich anderes: nämlich 
darum, Daten vom User zu gewinnen... :-(