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
:
Verschoben durch Moderator
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Jeder Klon kann sich unabhängig von seinem Vatter/Mutter/Dotter weiterentwickeln...
:
Bearbeitet durch User
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 | Button btn; |
2 | |
3 | init() { |
4 | btn = new Button("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.
:
Bearbeitet durch User
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:
1 | Window
|
2 | {
|
3 | Rectangle
|
4 | {
|
5 | color: "red" |
6 | width: 0.5 * parent.width |
7 | height: 100 |
8 | Behavior on width { SpringAnimation { spring: 2; damping: 0.5 } } |
9 | }
|
10 | }
|
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.
:
Bearbeitet durch User
> 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.
> (TKinter fällt raus)
Merkwürdiger Ausdruck. Aber egal: mit TKinter wäre ich schon fertig.
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.
Der Opa aus der Muppet Show schrieb: > Allee HTML5 Frameworks ignorieren die Erfahrungen, die zur > Qt geführt haben. 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
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.
1 | http://localhost/comport/open/<NAME_DES_PORTS>&baud=<BAUD_RATE> |
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.
:
Bearbeitet durch User
> 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.
Noch was bzgl. HTML5: Schaue dir mal https://mikrocontroller.bplaced.net/wordpress/?page_id=399 und Beitrag "Webserver auf STM32F1 ?" an!
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.
Angehängte Dateien:
-
lvgl8-Demo-1.jpg
230 KB -
lvgl8-Demo-2.jpg
240 KB
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?
Der Opa aus der Muppet Show schrieb: > Was ist da schief gelaufen? Die Muppet-Show wurde eingestellt, bevor du die Welt retten konntest. Oliver
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.
Dieter H. schrieb: > Was spricht gegen C#? Ist die Frage ernst gemeint? > Ist halt nicht cross-plattform. Genau das.
> 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: > Mittlerweile werden ganze Office-Pakete als Webapplikationen angeboten Tja, warum wohl.
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: > Durch die wachsende Komplexität der > Webentwicklung das ist das nächste Problem. JS ist eine Pest.
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.
Guck mal wieder ein GUI Framework, von Ex Qt-Leuten: https://www.heise.de/news/SixtyFPS-Toolkit-aus-Berlin-fuer-grafische-UIs-mit-Rust-C-und-JavaScript-6170408.html
vom Autopoliturverkäufer @ Kirmes zum Rekrutah schrieb im Beitrag #6798561: > Guck mal wieder ein GUI Framework, von Ex Qt-Leuten: > https://www.heise.de/news/SixtyFPS-Toolkit-aus-Berlin-fuer-grafische-UIs-mit-Rust-C-und-JavaScript-6170408.html https://xkcd.com/927/
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
:
Bearbeitet durch User
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.