Hallo :)
Für das Projekt meiner Abschlussarbeit benötige ich eine GUI. Gerne
möchte ich mich dann in eine zukunftsfähige GUI einarbeiten. Die GUI
soll auf einem SBC laufen - da nicht kommerziell wahrscheinlich auf
einem RPi, oder sollte man doch ein x86/64-Prozessorboard nehmen? Habt
ihr dort Vorschläge oder Ideen? Es sollte optisch schon zeitgemäß
aussehen (TKinter fällt raus). Ich kann C/C++, Python, (Java). Danke
euch
RPi und zeitgemäßes Gui passen ja schon einmal kaum zusammen. Da kann
der Raspi aber nichts dafür...
Qt liefert, wenn möglich, ein natives Gui passend zum Betriebssystem. Ob
sich der Einarbeitungsaufwand in solch Universal-Monster aber für ein
einziges Projekt lohnt, musst du selber wissen. Wenn es da nur um ein
paar Buttons und Icons geht, würde da doch eher was gescriptetes mit
niedriger Einstiegsschwelle wählen.
Oliver
Ich sag mal: weder - noch.
Zukunftsfähig ist eine GUI nur, wenn ihre Controls, also Buttons und
Listenelemente, Menüs und Fensterrahmen, vollkommen programmspezifisch
mit beliebiger auch nicht-rechteckiger Aussenkontur gezeichnet werden
können, und die Standardcontrols halt bloss einem die Mühe abnehmen, es
auch zeichnen zu müssen
UND
die GUI Flache es trotzdem erlaubt, in irregulär begrenzten
Bildschirmflächen flackerfrei (also double buffering) animierte Bitmaps
in Videoqualität und Geschwindigkeit darzustellen.
UND
wenn es die Identifikation der Controls auf der Oberfläche nicht nur per
Position, sondern namentlicher ID erlauben UND an jedem Control
(zumindest statisch, aber gern auch dynamisch, jedoch nicht nur
dynamisch) programmspezifische 'user-data' angehängt werden kann.
Moin, -
willkommen im Club. Ich stehe vor demselben Problem: Ich wuerde gern Qt
benutzen, nur sind die Lizenzbedingungen ein wenig zu komplex. Zudem
soll das Prograemmchen mit einer Datenbank spielen (Transaktionen sind
notwendig).
Dann dachte ich an FreePascal (Lazarus) Laeuft unter Windows/Linux
(sogar auf einem Raspi3/4). Lizenz waere fuer mich OK.
Ich habe noch keine richtige Loesung gefunden.
Gruesse
Th.
Andreas schrieb:> da nicht kommerziell wahrscheinlich auf einem RPi
Dieser logische Kurzschluss ist mir jetzt nicht so ganz klar.
> auf einem RPi, oder sollte man doch ein x86/64-Prozessorboard nehmen?> Habt ihr dort Vorschläge oder Ideen?
Welche Busse oder Interfaces brauchst du? Wieviel Leistung kannst du
wegkühlen? Wieviele Daten musst du wie schnell speichern? Was soll die
GUI wie schnell abbilden?
Andreas schrieb:> Für das Projekt meiner Abschlussarbeit benötige ich eine GUI. Gerne> möchte ich mich dann in eine zukunftsfähige GUI einarbeiten. Die GUI> soll auf einem SBC laufen - da nicht kommerziell wahrscheinlich auf> einem RPi, oder sollte man doch ein x86/64-Prozessorboard nehmen?
Kommt drauf an, was deine GUI so alles machen soll.
> Habt ihr dort Vorschläge oder Ideen? Es sollte optisch schon zeitgemäß> aussehen (TKinter fällt raus).
Soll es dennoch eher eine klassische "Widget"-basierte GUI sein oder
eher sowas wie eine Touch-GUI mit schicken Animationen u.s.w.? Qt
beinhaltet für beides jeweils ein eigenes GUI-Framework.
Rath Looser schrieb:> Andreas schrieb:>> soll auf einem SBC laufen>> Kann man SBC essen?>> https://de.wikipedia.org/wiki/SBC
Himbeerkuchen kann man zwar essen, aber ich glaube, das der nicht das
ist, was mit "RPi" gemeint ist. Und essbare Single *Board* Computer
kenne ich nicht.
MaWin schrieb:> Ich sag mal: weder - noch.
Deine folgenden Beschreibungen hätte jetzt eher für "sowohl, als auch"
gesprochen. Alle von dir genannten Sachen kann man mit Qt machen, Bisher
dachte ich, das ginge auch mit HTML5, womit ich mich aber
zugegebenermaßen nicht auskenne.
Thomas W. schrieb:> Ich wuerde gern Qt benutzen, nur sind die Lizenzbedingungen ein wenig zu> komplex.
Was meinst du damit? Was genau ist dir zu komplex?
> Zudem soll das Prograemmchen mit einer Datenbank spielen (Transaktionen> sind notwendig).
Das ist doch in Qt alles schon eingebaut.
https://doc.qt.io/qt-5/sql-sqlstatements.html#transactions
Thomas W. schrieb:> Ich wuerde gern Qt benutzen, nur sind die Lizenzbedingungen ein wenig zu> komplex
Für nicht kommerzielle Anwendungen, wie beim TO, dürfte das ja kein
Problem sein und für kommerzielle Anwendungen wenn man nichts bezahlen
will, gibt es einen Teil des Frameworks als LGPL
Thomas W. schrieb:> Zudem> soll das Prograemmchen mit einer Datenbank spielen (Transaktionen sind> notwendig).>
Was haben GUI und Datenbank miteinander zu tun?
OK, QT hat auch eine Datenbank-Klasse mit dabei, die muss man aber nicht
benutzen.
Der Einstieg in QT geht schnell, einfache Dialog sind in einer Stunde
fertig. Die Dokumentation ist rpima und umfangreich. Hilfestellungen im
Web sind mehr aus ausreichend.
Ich würde nichts anderes nehmen.
Und wenn man will, geht eine Portierung auf Windows oder MacOS recht
zügig.
Hallo und Danke schon mal für eure Antworten.
Rath Looser schrieb:> Kann man SBC essen?
man kann alles, wenn man möchte
Oliver S. schrieb:> RPi und zeitgemäßes Gui passen ja schon einmal kaum zusammen. Da kann> der Raspi aber nichts dafür...
Warum das? Wegen begrenzter Rechen-/Grafik-Leistung?
MaWin schrieb:> Ich sag mal: weder - noch.
Was wäre denn die passende Alternative mit der notwendigen Bedingung:
kostenlos für nichtkommerziell
Thomas W. schrieb:> willkommen im Club. Ich stehe vor demselben Problem: Ich wuerde gern Qt> benutzen, nur sind die Lizenzbedingungen ein wenig zu komplex. Zudem> soll das Prograemmchen mit einer Datenbank spielen (Transaktionen sind> notwendig).
das ist beides kein Problem und eher (mittlerweile) einfacher gelöst als
bei vielen Alternativen.
Lothar M. schrieb:> Andreas schrieb:>> da nicht kommerziell wahrscheinlich auf einem RPi> Dieser logische Kurzschluss ist mir jetzt nicht so ganz klar.
mit anderen Worten: gerne günstig
Lothar M. schrieb:> Welche Busse oder Interfaces brauchst du? Wieviel Leistung kannst du> wegkühlen? Wieviele Daten musst du wie schnell speichern? Was soll die> GUI wie schnell abbilden?
Aktuell nur USB. Es soll nur die Visu und ein ganz klein bisschen
Managment machen. Der eigentliche Prozess findet auf einem(mehreren)
LowLevelBoards statt.
Rolf M. schrieb:> Kommt drauf an, was deine GUI so alles machen soll.
Nur Visu mit einer Aktualisierungsrate von max 10Hz. Also der
Hintergrundprozess ist vernachlässigbar. Es soll nur nicht Aussehen wie
Windows 95.
PittyJ schrieb:> Was haben GUI und Datenbank miteinander zu tun?> OK, QT hat auch eine Datenbank-Klasse mit dabei, die muss man aber nicht> benutzen.
Bei Einsatz als vollwertiges TopLevel zB für die Dokumentation von
Prozesswerten.
PittyJ schrieb:> Der Einstieg in QT geht schnell, einfache Dialog sind in einer Stunde> fertig. Die Dokumentation ist rpima und umfangreich. Hilfestellungen im> Web sind mehr aus ausreichend.> Ich würde nichts anderes nehmen.
Danke. Hast du Erfahrung wie es mit der Performance auf ARM-Systemen,
speziell RPi, verhält? Pakete sind kompiliert wohl nur für intelbasiert
verfügbbar.
Mir fallen da HTML5, JavaFX oder das hier schon oft genannte Qt ein. Qt
ist ja hinlänglich bekannt, ich sage mal was zu den anderen Optionen:
Für kleine Tools und Demos auf dem Desktop nutze ich gerne JavaFX, es
ist recht angenehm damit zu arbeiten. Dort wird sehr stark auf Widgets
gesetzt, es hat aber auch ein Canvas mit dem man beliebige Konstrukte
realisieren kann. Man kann die Widgets mit CSS stylen und die
Verknüpfung zwischen GUI-Elementen und Code Event-basiert realisieren.
Für Touch-Anwendungen wegen fehlendem Fokus auf Touch-Widgets NICHT zu
empfehlen, außer man ist bereit viel Aufwand zu betreiben.
Talk zu JavaFX auf dem Pi, ab ca 30m geht es um JavaFX:
https://www.youtube.com/watch?v=7Be0VB3qLIQ
Web-Anwendungen können auch gut funktionieren, man darf sich aber nicht
so weit aus dem Fenster lehnen was Animationen, Übergänge und
Medieninhalte angeht, sonst ist der Pi schnell mal überfordert und es
gibt Frameeinbrüche. Mit Qt kannst du natürlich aus der vorhandenen
Rechenleistung einiges mehr rausholen als mit HTML5. Grundsätzlich ist
HTML5 aber sehr leistungsfähig und extrem vielseitig, besonders wenn man
pures HTML ohne aufgeblähte Frameworks nutzt.
Tutorial zu FullPageOS, eine Distro die nach dem Boot eine Webpage im
Vollbildmodus anzeigt: https://www.youtube.com/watch?v=rHwrwz3kv5o
Andreas schrieb:> Hallo :)>> Für das Projekt meiner Abschlussarbeit benötige ich eine GUI. Gerne> möchte ich mich dann in eine zukunftsfähige GUI einarbeiten. Die GUI> soll auf einem SBC laufen - da nicht kommerziell wahrscheinlich auf> einem RPi, oder sollte man doch ein x86/64-Prozessorboard nehmen? Habt> ihr dort Vorschläge oder Ideen? Es sollte optisch schon zeitgemäß> aussehen (TKinter fällt raus). Ich kann C/C++, Python, (Java). Danke> euch
Als ich das letzte Mal mit QT zu tun hatte, brauchten viele Sachen
OpenGL bzw GLES. Meine Hardware (MIPS) konnte aber kein OpenGL, sondern
hatte nur einen einfachen Linux Framebuffer. Damit war QT praktisch
raus.
Unter Linux ist der Gnome Desktop verbreitet, und darunter befindet sich
GTK, das es schon lange gibt, das auch nicht so schnell verschwinden
wird, und das komplett unter LGPL steht. Heißt also: keine
Lizenzprobleme. GTK setzt auf X oder Wayland auf, d.h. Du bist frei in
der Wahl Deiner Hardware, und solange Du X hast, läuft das - im
Gegensatz zu QT. Damit verschwinden auch die Abhängigkeiten von
irgendwelchen proprietären Grafiktreibern, Framebuffer reicht
prinzipiell.
Andere Möglichkeit: wxwidgets. Ist Multiplattformfähig.
fchk
Moin, -
Rolf M. schrieb:> Thomas W. schrieb:>> Ich wuerde gern Qt benutzen, nur sind die Lizenzbedingungen ein wenig zu>> komplex.>> Was meinst du damit? Was genau ist dir zu komplex?
Fuer Anfaenger:
- 4kUS$/a ist schon mal eine Hausnummer, nach Ablauf Deiner Subscription
kannst Du noch nicht einmal Bugfixes verteilen. Die 4kUS$ waeren schon
OK, wenn die Lizenz nicht auslaufen wuerde. Denn Du weisst nicht, welche
Zahl naechstes Jahr aufgerufen wird.
- I Don't trust Qt: Sie haben die perpetual license ab Qt6 gecancelt,
d.h. nur Abo.
- Open Source Usage Obligations sind schon sehr weitreichend.
-> Es ist schade, aber aus meiner Sicht ist das Risiko beim Einsatz von
Qt zu hoch. Aber: Your Mileage May Vary.
Gruesse
Th.
Also, zukunftsträchtig ist HTML.
Nur: Wenn Du keine Erfahrung mit der HTML- und Javascript-Entwicklung
hast, dann ist das ein ganz schöner Brocken. Es geht nicht um die
Sprache, die kannst Du sicherlich. Das Tooling und das notwendige
"Nebenwissen" und der Overhead um so eine HTML-Geschichte zu bauen, ist
doch recht umfangreich.
D.h. wenn Du C++ kannst und Dir keinen riesen Rucksack auf den Rücken
schnallen willst, nimm halt Qt. Aber sie Dir im Klaren: Qt (und alle
GUIs abseits von Android und IPhone) sind auf einem absteigenden Ast.
Die einen schneller, die einen langsamer. Aber in der Summe sind die
Zeiten rum. Die Gegenwart ist "schon" HTML.
Thomas W. schrieb:> - Open Source Usage Obligations sind schon sehr weitreichend.
naja, LGPL halt. Sind im Grunde keine anderen Obligations als z.B. bei
GTK oder wxWidgets.
Nur dass bei der QT jeder meint, er hätte einen super-tollen Geheim-Hack
gefunden wie er trotzdem kommerzielle Software mit der LGPL-Version
verkaufen kann, und sie es deshalb nochmal klipp und klar hinschreiben.
Ich rate zu Python in Verbindung mit Qt.
Damit sollte man recht schnell zu ersten Ergebnissen kommen.
Vorteil: du kannst dir deine GUI im QT-Designer zusammenklicken und das
.ui-File direkt im Python-Code laden.
Und den ganzen Blödsinn mit dem moc (und Kompilieren generell) kannst du
dir auch sparen.
Εrnst B. schrieb:> Nur dass bei der QT jeder meint, er hätte einen super-tollen Geheim-Hack> gefunden wie er trotzdem kommerzielle Software mit der LGPL-Version> verkaufen kann, und sie es deshalb nochmal klipp und klar hinschreiben.
Da es weder die GPL noch die LPGL verbieten, Software kommerziell zu
verkaufen, hat Qt da nichts dagegen, wenn das jemand unter Einhaltung
der GPL/LPGL-Bedingungen tut.
Das ist dort nicht anders als bei jeder anderen Software unter diesen
Lizenzen.
Oliver
Thomas W. schrieb:> Fuer Anfaenger:> - 4kUS$/a ist schon mal eine Hausnummer, nach Ablauf Deiner Subscription> kannst Du noch nicht einmal Bugfixes verteilen. Die 4kUS$ waeren schon> OK, wenn die Lizenz nicht auslaufen wuerde. Denn Du weisst nicht, welche> Zahl naechstes Jahr aufgerufen wird.
Wenn man eine kleine Firma mit unter 250k$ Umsatz pro Jahr ist, gibts
"Small Business" mit 500$/Jahr.
Andreas schrieb:> Für das Projekt meiner Abschlussarbeit benötige ich eine GUI. Gerne> möchte ich mich dann in eine zukunftsfähige GUI einarbeiten.
Man nimmt das was am wenigsten Arbeit macht und die Anforderungen
erfüllt.
Oliver S. schrieb:> Das ist dort nicht anders als bei jeder anderen Software unter diesen> Lizenzen.
Jep. Genau das habe ich gesagt.
Nur hat die QT auf der Webseite eben einen Erklärbär-Bereich, wo diese
Einschränkungen und was aus ihnen folgt nochmal klipp und klar stehen.
Was scheinbar zu Reaktionen führt wie:
Thomas W. schrieb:> Ich wuerde gern Qt> benutzen, nur sind die Lizenzbedingungen ein wenig zu komplex.
Komisch. Wenn's verschwurbelt in den Tiefen der LGPL steht, dann isses
OK, wenn es zusätzlich nochmal auf "deppensicher" erklärt wird, ist es
zu komplex.
Andreas schrieb:> PittyJ schrieb:>> Der Einstieg in QT geht schnell, einfache Dialog sind in einer Stunde>> fertig. Die Dokumentation ist rpima und umfangreich. Hilfestellungen im>> Web sind mehr aus ausreichend.>> Ich würde nichts anderes nehmen.>> Danke. Hast du Erfahrung wie es mit der Performance auf ARM-Systemen,> speziell RPi, verhält? Pakete sind kompiliert wohl nur für intelbasiert> verfügbbar.
Google "qt installieren raspberry pi"
Da findet man dann schnell, dass
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install qt5-default
sudo apt-get install qtcreator
sudo apt-get install libqt5serialport5
sudo apt-get install libqt5serialport5-dev
wohl reicht. Also das übliche apt-get ...
Die Performance ist gut. Da hatte ich schon schlechtere Intel-Systeme
vor 10 Jahren.
Im Wochenendhaus habe ich einen älteren Mac ausgemustert, und betreibe
einen Pi 400 als Surfstation. Das reicht auch für youtube etc. Mehr
braucht man im Normalfall nicht. Und das beste: kein Lüfter.
Andreas schrieb:> Pakete sind kompiliert wohl nur für intelbasiert verfügbbar.
Wie kommst du darauf?
Thomas W. schrieb:>> Was meinst du damit? Was genau ist dir zu komplex?>> Fuer Anfaenger:> - 4kUS$/a ist schon mal eine Hausnummer, nach Ablauf Deiner Subscription> kannst Du noch nicht einmal Bugfixes verteilen.
Es ist noch viel schlimmer: Du darfst nicht mal mehr die ursprüngliche
Version weiter verkaufen, wenn du keine gültige Lizenz hast. Das heißt,
wenn es keine Option ist, auf die OpenSource-Lizenz zu wechseln, musst
du den Vertrieb von allem, was auf Qt6 aufsetzt, mit Auslauf der Lizenz
komplett einstellen.
> -> Es ist schade, aber aus meiner Sicht ist das Risiko beim Einsatz von> Qt zu hoch. Aber: Your Mileage May Vary.
Sofern du nicht LGPL bzw. bei den entsprechenden Komponenten GPL
akzeptieren kannst, ja.
Le X. schrieb:> Ich rate zu Python in Verbindung mit Qt.> Damit sollte man recht schnell zu ersten Ergebnissen kommen.>> Vorteil: du kannst dir deine GUI im QT-Designer zusammenklicken und das> .ui-File direkt im Python-Code laden.
Das geht in C++ genauso. Nur macht das aus Performance-Gründen kaum
jemand.
Georg A. schrieb:> Thomas W. schrieb:>> Fuer Anfaenger:>> - 4kUS$/a ist schon mal eine Hausnummer, nach Ablauf Deiner Subscription>> kannst Du noch nicht einmal Bugfixes verteilen. Die 4kUS$ waeren schon>> OK, wenn die Lizenz nicht auslaufen wuerde. Denn Du weisst nicht, welche>> Zahl naechstes Jahr aufgerufen wird.>> Wenn man eine kleine Firma mit unter 250k$ Umsatz pro Jahr ist, gibts> "Small Business" mit 500$/Jahr.
Die Zahlen gelten übrigens pro Entwickler - jeder muss seine eigene
Lizenz haben und darf die nicht an andere übertragen. Hat man also ein
Entwicklungsteam mit 10 Mann, sind's bei der regulären Lizenz schon
40k/Jahr. Die Small Business ist auf 4 Lizenzen pro Firma begrenzt.
Hallo,
Qt bietet nicht nur die GUI, sondern relativ viel auch für
Schnittstellen (CAN/RS232/ETH/MQTT) welches für dein Projekt eventuell
benötigt wird. Ausserdem solltest Du Dir anschauen, ob Du Qt Widgets
oder Qml benutzen
willst. Ich würde mich für ein x86 SBC (up-board) oder Intel Nuc/etc.
entscheiden, andersfalls kann es einiges an Zeit kosten die Umgebung für
das Crosskomplieren und Debuggen einzustellen oder Du musst auf dem SBC
relativ langsam dein Programm jedesmal komplieren, so könntest Du vieles
auf deinem guten Desktop PC programmieren und testen.
Rolf M. schrieb:> Das geht in C++ genauso. Nur macht das aus Performance-Gründen kaum> jemand.
Nun ja, der Designer erzeugt daraus C++-Code, der nicht viel anders
aussieht ist, als handgestrickter. Da ist nichts langsamer.
Nur geht es letztendlich mit etwas Übung schneller, wenn man den Code
gleich von Hand schreibt, ganz ohne Designer.
Oliver
"Zukunftsfähge GUI" - Mein Gott, die sind doch alle mehr oder weniger
gleich. Und alle 2-3 Jahre kommt das nächste super-tolle Framework raus.
Womit hantiert man im GUI Bereich so rum?
-Gtk
-Qt
-WxWidget
-electron
-flutter
-Uno
-WPF
-Avalonia
-Fltk
-Xamarin
-UIKit
-mono
to be continued
Als Entwickler muss man sich mal eben an ein beliebiged Framework
ransetzen können und damit irgendwas machen. Mein Rat: Echt Pascal
nehmen. Weil das keiner benutzt, wird man damit bestimmt nicht zum
GUI-Fachidioten...
Oliver S. schrieb:> Nur geht es letztendlich mit etwas Übung schneller, wenn man den Code> gleich von Hand schreibt, ganz ohne Designer.
Ja... und Team-Kollegen dürfen sich durch Unmengen an unnötigem
Quelltext wühlen und Fehler suchen.
Andreas schrieb:> Für das Projekt meiner Abschlussarbeit benötige ich eine GUI
Für das was ich bisher so an Abschlussarbeiten gesehen habe reicht auch
FLTK locker aus. Was macht deine Arbeit so besonders das es QT sein
muss?
Oliver S. schrieb:> Nur geht es letztendlich mit etwas Übung schneller, wenn man den Code> gleich von Hand schreibt, ganz ohne Designer.
Das geht nie schneller weil das Layout aus dem Stand nicht so hinbekommt
wie mit einen GUI-Editor, ausser es ist hinterher egal wie scheisse das
aussieht. Man schreibt sich nen Wolf an Boilerplatecode, was unglaublich
viel Zeit frisst, selbst wenn du das Blind runterschreiben kannst, was
nie der Fall ist. Man hat unnötig viele Compilerläufe nur um die GUI zu
checken bis sie endlich so aussieht und sich so verhält wie man will.
Bei HTML/CSS geht das gerade noch, weil das ziemlich Highlevel ist, da
wird nur deklariert, als würde man ein XML schreiben das bei klassichen
Compilersprachen+GUI-Toolkits der GUI Editor erzeugt, eher noch ein
Level darüber ohne den XML-bloat. Bei JavaFX geht das sogar ziemlich
gut, teilweise nutzt das CSS-Syntax kann die FXML auch per Hand
schreiben, bei ersten Versionen hat man das oft auch so gemacht aber
auch dort ist das inzw. überflüssig.
Unter Swing hat man das alles noch von Hand gecoded, und endlose
Boilerplatecode nur für die GUI produziert und wollteste mal ein bischen
was anders haben blähte es alles noch mehr auf: Border anders, Insets
ein bischen breiter,.... meterweise GUI-Code. Aber auch dort gab es
später (hat lange genug gedauert) endlich brauchbare GUI-Editoren
(Matisse) als das Springlayout einzug hielt, die anderen Layoutmanager
waren ja (pain in the ass)^10. Wenns schnell gehen musste nahm man das
Nulllayout und absolut positioniert wie bei allen ältern GUI-Toolkits in
anderen Sprachen auch.
Oliver S. schrieb:> Rolf M. schrieb:>> Das geht in C++ genauso. Nur macht das aus Performance-Gründen kaum>> jemand.>> Nun ja, der Designer erzeugt daraus C++-Code, der nicht viel anders> aussieht ist, als handgestrickter. Da ist nichts langsamer.
Nicht der Designer, sondern der uic, und das war ja gerade mein Punkt.
Der generierte C++-Code ist nicht langsamer. Wenn du dagegen das ui-File
direkt im Programm einliest, muss erstmal das ganze XML-Geparse gemacht
und daraus dynamisch die Funktionsaufrufe ausgewählt werden. Das braucht
mehr Zeit. Und in Python ist das dann natürlich auch so.
Tw schrieb:> Andreas schrieb:>> Für das Projekt meiner Abschlussarbeit benötige ich eine GUI>> Für das was ich bisher so an Abschlussarbeiten gesehen habe reicht auch> FLTK locker aus. Was macht deine Arbeit so besonders das es QT sein> muss?
Warum ist Qt deiner Meinung nach denn nur für "besondere" Projekte
geeignet?
Generaldirektor Heinrich Haffenloherich schrieb:> Das geht nie schneller weil das Layout aus dem Stand nicht so hinbekommt> wie mit einen GUI-Editor, ausser es ist hinterher egal wie scheisse das> aussieht.
Du kennst Qt*
[ ] Nein
[ ] Nein
*zutreffendes bitte ankreuzen.
Oliver
Rolf M. schrieb:> Nicht der Designer, sondern der uic, und das war ja gerade mein Punkt.> Der generierte C++-Code ist nicht langsamer. Wenn du dagegen das ui-File> direkt im Programm einliest, muss erstmal das ganze XML-Geparse gemacht> und daraus dynamisch die Funktionsaufrufe ausgewählt werden. Das braucht> mehr Zeit. Und in Python ist das dann natürlich auch so.
Wurde seitens TE erwähnt dass es auf Performance ankommt?
Ich hatte den Eindruck, die GUI sei eher so ne Nebenbaustelle, soll also
möglichst wenig Aufwand verursachen, aber trotzdem einigermaßen hübsch
aussehen.
Oliver S. schrieb:> Generaldirektor Heinrich Haffenloherich schrieb:>> Das geht nie schneller weil das Layout aus dem Stand nicht so hinbekommt>> wie mit einen GUI-Editor, ausser es ist hinterher egal wie scheisse das>> aussieht.>> Du kennst Qt*>> [ ] Nein> [ ] Nein>> *zutreffendes bitte ankreuzen.
Diese Aussage ist sehr überspitzt geschrieben, aber zumindest an dieser
hier ist was dran:
Generaldirektor Heinrich Haffenloherich schrieb:> Man hat unnötig viele Compilerläufe nur um die GUI zu> checken bis sie endlich so aussieht und sich so verhält wie man will.
Ich hab früher immer alles von Hand geschrieben, aber bei etwas
komplexeren Layouts bin ich dann doch mit der WYSIWYG-Methode im
Designer schneller, als wenn ich nach jeder Änderung erstmal compilieren
und das Programm starten muss, um zu sehen, ob's jetzt passt.
Le X. schrieb:> Wurde seitens TE erwähnt dass es auf Performance ankommt?
Er will aus Kostengründen einen Raspi verwenden, ist sich aber nicht
sicher, ob das performant genug ist.
Frank K. schrieb:> Als ich das letzte Mal mit QT zu tun hatte, brauchten viele Sachen> OpenGL bzw GLES. Meine Hardware (MIPS) konnte aber kein OpenGL, sondern> hatte nur einen einfachen Linux Framebuffer. Damit war QT praktisch> raus.
Unsinn. Qt unterstützt den Linux Framebuffer schon seit Ewigkeiten als
Platform. Man startet die Applikation einfach mit dem Argument -platform
linuxfb:fb=/dev/fbX und schon läuft sie auf dem Framebuffer.
https://doc.qt.io/qt-5/embedded-linux.html
Dirk K. schrieb:> Qt-Klon
"was initially derived from the Qt framework. Over the last several
years CopperSpice has completely diverged"
Unter Klon hätte man jetzt was anderes verstanden...
Oliver
Al Fine schrieb:> "Zukunftsfähge GUI" - Mein Gott, die sind doch alle mehr oder weniger> gleich...
Richtig, die von dir aufgezählten sind alle relativ gleich. Was sich
aber in den letzten Jahren schon recht deutlich gezeigt hat ist ein
Trend hin zu "Immediate Mode" GUIs
(https://en.wikipedia.org/wiki/Immediate_mode_GUI) wie es etwa Dear
ImGui (https://github.com/ocornut/imgui) implementiert.
Grad für schnelle iterative Arbeiten an kleineren GUIs eine willkommene
Abwechslung.
BobbyX schrieb:> Frank K. schrieb:>>> Als ich das letzte Mal mit QT zu tun hatte, brauchten viele Sachen>> OpenGL bzw GLES. Meine Hardware (MIPS) konnte aber kein OpenGL, sondern>> hatte nur einen einfachen Linux Framebuffer. Damit war QT praktisch>> raus.>> Unsinn. Qt unterstützt den Linux Framebuffer schon seit Ewigkeiten als> Platform. Man startet die Applikation einfach mit dem Argument -platform> linuxfb:fb=/dev/fbX und schon läuft sie auf dem Framebuffer.
Ja, aber nicht alles. Bei QT5 sind etliche Dinge dazugekommen, die
explizit OpenGL voraussetzen. Und dann siehst Du nichts. Die Sachen, die
mit fb funktionieren, sind auf QT 4 Level.
fchk
Vincent H. schrieb:> Richtig, die von dir aufgezählten sind alle relativ gleich. Was sich> aber in den letzten Jahren schon recht deutlich gezeigt hat ist ein> Trend hin zu "Immediate Mode" GUIs> (https://en.wikipedia.org/wiki/Immediate_mode_GUI) wie es etwa Dear> ImGui (https://github.com/ocornut/imgui) implementiert.
Ja... liest sich etwas so wie Immediate-Mode OpenGL vs Scenegraphs. Ist
aber natürlich leichter verständlich, wenn man sich nicht erstmal durch
Erklärungskapitel wie "Auflösung von Resourcen-Referenzen", "Angewandtes
Responsive Design" usw. durchackern muss, um etwas auf den Bildschirm zu
kriegen. Den Trend sehe ich nicht.
> Den Trend sehe ich nicht.
Diese Art GUI-System wird extrem häufig in OpenGL-basierten Tools, Demos
und Game-Engines verbaut, unter anderem weil es z.B. in Form von "Dear
IMGUI" einfach einzubinden ist, hier einige Beispiele:
https://gist.github.com/bkaradzic/853fd21a15542e0ec96f7268150f1b62#examples
Der Vorteil ist, dass man keine Widget-Objekte oder ähnliches managen
muss.
Wenn wir einen Button wollen, der beim drücken "Hello" in die Konsole
schreibt, würde das mit Retained Mode GUI z.B. so aussehen:
1
Buttonbtn;
2
3
init(){
4
btn=newButton("Hello");
5
btn.onPressed(&helloFunction);
6
}
7
8
loop(){
9
gui::render();
10
}
11
12
helloFunction(){
13
print("Hello");
14
}
Und so mit Immediate Mode GUI:
1
init(){}
2
3
loop(){
4
gui::button("Hello",&helloFunction);
5
gui::render();
6
}
7
8
helloFunction(){
9
print("Hello");
10
}
Man hat bei IMGUI keine "GUI-Objekte" in der Applikation selbst. Also
keine Widget Objekte oder Referenzen auf irgendwas aus dem GUI, die man
initialisieren, miteinander verbinden, löschen usw muss. Das eignet sich
aber nicht für alle Situationen.
Wo soll die GUI denn überhaupt angezeigt werden,
Raspberry Pi klingt für mich danach das es nicht auf dem normalen
bürorechner laufen soll, vieleicht dann mit kleinem Display?
dann währe die Frage ob es nicht auch ein µC (z.B.stm32F7xx) tut, darauf
könnte man dann z.B. mit TouchGFX oder QT for uC oder oder oder etwas
zusammenbauen. Oder wenn es etwas komplet fertiges (und u.a. arduino
programmierbar) sein soll, vieleicht ein FTDI EVE?
Eiene Weitere möglichkeit wäre etwas auf Android Basis zu machen
Wie immer gilt, erst müssen die Anforderungen bekannt sein, um daraus
dann die 2-3 sinvollsten Lösungen gegeneinander stellen zu können.
just my 4 cent
Florian S. schrieb:> Man hat bei IMGUI keine "GUI-Objekte" in der Applikation selbst. Also> keine Widget Objekte oder Referenzen auf irgendwas aus dem GUI, die man> initialisieren, miteinander verbinden, löschen usw muss. Das eignet sich> aber nicht für alle Situationen.
Für einfache GUIs kann ich mir das vorstellen, aber wenn's etwas
komplexer wird, klingt das für mich eher umständlich.
Interessanterweise geht Qt mit seinem QML eher noch in die
entgegengesetzte Richtung, denn QML ist eine deklarative Sprache. Man
schreibt eigentlich fast alles nur noch als Deklaration bzw.
Initialisierung von Objekten, die dann beim Start erzeugt werden. Dabei
beschreibt man nicht nur den Initialzustand, sondern auch dynamische
Vorgänge als Deklaration. Ganz simples Beispiel:
Hier deklariere ich ein Fenster und darin ein Rechteck, das halb so
breit ist wie das Fenster. Der wesentliche Punkt ist hierbei, dass das
nicht nur beim Start so ist, sondern der Zusammenhang auch später
bestehen bleibt. Das heißt, wenn ich die Fensterbreite ändere, passt
sich das Rechteck immer so an, dass es halb so breit bleibt wie das
Fenster. In Qt-Sprech nennt sich das Property Binding. Das Behavior
sorgt dafür, dass die Größenänderung nicht unmittelbar passiert, sondern
als ob es über eine Feder mit dem Fenster verbunden ist.
> Für einfache GUIs kann ich mir das vorstellen, aber wenn's etwas> komplexer wird, klingt das für mich eher umständlich.
Joa, wird häufig nur dort benutzt, wo einfach ein paar Programmvariablen
angezeigt und editierbar gemacht werden müssen. Ich setze es bei meinen
Projekten auch nicht ein.
Nimm Freepascal/Lazarus. Damit erstellte Programme laeufen nativ auf den
bekannten Plattformen einschliesslich Arm-Linux (z.B. Raspi). Die
Entwicklung gerade kleiner Gui-Programme geht damit schneller als mit
jedem anderen System. Bei groesseren Programmen hilft der RAD-Ansatz
weniger, der Vorsprung ggue. anderem wird dann kleiner.
Ob eine damit erstellte Anwendung gut oder nach "90er" aussieht, liegt
wie immer am Programmierer.
Maxe schrieb:> Ob eine damit erstellte Anwendung gut oder nach "90er" aussieht, liegt> wie immer am Programmierer.
Die Programmiersprachen, die ich kenne, rufen intern die
Windows - API zum Erzeugen von Fenstern und Controls auf.
Windows gibt dann die entsprechenden Handle zurück.
Da wird sich das Aussehen eher an der entsprechenden Windows
Version orientieren. Bei Win95 oder XP kann es da schon
Unterschiede geben. Es sei denn, wenn es die entsprechende
Sprache zulässt, man erzeugt seine eigenen Klassen für die
entsprechenden Elemente, wie Buttons usw. und registriert
sie dann bei Windows. Aber sowas macht man eigentlich nur,
wenn man Spezial-Lösungen möchte, die halt extravagant
aussehen sollen.
Somit möchte ich mal sagen, dass die Anwendung eher nach der
vorhandenen Windowsversion aussieht.
Heinz B. schrieb:> Die Programmiersprachen, die ich kenne, rufen intern die> Windows - API zum Erzeugen von Fenstern und Controls auf.> Windows gibt dann die entsprechenden Handle zurück.> Da wird sich das Aussehen eher an der entsprechenden Windows> Version orientieren.
Das hat weniger mit der Programmiersprache als mit dem GUI-Toolkit zu
tun. Bei Qt kann man wählen, ob es das tun soll oder nicht.
Und wenn man sich die Microsoft-eigenen Toolkits anschaut, von MPC,
Windows-Forms, WPF, Metro, UWP und wie sie alle heißen, dann stellt man
fest, dass die auch unter dem selben System alle irgendwie
unterschiedlich aussehen.
Was spricht gegen C#? Ist halt nicht cross-plattform.
Dann zwischen C++ und C# interfacen mittels C++ CLI z.B.
Python und QT ist aber auch meiner Meinung nach die effizienste
Variante.
Wer hat im Jahr 2021 noch Bock auf C++...
Zukunftsfähig?
Eigentlich ist beides nicht so wirklich zukunftsfähig.
Die auf auf Smalltalk aufbauenden GUIs wie Qt haben die bessere
Architektur. Allee HTML5 Frameworks ignorieren die Erfahrungen, die zur
Qt geführt haben.
Die HTML5 Frameworks sind natürlich bedeutend besser, wenn du nicht
diese drögen Standard Widgets haben willst.
Zukunftsfähig wäre die Qt Architektur kombiniert mit der HTML5
Flexibilität. Arbeite dich in beides ein und konstruiere ein System, was
beide Vorteile verbindet. "The best way to predict the future is to
invent it".
P.S: Python oder C++ ? Beides! Schau dir Blender an. Die Performance
kritischen Sachen in C++. Und die Features, die aus Experimenten
einstanden sind in Python implementiert.
guten morgen,
fuer saemtliches, was irgendwie "frontend" benoetigt, arbeite ich
mittlerweile mit Vue.JS und HTML5; richtung raspberry dann z.b. selber
geschriebene REST-API mittels python & FastAPI. das geht recht flott,
das man sich dort etwas zusammengebaut hat.
ist aber sicherlich nicht so performant als eine "richtige" GUI mit Qt
auf dem zielsystem. aber fuer so dinge wie "schaltbare netzwerk
steckdosen"
oder temperatur sensoren langt das vollig und kann auch mit
fremd-systemen
verwendet werden, da ja die REST(ish) API die einzigste schnittstelle
ist.
gruss,
-- randy
> fuer saemtliches, was irgendwie "frontend" benoetigt
Wurde dieser Punkt schon genannt?
In Zukunft erwartet absolut jeder, die GUI muss auch auf dem Smartphone
laufen. Wenn dir unterwegs einfällt, du hast Heizung abschalten
vergessen, willst du nicht zurück fahren.
> ist aber sicherlich nicht so performant
Interessiert doch niemanden mehr. Smartphone und 5G sind mehr als
schnell genug.
Heinz B. schrieb:> Maxe schrieb:>> Ob eine damit erstellte Anwendung gut oder nach "90er" aussieht, liegt>> wie immer am Programmierer.>> Die Programmiersprachen, die ich kenne, rufen intern die> Windows - API zum Erzeugen von Fenstern und Controls auf.> Windows gibt dann die entsprechenden Handle zurück.
Zumindest unter Win7 war die Standardfarbe noch grau, also Hintergrund
und so. Windows hat sich in seinen Programmen, Explorer/Systemsteuerung
(zum Glück) selbst nicht daran gehalten. Auch die "Adressleiste" im
Dateibrowser ist nicht einfach ein Edit, wie es die Win-API
bereitstellt. Die Win-API stellt eher ein Kompatibilitätsmodus für alte
Programme bzw. Programme für alte Windosse bereit. Natürlich hat auch
das System mit seinen modernen Elementen seinen Anteil (Buttons,
Scrollbars, Dialoge etc.). Ein Großteil liegt aber am Programmierer. Ob
er eine klassische Menüleiste oder ein Ribbon verwendet. Ob er alle
Bedienelemente auf eine Seite klatscht oder dem Kontext anpasst usw.
usf.
Εrnst B. schrieb:> Alle? Nein. Ein von unbeugsamen Qooxdoianern bewohntes Framework hört> nicht auf, der Angularisierung des Web Widerstand zu leisten.>> Demo z.B.>> https://qooxdoo.org/qxl.demobrowser/#widget~Window.html
klingt interessant, nur was mich bisher von irgendwelchen web
Geschichten abgehalten hat, ist das ich nicht weiß wie ich damit (am
besten betriebssystemunabhängig) auf z.B. einen Comport zugreifen kann.
QT bringt da ja eine Serialklasse mit, wie geht das mit hmtl/css/js ...
?
nurmal so schrieb:> klingt interessant, nur was mich bisher von irgendwelchen web> Geschichten abgehalten hat, ist das ich nicht weiß wie ich damit (am> besten betriebssystemunabhängig) auf z.B. einen Comport zugreifen kann.> QT bringt da ja eine Serialklasse mit, wie geht das mit hmtl/css/js ...> ?
Du kannst den lokalen Webserver dahingehend modifizieren, dass du ihm
ein HTTP-Interface verpasst, welches als Proxy für die
Comport-Funktionalität dient.
Dann rufst du z.B.
auf um den Server anzuweisen, den entsprechenden Port zu öffnen.
Mit weiteren HTTP-Requests kannst du dann deine Daten an den Port-Proxy
senden und empfangene Daten abfragen:
1
http://localhost/comport/update/<NAME_DES_PORTS>
Noch schlauer wäre es aber, wenn man der HTML-GUI erst gar keine (auch
nicht indirekte) Kontrolle über den Comport gibt, sondern es nur zur
Darstellung nutzt. Den Comport öffnet und benutzt dann ausschließlich
der Server intern, ohne diese Funktionalität dem HTML-GUI als
Comport-API zu liefern. Der HTML/CSS/JS Teil dient dann nur als
Darstellung und die eigentliche Anwendungslogik läuft auf dem Server.
> das ich nicht weiß wie ich damit auf z.B. einen Comport zugreifen kann.> Du kannst den lokalen Webserver dahingehend modifizieren...
Ja, dies ist das wirklich zukunftsfähige Feature an den HTML5
Oberflächen:
Die schreibst eine Oberfläche, die überall läuft. Sowohl auf dem Display
deines Gerätes, als auch auf jedem Smartphone irgendwo auf der ganzen
Welt.
Die Frage, wie du auf einen Comport zugreifst ist vollkommen unabhängig
von der Oberfläche. Das macht der Server.
soweit so verstanden :)
gibt es irgendwo ein tutorial wie so ein lokaler Webserver aussehen
könnte? erst mal nur für Win und Linux wenn dann Android (ios wohl eher
nicht?) gehen würden um so besser.
irgend etwas ganz einfaches, comport, baudrate etc. auswählen connecten
und dann die empfangenen Daten in ein textfeld einfügen.
vielen dank
nurmal so schrieb:> gibt es irgendwo ein tutorial wie so ein lokaler Webserver aussehen> könnte?
Dir fehlen die Grundlagen, wenn du das schon nicht selber hinbekommst
dann lass es besser bleiben.
Tw schrieb:> Für das was ich bisher so an Abschlussarbeiten gesehen habe reicht auch> FLTK locker aus. Was macht deine Arbeit so besonders das es QT sein> muss?
Die Aussage, dass FLTK "locker" ausreicht, wird sicher richtig sein.
Aber: Qt ist nicht schwerer zu lernen als FLTK und bringt vieles mit,
was mit FLTK nicht geht. Außerdem schaden Qt und C++ Kenntnisse nicht im
Lebenslauf...
nurmal so schrieb:> gibt es irgendwo ein tutorial wie so ein lokaler Webserver aussehen> könnte?
In python sind das gerade mal drei Zeilen:
https://docs.python.org/3/library/http.server.html
Auch für C ist das Internet voll von Beispiele. Das Problem: So viele
Bespiele es gibt, so viele Security-Löcher sind auch vorhanden. Gerade
als Anfänger wird das nahezu unmöglich sein, alle Löcher zu stopfen!
Zwar kannst du eine einfache GUI mit HTML5 schnell zaubern, diese sieht
dann aber auch nicht gerade "schön" aus.
Wenn du eh eine Client-Server Architektur hast, kann man natürlich auch
über HTML5 nachdenken, aber ich denke, dass du als Anfänger mit Qt
deutlich schneller am Ziel bist. Ob du dir nennenswert Gedanken über das
Qt Lizenzmodell machen musst, kann ich nicht beurteilen, aber wenn du
evtl. für eine Firma arbeitest, könnte dies natürlich relevant werden.
Es hilft dir bei beiden Ansätzen ungemein, wenn du auf deinem SBC ein
vollwertiges Linux laufen lassen kannst. Prinzipiell gehen beide Ansätze
auch in Bare-Metall, dann kann es aber eklig werden bzw. du braucht
jemand mit viel Erfahrung. Gerade Qt kann hier problematisch werden, es
überhaupt zum laufen zu bekommen. Hier kann dann der HTML5 Ansatz
leichter werden, auf dem Server (=SBC) muss ja dann nur eine
Netzwerk-Stack laufen und der Client, der die GUI darstellt, ist dann
irgend ein Win/Linux-PC oder ein Android/iOS-Gerät.
Generaldirektor Heinrich Haffenloherich schrieb:> Dir fehlen die Grundlagen, wenn du das schon nicht selber hinbekommst> dann lass es besser bleiben.
Wie freundlich, da fragt man nach Tutorials um sich die Grundlagen zu
erarbeiten und man bekommt ein "lass es" zu hören ;)
2⁵ schrieb:> In python sind das gerade mal drei Zeilen:> https://docs.python.org/3/library/http.server.html
hmm, auf der Python Seite lacht mich gleich ein
"
Warning
http.server is not recommended for production. It only implements basic
security checks.
" an!
Bisher bin ich (übrigens nicht der TO und sorry für das teilweise Kapern
des Freds) gut mit QT, C# etc. gefahren, aber da immer wieder auf HTML5
(was ich bisher nur für statische Webseiten benutzt habe) verwiesen
wurde, wollte ich einfach mal wissen wie man dort an so etwas heran
geht.
Es kann erst mal hässlich ohne jedes CSS usw sein. es geht mir darum die
Technik zu verstehen.
Bei Webservern habe ich bisher immer eher an etwas wie Apache und Co.
gedacht.
also wenn ich das richtig verstehe habe ich einen lokalen Miniwebserver
der auch zugriff auf die HW hat und somit irgendwie an den comport kommt
(mittels python? java? php?). dann gibt es noch das frontend (gui in
html5 css3 js ...) welches die Darstellung übernimmt und per
http(s)://localhost auf den webserver zugreift?
ist es nicht möglich das backend auf einem "richtigen" Webserver laufen
zu lassen und der Client übergibt diesem dann die Daten des comports
(JS?) und bekommt dafür dann Informationen zum anzeigen zurück
geliefert. oder baut sich die Informationen (js?) selber zusammen.
ich möchte wirklich gerne in die Thematik einsteigen aber ich habe mehr
Fragezeichen als alles andere :D
bisher will sich mir Vorteil bei dem Ansatz mit html5 nicht so richtig
erschließen, eine Trennung zwischen gui (frontend) und Programmablauf
(backend, webserver) habe ich ja auch bei der "klassischen" Methode. und
der Webserver muss jeweils auf die Zielhardware angepasst werden. Die
Darstellung sollte dafür dann einigermaßen überall stimmen. Zumindest
bei der Verwendung eines halbwegs aktuellen Browsers.
ok ich könnte den ganzen Server mit den comports auf einem Rechner
laufen lassen und mir die gui dann auf einem anderen ansehen (wenn ich
denn den Webserver ins netz hängen kann/darf) aber ansonsten?
HTML macht Sinn wenn das Gerät den Webserver integriert hat, der HTML
Code + Resourcen können dann auch mehrere MB groß sein weil das ja 'nur'
erstmal an den Client geschickt werden muss. Ideal sind dann noch
Websockets, damit kann das Gerät dynamische Seiten anbieten. Der Client
bekommt einmal den Code wie Daten verarbeitet und dargestellt werden
sollen, das Gerät schiebt über die Websockets nur noch kontinuierlich
Daten nach.
Der TO wollte aber die Grafik auf dem SBC haben, da würde der Browser
auf dem Gerät laufen und muss auch das HTML rendern, und das ist gerade
beim HTML5 schon sehr anspruchsvoll.
weniger aufwändig ist lvgl, dafür läuft es auch auf µC. Es hat auch
schöne Widgets und ist auf einem z.B. STM32F769 auch schnell (trotz 32
Bit Farbtiefe und 800 x 480 Pixel Display). Siehe Anhang mit einer lvgl
Demo auf dem F769 Disco.
Auf der lvgl Seite im Blog ist auch ein Beitrag wie man es auf einem RPi
mit Framebuffer Ausgabe umsetzen kann.
Aber es braucht auch das was Steve mit dem iPhone eingeführt hat: mehr
Arbeit in UI/UX stecken. Buttons, Slider & Co. müssen auch ordentlich
bedienbar sein wenn es mit touch funktionieren soll.
Hallo Andreas.
Andreas schrieb:> Es sollte optisch schon zeitgemäß> aussehen (TKinter fällt raus).
Tkinter lässt sich mit etwas Mühe optisch pimpen.
Ist die Frage, was Dir vorschwebt.
Jedenfalls ist mehr drin als die Beispiele aus Lehrbüchern. ;O)
Tkinter hat den riesen Vorteil, dass es robust ist und auf so gut wie
jeder Plattform läuft, falls Du mal etwas portieren möchtest.
Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de
> gibt es irgendwo ein tutorial
Es ist zum Verzweifeln.
Wir haben 3 verfeindete Religionen. Qt bzw Smalltalk, HTML5 und die
Serverkonzepte. Nicht nur, das du kein umfassendes Tutorial findest, du
musst auch noch mehrere inkompatible IDEs gleichzeitig benutzen.
Der Opa aus der Muppet Show schrieb:> Es ist zum Verzweifeln.>> Wir haben 3 verfeindete Religionen. Qt bzw Smalltalk, HTML5 und die> Serverkonzepte.
Was hast du nur dauernd mit Smalltalk? Außer dir hat da keiner davon
gesprochen. Und sind "HTML5" und "die Serverkonzept" nicht ein und das
selbe? Also sprich: Es geht eigentlich nur um klassische GUI vs.
Webapplikation. Mit Religion hat das auch nicht viel zu tun.
Rolf M. schrieb:> Was hast du nur dauernd mit Smalltalk?
Aus Smalltalk kommt das Konzept, dass beliebige Event-Sender und
-Empfänger zur Laufzeit miteinander gekoppelt werden können. Das sind
die berühmten "Nachrichten an Objekte", so wie sie sich das Alan Kay
einst gedacht hat und mit Smalltalk umgesetzt hat. Das, was C++, Java
und all die anderen "Objektorientierten" Sprachen daraus gemacht haben,
ist nicht mal ein müdes Lächeln wert.
Qt greift dieses Konzept mit seinen Signals und Slots und dem moc-
Präprozessor auf. Es gibt auch noch andere Toolkits, die dieses Konzept
aufgenommen haben, teilweise dann später auch direkt in C++ mit den dann
vorhandenen Templates, die zur Einführung von Qt praktisch nicht
vorhanden waren.
> Außer dir hat da keiner davon gesprochen.
Tja, viele denken halt, wenn sie eine Programmiersprache oder ein
Toolkit "kennen", vulgo darin irgendwelche Programme zusammenbasteln die
der Compiler akzeptiert, sie würden sich auskennen.
Aber den meisten fehlt jegliches Wissen über die Geschichte der
verschiedenen Entwicklungen und den ganzen Zusammenhängen. Da reicht der
Horizont nicht weiter als zu den eigenen Zehenspitzen.
Bernd W. schrieb:> Tkinter lässt sich mit etwas Mühe optisch pimpen.> Ist die Frage, was Dir vorschwebt.
Man hört und liest es leider überall. Fast jeder ist von der alten Optik
von Tkinter abgeschreckt worden. Und die meisten wissen auch nicht dass
man ändern kann. Ich finde Tkinter braucht als default eine etwas
modernisierte Optik. Tkinter wirkt leider so als wäre es vor langer Zeit
im Grunde aufgegeben. Es ist nämlich nicht wirklich schwierig die Optik
zeitgemäß zu gestalten und neue Widgets mitzuliefern.
Wieso hat sich Tkinter nicht durchgesetzt? Das Konzept klingt doch ganz
überzeugend.
Wollen wir eine GUI solange umbauen, bis alle Benutzer sofort intuitiv
zurechtkommen, ist Python ideal. Genau deswegen hat sich in der KI die
Kombination aus C++ Kern und Python Anwendungslogik durchgesetzt.
Mit der alten MVC Architektur aus Smalltalk-Zeiten trennen wir sowieso
Oberfläche und Verarbeitung, können GUI und Verarbeitung auf
unterschiedlichen Maschinen in unterschiedlichen Sprachen laufen lassen.
Hätten wir Tkinter statt HTML5 Browser auf jedem Rechner und jedem
Smartphone, wir könnten die Programme in 1/10 der Zeit entwickeln.
Was ist da schief gelaufen?
Rolf M. schrieb:>> -> Es ist schade, aber aus meiner Sicht ist das Risiko beim Einsatz von>> Qt zu hoch. Aber: Your Mileage May Vary.>> Sofern du nicht LGPL bzw. bei den entsprechenden Komponenten GPL> akzeptieren kannst, ja.
Wobei man natürlich dazu sagen muß, daß die Risiken durchaus
überschaubar sind. Die meisten Menschen, die die GPL und die davon
abgeleiteten Lizenzen für ein Risiko halten oder sie anderweitig
kritisieren, haben sie nicht verstanden.
> Die Zahlen gelten übrigens pro Entwickler - jeder muss seine eigene> Lizenz haben und darf die nicht an andere übertragen. Hat man also ein> Entwicklungsteam mit 10 Mann, sind's bei der regulären Lizenz schon> 40k/Jahr. Die Small Business ist auf 4 Lizenzen pro Firma begrenzt.
Bei einem Entwicklungsteam von 10 Mann hat man allerdings schon
Personalkosten in Höhe von rund einer Million Euro und damit natürlich
auch einen dementsprechenden Umsatz. Wenn 40k pro Jahr bei einem
Unternehmen dieser Größe ein größeres Problem darstellen, hat das
Unternehmen ganz andere Probleme. ;-)
Andreas schrieb:> Hast du Erfahrung wie es mit der Performance auf ARM-Systemen,> speziell RPi, verhält?
So ein RasPi4 hat schon viel Dampf unter der Haube -- für Deinen
Anwendungsfall, den Du bisher beschrieben hast, hat er sehr viel mehr
als genug. Bei mir läuft ein RasPi4 mit einer kleinen Python-Anwendung,
die 720p-Bilder von einer Logitech C920 liest, eine Bewegungserkennung
mit OpenCV darauf macht und deren Ergebnisse serialisiert in einen
lokalen Redis-Server schreibt -- dabei schafft der RasPi4 tatsächlich 30
Frames pro Sekunde, ist dann allerdings auch auf allen vier Kernen
komplett ausgelastet und braucht einen großen, passiven Kühlkörper, um
nicht zu heiß zu werden und dann herunterzutakten. ;-)
Früher habe ich auch gerne und viel mit Qt gemacht, das Attribut
"zukunftsfähig" einer GUI bedeutet heutzutage meistens HTML5. Fat
Clients sind bei Kunden wegen des Aufwandes für Paketierung, Deployment
und Pflege nicht besonders beliebt, da sind eine oder wenige zentrale
Instanzen wesentlich preiswerter.
Eine Web-GUI hat einen weiteren riesigen Vorteil, nämlich, daß Du sehr
viele aufwändige Dinge wie zum Beispiel die grafische Visualisierung von
Daten sehr einfach und mit minimalem Aufwand "dezentralisieren" in einer
Art "poor man's distributed computing" auf den Clients machen kannst.
Dazu eine serverseitige Webapp, gerne auch mit Websockets zur
eventgetriggerten Ausleitung Deiner Daten an die Clients, ein bisschen
JavaScript dazu und der Drops ist gelutscht.
Zu diesen Vorzügen kommt zudem, daß es für so ziemlich jede moderne
Plattform einen Webbrowser gibt, so daß Deine Software sofort auf PCs
aller Art, Tablets, aber (wenn Du es richtig machst) sogar auf
Mobiltelefonen nutzbar ist.
Obendrein hast Du -- je nachdem, welche JS-Bibliothek(en) Du für die
Virtualisierung benutzt -- damit noch einen weiteren großen Vorteil,
nämlich den der Interaktivität. Mit passenden JS-Bibliotheken kann der
Benutzer in die Visualisierung hinein- und natürlich auch wieder
herausscrollen oder noch ein paar andere lustige Dinge machen.
Ein Beispiel von mir -- eine Visualisierung eines sehr alten Thread über
die Scores von "lesenswert" und "nicht lesenswert" -- findest Du im
Anhang dieses Beitrages. Bitte beachte, daß die Datei aus
Sicherheitsgründen zum Betrachten heruntergeladen und dann mit dem
Browser geöffnet werden muß, damit sie korrekt funktioniert. Oben
findest Du eine sortier- und durchsuchbare Tabelle, die mit Datatables
[1] erstellt wurde, unten drei interaktive Diagramme, die mit
pandas-bokeh [2] aus -- Du ahnst es -- einem Pandas-DataFrame [3] mit
Python generiert worden sind. Für einen schnellen Hack find' ich das
zwar noch nicht besonders ansehnlich, aber praktisch schon recht
brauchbar.
Diesen Vorteilen von HTML steht allerdings ein etwas höherer Aufwand für
eine (mehr oder weniger gründliche) Einarbeitung sowohl in HTML5, CSS
und JavaScript, sowie in eventuell zu verwendende Frameworks entgegen.
Leider sagst Du nicht so besonders viel zu Deinen Vorkenntnissen, auch
hinsichtlich Programmiersprachen, deswegen: HTH, YMMV, viel Spaß und
Erfolg!
[1] https://datatables.net/
[2] https://github.com/PatrikHlobil/Pandas-Bokeh
[3] https://pandas.pydata.org/
Sheeva P. schrieb:> Zu diesen Vorzügen kommt zudem, daß es für so ziemlich jede moderne> Plattform einen Webbrowser gibt
Ich halte diese "Technologie" für Schwachsinn.
Aber wenn es so toll ist, was folgt daraus? Dann brauchen wir keine
Betriebssysteme mehr. Ein Browser, in dem alles läuft, reicht doch.
> Ein Browser, in dem alles läuft, reicht doch.
Einen Browser, auf dem alles läuft, bezeichnen wir doch als
Client-Betriebssystem.
Die ursprünglichen Chromebooks hatten ja nur einen Browser für
Webapplikationen. Typische Antwort eines typischen Benutzers: "Was soll
ich denn mit einem Laptop, auf dem keine Adobe Programme laufen"?
> Diesen Vorteilen von HTML steht allerdings ein etwas höherer Aufwand für> eine ... Einarbeitung in HTML5, CSS, JavaScript, Frameworks ... entgegen.
Oje oje, oje... Seit 1980 gibt es bei den GUI Frameworks nur mehr
Rückschritte. Zwischendurch mussten wir uns nur in die Qt einarbeiten.
Heute in 4 Client-Technologien. 2 unterschiedliche REST Frameworks.
Mehrere inkompatible Server Frameworks. Und dazu noch unzählige
Automatismen, die angeblich die Build Prozesse vereinfachen sollen.
Der Opa aus der Muppet Show schrieb:> bezeichnen wir doch als> Client-Betriebssystem
Warum nicht einfach als Client?
Und hatten wir das nicht schon mal? Ein "Großrechner" + Zugriff per
Terminal darauf? ;-) Jetzt halt nur noch bunter.
So absurd.
wozu noch Betriebssysteme schrieb:> Aber wenn es so toll ist, was folgt daraus? Dann brauchen wir keine> Betriebssysteme mehr. Ein Browser, in dem alles läuft, reicht doch.
Ja, aber wenn man mal überlegt: Das ist doch gar kein schlechter Ansatz
für Service-Computer oder grafische Anzeigetafeln, z.B. am Bahnhof der
Fahrkartenautomat. Ein OS-Image, das nur die nötigen Komponenten für
einen Browser und Internetzugang enthält, wäre auch leichter
abzusichern, dank kleinerer Angriffsfläche. Man könnte die Seite, die
angezeigt werden soll, lokal oder auf einem entfernten Server
bereitstellen. Updates wären dann im letzteren Fall komplett
automatisiert.
Wer sowas allerdings für Desktop oder Smartphone-Anwendungen einsetzt,
hat IMO das Ziel etwas verfehlt, dafür ist der ganze Browser-Kram in
seiner jetzigen Form nicht so geil...
wozu noch Betriebssysteme schrieb:> Jetzt halt nur noch bunter.
etwas anders ist es heute schon, die Terminals waren dumm und konnten
nur Cursor positionieren und Zeichen anzeigen. Im HTML werden heute
komplette Programme im Quellcode an den Client geschickt und über die
vereinheitlichte (so die Theorie) HTML Engine dargestellt.
nurmal so schrieb:> Bisher bin ich (übrigens nicht der TO und sorry für das teilweise Kapern> des Freds) gut mit QT, C# etc. gefahren, aber da immer wieder auf HTML5> (was ich bisher nur für statische Webseiten benutzt habe) verwiesen> wurde, wollte ich einfach mal wissen wie man dort an so etwas heran> geht.> Es kann erst mal hässlich ohne jedes CSS usw sein. es geht mir darum die> Technik zu verstehen.>> Bei Webservern habe ich bisher immer eher an etwas wie Apache und Co.> gedacht.
... und das ist der Grund, warum Du schon mit der Terminologie auf
Deinem eigenen Schlauch stehst. Der "Webserver" ist tatsächlich ein
Webserver, Dein Programm ist hingegen ein Skript. Da das Skript ein
lokal laufendes Programm ist, kann es bei entsprechenden Berechtigungen
die konfigurierte(n) Schnittstelle(n) ganz normal benutzen, wie jedes
andere lokale Skript auch.
Das Skript muß dann natürlich via HTTP mit der Außenwelt kommunizieren,
und darum kümmert sich ein Webserver. Bei -- zum Beispiel -- einem
Skript in Python mit dem Flask-Framework gibt es da verschiedene
Möglichkeiten: den eingebauten Webserver, welcher in Python geschrieben
und nur für Entwicklungszwecke geeignet ist, oder in einem "richtigen"
Webserver wie den Apachen mit dem mod_wsgi-Modul, oder in einem
speziellen WSGI-Webserver wie gunicorn oder uwsgi -- wobei letztere
Lösungen gerne hinter einem klassischen Webserver wie Apache oder Nginx
benutzt werden, die dann als Reverse Proxy konfiguriert sind. Andere
Sprachen und Frameworks haben natürlich recht ähnliche Möglichkeiten.
Dein Beispiel mit dem Comport ist also ziemlich einfach: beim Starten
Deines Skript wird der Comport geöffnet und an das globale
Application-Objekt gebunden, das auch das Mapping von URLs auf
Funktionen und den Zugriff auf allerlei Ressourcen wie die
Konfiguration, Datenspeicher aller Art, ... you name it über
entsprechende Handles ermöglicht.
wozu noch Betriebssysteme schrieb:> Sheeva P. schrieb:>> Zu diesen Vorzügen kommt zudem, daß es für so ziemlich jede moderne>> Plattform einen Webbrowser gibt>> Ich halte diese "Technologie" für Schwachsinn.
Ich halte solche Aussagen für Schwachsinn.
> Aber wenn es so toll ist, was folgt daraus? Dann brauchen wir keine> Betriebssysteme mehr. Ein Browser, in dem alles läuft, reicht doch.
Ja, genau. Das ist genau das, was Sheeva vermutlich meint: Du brauchst
nur noch eine minimale Installation, die gerade ausreicht, um einen
Webrowser zu betreiben. Ein Träumchen für Systemadministratoren und alle
anderen Menschen, die die Ökonomie hinter der Entwicklung und dem
Betrieb von Software verstehen.
Nur_ein_Typ schrieb:> Ein Träumchen für Systemadministratoren und alle> anderen Menschen, die die Ökonomie hinter der Entwicklung und dem> Betrieb von Software verstehen.
Für mich als Anwender, der den Webbrowser ständig mit sich führt, ist es
ebenfalls ein Träumchen.
Florian S. schrieb:> Wer sowas allerdings für Desktop oder Smartphone-Anwendungen einsetzt,> hat IMO das Ziel etwas verfehlt, dafür ist der ganze Browser-Kram in> seiner jetzigen Form nicht so geil...
Mittlerweile werden ganze Office-Pakete als Webapplikationen angeboten,
allen voran Microsoft 365 und Google Docs... Wir können es drehen und
wenden, wir wir wollen: die klassischen GUIs sind auf dem absteigenden
Ast. Ich persönlich würde sogar sagen, sie haben bereits verloren.
Johannes S. schrieb:> Nur_ein_Typ schrieb:>> Ein Träumchen für Systemadministratoren und alle>> anderen Menschen, die die Ökonomie hinter der Entwicklung und dem>> Betrieb von Software verstehen.>> Für mich als Anwender, der den Webbrowser ständig mit sich führt, ist es> ebenfalls ein Träumchen.
Oh, stimmt, Du hast Recht: ich hatte die Anwender vergessen, obwohl ich
natürlich selbst auch einer davon bin. :-)
Nur_ein_Typ schrieb:> Ich halte solche Aussagen für Schwachsinn.
Nicht nur du! Darum haben wir jetzt auch überall Clouds, Server und
Clients.
Nur_ein_Typ schrieb:> Ein Träumchen für Systemadministratoren und alle> anderen Menschen, die die Ökonomie hinter der Entwicklung und dem> Betrieb von Software verstehen.
Tja, Ökonomie. Mehr brauchst du wohl nicht zu versehen - ich schon.
Ich will nicht eine Situation haben, wo meine Programme und Daten auf
irgendwelchen Servern liegen.
Nur_ein_Typ schrieb:> Ein Träumchen für Systemadministratoren
und für den Staat, Polizei und Geheimdienst. Alle Informationen werden
über irgendwelche Datenleitungen gesendet. Alle.
Nein, danke.
Nur_ein_Typ schrieb:> die klassischen GUIs sind auf dem absteigenden> Ast.
Wer braucht eigentlich GUIs?
Jedes Program, das man intensiv nutzt, wird doch früher oder später über
die Tastenkombinationen benutzt.
wenn man alle zwei Wochen seinen Editor vewchselt, dann braucht man
natürlich die Maus und eine GUI.
Es muss ja nicht alles in einem Browser laufen. Das klingt sowieso nach
Sicherheitsproblemen. Unzählige von Tabs sind außerdem übelst
unübersichtlich.
Warum nicht ein Betriebsystem das mehrere Ebenen von "Browsern" bzw. Web
Renderern bietet?
Zum surfen nutzt man den Browser mit sicherheitsrelevanten
Einschränkungen. Und Anwendungen die mehr erfordern werden in seperaten
Level x Browsern ausgeführt. Wie eine normale Desktop Anwendung mit
eigenem Fenster und mit einer Web Oberfläche.
Aber insgesamt klingen solche Ideen für mich künstlich. Wieso sollte die
Welt der Programmierung und Anwendungen auch nur aus Webtechnologie
bestehen? Das wäre doch irgendwie eine beeinträchtigte Vielfalt.
Die Anwender interessiert es sowieso nicht welche Technologie hinter
einer Anwendung arbeitet.
Ich denke die "alles im Browser" Idee ist bereits gescheitert. Glaube
dafür gibt es eher den Trend "alles im Smartphone" :D
> Nur_ein_Typ schrieb:>> Ich halte solche Aussagen für Schwachsinn.> Nicht nur du! Darum haben wir jetzt auch überall Clouds, Server und> Clients.
Server sind doch ne gute Sache, zumindest wenn es der eigene Server ist,
über den man auch Kontrolle hat.
> Ich will nicht eine Situation haben, wo meine Programme und Daten auf> irgendwelchen Servern liegen.
Das liegt rein an der Geldgeilheit und Paranoia von Unternehmen, mit
GUI-Technologie hat das eher wenig zu tun. Der Enabler für dieses
übergriffige Verhalten ist auch nicht der Browser oder HTML/CSS/JS,
sondern die ständige Verfügbarkeit einer Internetverbindung. Gibt jetzt
schon genug native Programme die ohne Internetverbindung keinen Mucks
machen.
wozu noch Betriebssysteme schrieb:> Nur_ein_Typ schrieb:>> Ich halte solche Aussagen für Schwachsinn.>> Nicht nur du! Darum haben wir jetzt auch überall Clouds, Server und> Clients.
Die haben wir, weil es schlicht und ergreifend einfacher, sinnvoller,
und ja, am Ende auch sinnvoller ist, Ressourcen zu teilen. Es ist
schlicht bescheuert, eine eigene Hardware nebst Stromversorgung,
Kühlung, Zugriffskontrollen und so weiter zu kaufen und zu unterhalten,
damit darauf einmal im Monat die Abrechnung laufen kann.
> Nur_ein_Typ schrieb:>> Ein Träumchen für Systemadministratoren und alle>> anderen Menschen, die die Ökonomie hinter der Entwicklung und dem>> Betrieb von Software verstehen.>> Tja, Ökonomie. Mehr brauchst du wohl nicht zu versehen - ich schon.
Du verstehst gar nichts, fürchte ich.
> Ich will nicht eine Situation haben, wo meine Programme und Daten auf> irgendwelchen Servern liegen.> [...]> und für den Staat, Polizei und Geheimdienst. Alle Informationen werden> über irgendwelche Datenleitungen gesendet. Alle.
Weil unser Staat und seine Organe wie Geheimdienste und Polizeien ja
bekanntlich überhaupt gar keine Möglichkeiten haben, sich offen oder
gegebenenfalls verdeckt Zugang zu Deinen Räumlichkeiten und Deine Daten
zu verschaffen, und wenn Du so große Paranoia davor hast, daß der Staat
Deine Daten sieht, wirst Du wohl Deine Gründe dafür haben. Obendrein
verstehst Du offensichtlich nicht, daß Deine Daten in einem
Rechenzentrum in Kapstadt, Sao Paulo, Mumbai, Singapur oder Bahrain vor
dem Zugriff unseres Staates wesentlich sicherer sind als auf Deiner
eigenen Infrastruktur -- und daß wir, wenn der Staat oder seine Organe
tatsächlich zu einer Gefahr für die Bürger werden, ganz andere Probleme
haben als Deine Daten, verstehst Du wohl auch nicht. Wenn das nämlich
der Fall wäre, würden sich die Betreffenden den Zugriff auf diese Daten
nämlich ohnehin schneller verschaffen, als Du "Huch" sagen kannst.
TkinterAberNatürlich schrieb:> Es muss ja nicht alles in einem Browser laufen. Das klingt sowieso nach> Sicherheitsproblemen.
Für mich nicht.
> Unzählige von Tabs sind außerdem übelst unübersichtlich.
Im klassischen GUI-Umfeld gibt es für sowas die sogenannten
MDI-Schnittstellen, und übersichtlicher sind die auch nicht. Bei meinen
Browsern kann ich wenigstens wählen ob ich ein neues Fenster oder einen
neuen Tab öffne, ob ich einen Tab in ein neues Fenster pinne oder in ein
eigenes Standalone-Fenster überführe. Dadurch kann ich mit dieser
Technik wesentlich mehr Übersicht erreichen als mit einem MDI-Singleton.
> Warum nicht ein Betriebsystem das mehrere Ebenen von "Browsern" bzw. Web> Renderern bietet?> Zum surfen nutzt man den Browser mit sicherheitsrelevanten> Einschränkungen. Und Anwendungen die mehr erfordern werden in seperaten> Level x Browsern ausgeführt. Wie eine normale Desktop Anwendung mit> eigenem Fenster und mit einer Web Oberfläche.
Für sicherheitsrelevante Bereiche geht das zumindest unter Linux
bereits. Einfach einen Browser mit dem gewünschten Sicherheitsprofil für
das bevorzugte Framework in einen Docker-Container packen, das hilft
schon.
Allerdings ist es aktuell so, daß die Technik selbst schon lange nicht
mehr das primäre Angriffsziel ist. Das ist vielmehr der Anwender, der
gerne mal auf alles klickt, das hinreichend bunt, zappelig und nicht
schnell genug auf dem Baum ist.
> Aber insgesamt klingen solche Ideen für mich künstlich. Wieso sollte die> Welt der Programmierung und Anwendungen auch nur aus Webtechnologie> bestehen? Das wäre doch irgendwie eine beeinträchtigte Vielfalt.
Weil das viele Dinge sehr viel einfacher und preiswerter macht.
> Die Anwender interessiert es sowieso nicht welche Technologie hinter> einer Anwendung arbeitet.
Ich kenne Deine Anwender ja nicht, aber meine wissen es sehr zu
schätzen, wenn eine Software stabil läuft, sie nicht ständig für
irgendwelche Updates rebooten müssen, sie dieselbe Software und
Konfiguration auf unterschiedlicher Hardware benutzen können und die
Kosten für Software, Anwendung und Betrieb niedrig sind.
> Ich denke die "alles im Browser" Idee ist bereits gescheitert.
Im Gegenteil: es fängt gerade erst an.
> Glaube dafür gibt es eher den Trend "alles im Smartphone" :D
Das Eine schließt das Andere nicht aus, sondern ein.
Nur_ein_Typ schrieb:> Es ist> schlicht bescheuert, eine eigene Hardware nebst Stromversorgung,> Kühlung, Zugriffskontrollen und so weiter zu kaufen und zu unterhalten,> damit darauf einmal im Monat die Abrechnung laufen kann.
Was für ein dummes Geschwätz.
Das Teuerste sind die Daten (private oder firmeninterne) und nicht die
Hardware.
wozu noch Betriebssysteme schrieb:> Was für ein dummes Geschwätz.
Dann sag' doch ausnahmsweise mal was Intelligentes. Vielleicht auch mal
etwas zum Thema des Threads, anstatt hier rumzutrollen.
> Das Teuerste sind die Daten (private oder firmeninterne) und nicht die> Hardware.
Schon wieder nichts verstanden. Es macht nämlich keinen Unterschied, ob
Du Deine Daten einem undurchsichtigen Programm oder Betriebssystem eines
mehr oder weniger dubiosen Herstellers, oder einem von ihm betriebenen
Server anvertraust.
So, jetzt aber wieder zurück zum Thema.
Nur_ein_Typ schrieb:> Für mich nicht.
Das ergibt sich einfach durch die vergrößerte Angriffsfläche. Denn ein
solcher Trend würde die sowieso schon komplex gewordenen Browser noch
umfangreicher machen.
Nur_ein_Typ schrieb:> Weil das viele Dinge sehr viel einfacher und preiswerter macht.
Inzwischen ist das relativiert. Durch die wachsende Komplexität der
Webentwicklung sind das heute komplexe Projekte mit vielen
Abhängigkeiten, verschiedenen Konzepten und build tools.
Einfach nur HTML oder CSS tippen ist an sich nicht schwierig. Aber
einfach C++ tippen ist auch nicht schwierig.
Frameworks wie Angular sind nicht trivial und bieten selbst für Leute
mit Vorerfahrungen eine steile Lernkurve die sich kaum von QT
Entwicklung unterscheidet.
TkinterAberNatürlich schrieb:> Nur_ein_Typ schrieb:>> Für mich nicht.>> Das ergibt sich einfach durch die vergrößerte Angriffsfläche. Denn ein> solcher Trend würde die sowieso schon komplex gewordenen Browser noch> umfangreicher machen.
Die letzten größeren Dinge, welche die Browser und Webprojekte komplexer
gemacht haben, waren allerdings ausgerechnet Funktionen zur Verbesserung
der Sicherheit wie HSTS, SOP und Co. Davor war es natürlich HTML5, aber
daß HTML weiterentwickelt wird ist ja nun wirklich nichts Neues, und das
gilt für GUI-Frameworks ja auch.
> Nur_ein_Typ schrieb:>> Weil das viele Dinge sehr viel einfacher und preiswerter macht.>> Inzwischen ist das relativiert. Durch die wachsende Komplexität der> Webentwicklung sind das heute komplexe Projekte mit vielen> Abhängigkeiten, verschiedenen Konzepten und build tools.> Einfach nur HTML oder CSS tippen ist an sich nicht schwierig. Aber> einfach C++ tippen ist auch nicht schwierig.> Frameworks wie Angular sind nicht trivial und bieten selbst für Leute> mit Vorerfahrungen eine steile Lernkurve die sich kaum von QT> Entwicklung unterscheidet.
Softwareentwicklung ist nun einmal komplex, da beißt die Maus keinen
Faden ab. Bei ernstzunehmender Software sind die Einarbeitungsaufwände
ins Tooling allerdings ein recht überschaubarer Posten, da geht es eher
um andere Themen. Allerdings: wenn die Lernkurven von Qt und Angular
ähnlich sind -- wobei ich ehrlicherweise sogar einen kleinen Vorteil bei
Qt sehe -- dann spielen die Kosten dafür keine Rolle mehr, weil sie in
beiden Fällen ähnlich sind und ich diese Kosten ohnehin berappen muß.
Zudem sind das ja weitestgehend einmalige Kosten, die sich über die Zeit
amortisieren.
Deswegen haben kluge Leute darüber nachgedacht, was denn so im Laufe der
Lebenszeit einer Software sonst noch so an Kosten anfällt, abgesehen von
der Beschaffung. Und, siehe da, denen ist aufgefallen, daß an
klassischen GUI-Programmen noch zusätzliche Kosten für das Deployment
und die Pflege anfallen. Und daß außerdem ja dann auch die
Clientmaschinen leistungsfähig genug sein müssen, um die betreffenden
GUI-Programme ausführen zu können -- und zwar sogar dann, wenn die
betroffenen Mitarbeiter diese Programme womöglich nur für eine Stunde im
Monat aktiv benutzen. Erinnert sich noch jemand an das Konzept der
"Total Cost Of Ownership", das ein bekannter Hersteller entwickeln ließ,
um die eigenen hohen Lizenzpreise verargumentieren und vor allem die
ungeliebten Wettbewerber aus dem OpenSource-Umfeld diskreditieren zu
können?
Nun, betrachten wir das doch einfach aus dieser Perspektive. Wenn die
Entwicklungs- und damit die Beschaffungskosten unabhängig davon sind, ob
es sich um eine GUI- oder um eine Websoftware handelt, egalisiert sich
diese Position und spielt für weitere Betrachtungen keine Rolle mehr.
Also können wir uns auf Vorzüge die und Nachteile von Web- gegenüber
GUI-Software konzentrieren, und zumindest in Unternehmen haben
Webapplikationen da in vielerlei Hinsicht die Nase weit, weit vorne. In
Deployment, Wartung, Lastverteilung, Testbarkeit, und eventuell auch bei
der Zugriffskontrolle und Auditierbarkeit hat Websoftware eindeutige
Vorteile.
Wie jemand anders hier ausnahmsweise richtig angemerkt hat, interessiert
es die Anwender nicht, mit welchem Technologiestack die Software
entwickelt wurde. Ja, haargenau. Und deswegen gibt es mittlerweile eben
auch Hybride wie das von mir bereits erwähnte Admin-Frontend pgAdmin4
für PostgreSQL, das als Webapplikation entwickelt wurde und sowohl
netzwerkweit zentralisiert über HTTP ausgerollt oder stattdessen mit
einem Webbrowser als lokale Installation genutzt werden kann. Und dieses
Konzept funktioniert so gut, daß ich zu behaupten wage: 99% der Leute,
die pgAdmin4 in einer lokalen Installation benutzen, merken nicht einmal
etwas davon, daß sie im Hintergrund mit einer Webapplikation arbeiten.
nurmal so schrieb:> gibt es irgendwo ein tutorial wie so ein lokaler Webserver aussehen> könnte? erst mal nur für Win und Linux wenn dann Android (ios wohl eher> nicht?) gehen würden um so besser.>> irgend etwas ganz einfaches, comport, baudrate etc. auswählen connecten> und dann die empfangenen Daten in ein textfeld einfügen.
Aus Spaß habe ich Dir da mal schnell was gehackt, das findest Du -- aus
Rücksicht auf den armen TO -- hier: [1]. Ich würde mich freuen, wenn die
weiteren Gespräche darüber in dem neuen Thread stattfinden könnten,
lieben Dank.
[1] Beitrag "Winzige Beispiel-Webapp mit Python und Flask"
Der Opa aus der Muppet Show schrieb:> Wir haben 3 verfeindete Religionen. Qt bzw Smalltalk, HTML5 und die> Serverkonzepte.
Verzeih' bitte, aber das ist ja Unfug. Qt ist nicht Smalltalk, auch
nicht mit dem Signals+Slots-Mechanismus, und HTML5 ist ein
Serverkonzept, das allerdings auch lokal benutzt werden kann.
TkinterAberNatürlich schrieb:> Fast jeder ist von der alten Optik von Tkinter abgeschreckt worden.
Das stimmt. Und daß Tkinter in Tutorials immer prozedural gezeigt wird:
1
root = tkinter.Tk()
2
button = tkinter.Button(root, ...)
3
button.pack(side=tkinter.LEFT)
4
# ...
5
root.mainloop()
anstelle von objektorientiertem:
1
class MainWin(tkinter.Tk):
2
def __init__(self, *args, **kwargs):
3
super().__init__(*args, **kwargs)
4
self.button = tkinter.Button(self, ...)
5
self.button.pack(side=tkinter.LEFT)
6
# ...
7
MainWin().mainloop()
(ungetestet aus der Hand) ist auch nicht sonderlich hilfreich und ärgert
mich jedes Mal, wenn ich es sehe... da rollen sich erfahrenen
Entwicklern doch die Fußnägel auf, verdammt!
wozu noch Betriebssysteme schrieb:> Der Opa aus der Muppet Show schrieb:>> bezeichnen wir doch als>> Client-Betriebssystem>> Und hatten wir das nicht schon mal? Ein "Großrechner" + Zugriff per> Terminal darauf? ;-) Jetzt halt nur noch bunter.
Ja, aber... damals hatten wir (wenn wir Glück hatten) 9600 Baud über
spezielle, schweineteure Kabel, und die gesamte "GUI" mußte darüber
transportiert werden.
Zwischenzeitlich hatten sich "Zwischenlösungen" etabliert, wie X11 und
Citrix, solches Gerümpel halt. Das ging, aber wirklich glücklich war
damit keiner.
Heute sieht das ein bisschen anders aus: Netzwerke sind überall billig
verfügbar, clientseitig gibt es Technologien wie Webbrowser, die einmal
die GUI übers Netz laden und dann nur noch Daten ziehen, eigene lokale
Speichermöglichkeiten haben und sogar Datenbanken, ... und wir haben
vielfach schnellere Rechner und Netze, mit so vielen neuen
Möglichkeiten...
Nur_ein_Typ schrieb:> wozu noch Betriebssysteme schrieb:>> Aber wenn es so toll ist, was folgt daraus? Dann brauchen wir keine>> Betriebssysteme mehr. Ein Browser, in dem alles läuft, reicht doch.>> Ja, genau. Das ist genau das, was Sheeva vermutlich meint: Du brauchst> nur noch eine minimale Installation, die gerade ausreicht, um einen> Webrowser zu betreiben.
Ja, aber ich meine nicht nur das. Betriebssysteme werden unwichtig(er),
das sehen wir ja auch schon im Serverumfeld mit CoreOS, Rancher und
Ubuntu Core. Da laufen nurmehr rudimentäre Linux-Systeme mit der
minimalen Ausstattung, um Container zu betreiben. Das wiederum führt zu
einer nahezu totalen Entkoppelung von Hardware und Software, aber damit
auch zu standardisierten Schnittstellen und somit dazu, daß
Betriebssystem, Browser, und der Rest... am Ende unwichtig und
austauschbar werden. Muß man nicht gut finden, ist aber so. ;-)
> einer nahezu totalen Entkoppelung von Hardware und Software, aber damit> auch zu standardisierten Schnittstellen und somit dazu, daß> Betriebssystem, Browser, und der Rest... am Ende unwichtig und> austauschbar werden. Muß man nicht gut finden, ist aber so. ;-)
Du erhoffst dir davon eine Vereinfachung deiner Programmieraufgaben weil
Systeme scheinbar ueberschaubarer werden. Das Problem ist nur das es
sehr schnell unterschiedliche Arten der Entkopplung in unterschiedlichen
Versionsstaenden geben wird. Einfach weil Menschen das machen koennen,
nicht weil es Sinn macht.
Eine Abstraktion komplexer Systeme scheint zunaechst sinnvoll weil sie
weniger intellektuelle Ressourcen zum Verstaendnis erfordert. Es ist nur
Bloed wenn Programmierer die dann freigewordenen Ressourcen sofort
nutzen um ihre abstrahierten System erneut komplexer zu machen. .-)
Olaf
Johannes S. schrieb:> wozu noch Betriebssysteme schrieb:>> Jetzt halt nur noch bunter.>> etwas anders ist es heute schon, die Terminals waren dumm und konnten> nur Cursor positionieren und Zeichen anzeigen. Im HTML werden heute> komplette Programme im Quellcode an den Client geschickt und über die> vereinheitlichte (so die Theorie) HTML Engine dargestellt.
Das funktioniert erstaunlich gut. Kann man sogar wiederum mit Qt machen.
Das heißt, da wird ein komplettes Qt-Programm inklusive der Qt selbst im
Browser ausgeführt. Das wird aber nicht als Quellcode, sondern als
Bytecode übertragen.
https://www.qt.io/qt-examples-for-webassembly
Olaf schrieb:> Du erhoffst dir davon eine Vereinfachung deiner Programmieraufgaben weil> Systeme scheinbar ueberschaubarer werden.
Nö. Ich sehe, was ich sehe. Was ich mir erhoffe, ist davon unberührt.
> Eine Abstraktion komplexer Systeme scheint zunaechst sinnvoll weil sie> weniger intellektuelle Ressourcen zum Verstaendnis erfordert.
Das ist aktuell sicher noch nicht der Fall, aber in ein paar Jahren...
> Es ist nur> Bloed wenn Programmierer die dann freigewordenen Ressourcen sofort> nutzen um ihre abstrahierten System erneut komplexer zu machen. .-)
Komplexer oder besser?
> Komplexer oder besser?
Fuer einen selber ist das zuerst immer besser. Fuer andere ist es
komplexer. Das geht solange bis dann irgendwann der Nachwuchs denkt: Oh
oh, das ist aber kompliziert, da schreibe ich lieber eine neue
Programmiersprache, GUI, usw...
Olaf
Komplexität wird eigentlich immer nur dann zum Problem wenn es nicht
umfassend dokumentiert ist.
Wie ich es hasse wenn bei umfangreichen Frameworks nur ein paar Code
Beispiele reichen sollen.
Man verliert dabei so viel Zeit undokumentierten oder schlecht
dokumentierten Code zu verstehen. Man könnte meinen die Entwickler haben
gar kein Interesse daran, dass andere ihre Software nutzen. Wollten wohl
nur öffentlich machen, dass es da was gibt, was sie selbst verstehen und
nutzen.
TkinterAberNatürlich schrieb:> Wie ich es hasse wenn bei umfangreichen Frameworks nur ein paar Code> Beispiele reichen sollen.
Und ich hasse es, wenn in das eine Beispiel gleich alle Bells&Whistles
des Frameworks reingefummelt werden ;)
Olaf schrieb:> Das Problem ist nur das es> sehr schnell unterschiedliche Arten der Entkopplung in unterschiedlichen> Versionsstaenden geben wird.
Überhaupt nicht. Die Schnittstelle der unterschiedlichen
Virtualisierungen ist im Backend z.B. Posix. Die Schnittstelle im
Frontend ist HTML inkl. DOM, WASM etc.
Noch nie konnten Anwendungen auf so unterschiedlichen Hardware- und
Softwareplattformen laufen. Man muss sich nur mal vergegenwärtigen, auf
was so eine HTML/WASM-App läuft: Desktops und Notebooks mit
unterschiedlichen Browsern, Betriebssystemen, Prozessorarchitekturen,
unterschiedlichste Mobil-Telefone, Tabletts, Fernseher, etc.
Thread beobachten
Seitenaufteilung abschalten