Announcement: there is an English version of this forum on HI Leute, ich bin eigentlich eher im Embedded Bereich unterwegs. Trotzdem muss ich hier und da mal ein paar rudimentäre GUI's am PC bauen. Jahrelang habe ich dazu einfach nur C#.NET (mit dem Sharp-Develop Editor) genommen. Da konnte man sich ja dynn Wysiwyg-typisch einfach mal paar Gui's mit den Control's zusammenklicken und ist in der Regel zu einem brauchbaren Ergebnis gekommen. Nur leider war die ganze Sache immer nur so richtig für Windows funktional. Lief nur begrenzt mit Mono dann z.B. auf Linux. Auf iOS/Android Tables lief das natürlich gar nicht. Ich habe den Eindruck dass sich da sehr viel getan hat die letzten Jahre und möchte mich mal auf was neues einlassen und wollte da mal nach euren Empfehlungen fragen Ein paar Items hätte ich aber: - Es sollte Multi-Plattform sein. Im Idealfall kann ich meine Software also dann für Windows, Linux, Mac, Android und iOS parallel bauen. Großer Bonus wenn das ganze zusätzlich in irgendeiner Form als Website rausfällt sodass man es gleich einfach im Browser anzeigen könnte (dann ist man komplett unabhängig) - Ich wäre dankbar, wenn es auf Syntax ähnlich C / C# oder Java/JavaScript aufbauen würde - Wysiwyg-Editor der eine Bibliothek an graphisch modernen und ansprechenden Control-Items mitbringt (idealerweise auch paar Beispiel-Projekte) - Es sollte Möglichkeiten geben über lokale Netzwerk-Interfaces z.B. TCP/UDP Verbindungen aufzubauen oder auch Serielle-Schnittstellen anzusprechen; insofern es keinen direkten Dateisystemzugriff (wie bei iOS) gibt zumindest dann die Möglichkeiten einer rudimentären isolierten Dateiverwaltung Was sind so eure Erfahrungen wo es sich da lohnt mal hinzuschauen? Danke!
Weder neu noch besonders schön, und auch nicht immer kostenlos ist da in dem Bereich schon immer Qt/QML unterwegs. Oliver
Embarcadero C++ Builder 11.x Kann das alles und erzeugt nativen Maschinencode. Kann C++ und Objectpascal. Ist als "Communityedition" kostenlos, wenn Du "kein" Geld damit verdienen willst. (max. 5000 $ im Jahr) Ich würd die 12.x Versionen dann auslassen, die können nämlich nur Windows und Python, Apple wollte es diesmal so. Die nächsten Versionen sollen dann wieder alles können. Arbeiten mit dem C++ Builder ist einfach. Klicke die GUI mit der Maus zusammen, indem Du die Gewünschten Komponenten ins Fenster ziehst. Lege die Eigeschaften fest und verbinde diese mit den Varialen / Funktionen Deines Programmes. Das geht sogar visuell, da wird dann ne Proxyklasse angelegt, die dann die Verbindung übernimmt. Lotta.
Markus W. schrieb: > Website rausfällt sodass man es gleich einfach im Browser anzeigen > könnte Das schreit doch förmlich nach einer Webanwendung in JavaScript. z.B. mit VueJS. Ja, WYSIWYG gibt es da nicht so wirklich, braucht man aber auch eigentlich nicht, weil es "im Code" so wunderbar einfach ist. Und weil es ja auch auf verschiedenen Geräten gehen soll (PC, Smartphone, Tablet) muss die GUI ja sowieso reaktiv sein und da ist der Vorteil von WYSIWYG auch eher dahin. Und es gibt natürlich eine Unmenge an Libraries da draußen mit allen erdenklichen Steuerelementen. Die sind auch sehr einfach per NPM eingebunden. Markus W. schrieb: > über lokale Netzwerk-Interfaces z.B. TCP/UDP Verbindungen aufzubauen Bei JS muss man da WebSockets oder HTTP nutzen, aber eventuell reicht das ja... Markus W. schrieb: > oder auch Serielle-Schnittstellen anzusprechen Geht tatsächlich direkt in JS Markus W. schrieb: > rudimentären isolierten Dateiverwaltung Da gäbe es localStorage und ein paar weitere APIs für den Datenzugriff, ist natürlich begrenzt. Der Vorteil von JS Webapps ist eben, dass der selbe Code so gut wie überall läuft, man muss sich nicht mit Installern für App und Framework rumschlagen (nur URL aufrufen), es gibt Unmengen an Libraries und Ressourcen, man kann die GUI sehr flexibel ansprechend gestalten, dafür geht damit nicht ganz so viel an Systemzugriffen.
Markus W. schrieb: > ein paar rudimentäre GUI's Markus W. schrieb: > mal paar Gui's mit den Control's Deppenapostrophe aller Orten. Siehe http://www.deppenapostroph.info Bitte keine Deppenapostrophe.
Wastl schrieb: > Deppenapostrophe aller Orten. Siehe > http://www.deppenapostroph.info > Bitte keine Deppenapostrophe. Viel nerviger als die Deppenapostrophe sind doch die Deppen, die die Apostrophe anderer noch hervorheben. Wird dir das nicht eigentlich irgendwann mal langweilig? Witzig war es schon beim ersten mal nicht.
J. T. schrieb: > Wastl schrieb: >> Deppenapostrophe aller Orten. Siehe >> http://www.deppenapostroph.info >> Bitte keine Deppenapostrophe. > > Viel nerviger als die Deppenapostrophe sind doch die Deppen, die die > Apostrophe anderer noch hervorheben. > > Wird dir das nicht eigentlich irgendwann mal langweilig? Witzig war es > schon beim ersten mal nicht. jaaa, dan laasen wia di rechtSchreibung doch Am bästen glaich gans wek.
Ich selbst habe es noch nicht probiert, aber C# mit der WPF kann die App auch im Browser laufen lassen. Ich mag WPF nicht sehr und brauche das auch nicht. Und Visual Studio Community ist auch kostenlos.
Qt ist zwar sehr mächtig und auch ganz brauchbar zu programmieren - aber wenn Dein Programm nicht OpenSource und GPL werden soll, dann lies Dir vorher unbedingt die Lizenzbedingungen von Qt genau durch. Für kommerzielle Entwicklungen langen die ordentlich zu. Und vor allem kannst Du die Qt-Lizenzen nicht dauerhaft kaufen. Du musst die ständig mieten solange Du in der Lage sein willst Dein Programm an andere weiterzugeben (=verkaufen, verschenken, Updates,...). Wie die Preise und Bedingungen für Qt in Zukunft aussehen weißt Du nicht. Das ist ein ziemliches Risiko wenn Du da viel Zeit reinsteckst und die Bedingungen irgendwann nicht mehr tragbar sind.
Gerd E. schrieb: > Qt ist zwar sehr mächtig und auch ganz brauchbar zu programmieren - aber > wenn Dein Programm nicht OpenSource und GPL werden soll, dann lies Dir > vorher unbedingt die Lizenzbedingungen von Qt genau durch. Kann man als Alternative dann vielleicht GTK und gtkmm für C++ in den Raum werfen? Oder wxWidgets oder FLTK, die sind ja alle nicht-kommerziell.
:
Bearbeitet durch User
Johannes F. schrieb: > Kann man als Alternative dann vielleicht GTK und gtkmm für C++ in den > Raum werfen? Oder wxWidgets oder FLTK, die sind ja alle > nicht-kommerziell. Sollte man auf jeden Fall mit in einen Vergleich einbeziehen. Ich würde sagen nicht ganz so bequem und mächtig wie Qt. Aber wenn man sich z.B. Kicad anschaut (wxWidgets) dann kann man da auf jeden Fall schon was mit erreichen. Ob das passt hängt denke ich von den individuellen Rahmenbedingungen und Prioritäten ab.
Also eine GUI, insbesondere eine portable, in C++ zu schreiben, finde ich stark überkompliziert, außer man hat ganz spezielle Anforderungen wie High Performance und 3D Beschleunigung oder so. Wenn schon eine "traditionelle" Sprache dann eine .net (C# etc) oder JVM basierte (Java, Kotlin, Scala...), die läuft dann wenigstens ohne neukompilieren. Aus der Matrix an Zielplattformen (Linux, Windows, Mac OS, iOS, Android) und Architekturen (i386, amd64, AArch32, AArch64, bald auch RISC-V) ergibt eine Menge Potenzial für unendlich viel Fummelei (BTDT).
:
Bearbeitet durch User
> Also eine GUI, insbesondere eine portable, in C++ zu schreiben, finde > ich stark überkompliziert, Du findest das rumschubsen von Buttons und anderen Elementen mit der Maus ueberkompliziert? Und wenn man aus dem Embedded Bereich kommt dann kann man bereits C/C++, da stellt sich IMHO die Frage nicht. Eventuell mit der Einschraenkung der oben angefuehrten Lizenzbedingungen. Vanye
Vanye R. schrieb: > Du findest das rumschubsen von Buttons und anderen Elementen mit der > Maus ueberkompliziert? Eine Anwendung besteht meist aus mehr als nur der blanken GUI. Das rumschubsen der Buttons ist 1% der Arbeit. Da kommt gern auch noch etwas an Datenstrukturen und Algorithmen dazu. Und wie gesagt, allein das Kompilieren und Deployment für die vielen Zielplattformen ist sehr viel Frickelei. Auch das Kompilieren/Verwalten der ganzen Libraries für die jeweiligen Plattformen; Qt oder Gtk alleine reicht ja selten, man braucht ja Libraries für alles mögliche. Der conan.io Paketverwalter ist eine große Hilfe dabei, aber es ist trotzdem sehr viel Arbeit. Bei JVM oder .net gibt es eine .jar oder .dll für alle Plattformen, fertig.
Erstmal danke an alle die mir geantwortet haben. QT habe ich mir angesehen - das mit der jährlichen Lizenz finde ich ehrlich gesagt schwierig. C++ Builder finde ich da aktuell am interessantesten. Das trifft auch von der Lizenz ganz brauchbar zu. Ich möchte ein Projekt erstmal hobbymäßig starten mit der Idee es später zu lizenzieren. Es geht quasi um eine Remote-Kontrolle von einem Embedded-System. Was ich bei einer potentiellen Webapplikation ganz interessant fände: man könnte einen Webserver direkt mit in die MCU/MPU whatever bauen und die Remote-Software quasi darüber dem Endnutzer zur Verfügung stellen - keine sonstige Software/App Installation. @Erlkönig: Kannst du mal genauer sagen wo ich da hinschauen sollte? Ich habe mal kurz gegoogelt aber es gibt gefühlt Millionen JS Bibliotheken für so etwas. Teilweise frei, teilweise zum lizenzieren etc.
Markus W. schrieb: > man könnte einen Webserver direkt mit in die MCU/MPU whatever bauen und > die Remote-Software quasi darüber dem Endnutzer zur Verfügung stellen - > keine sonstige Software/App Installation. Das würde doch perfekt passen, insbesondere brauchst du dann keinen PC, sondern nur ein beliebiges Endgerät mit Browser. Nicht umsonst machen viele Geräte das heutzutage so, DSL-Router ja schon lange - da hat niemand je eine GUI in C++ für implementiert und lokal auf dem PC installiert... Markus W. schrieb: > Kannst du mal genauer sagen wo ich da hinschauen sollte? Ich habe mal > kurz gegoogelt aber es gibt gefühlt Millionen JS Bibliotheken Ja da gibt es viel Auswahl. Am besten wühlst du dich durch die bekanntesten durch und schaust was dir am besten passt. Meines Wissens nach ist zB VueJS recht einfach zu bedienen ohne große Umstände, dafür aber weniger mächtig als zB Angular. Es gibt Unmengen an Tutorials zu diesen Dingen, zB von "Fireship" auf Youtube, schau zB mal: https://youtu.be/cuHDQhDhvPE
> Da kommt gern auch noch etwas > an Datenstrukturen und Algorithmen dazu. Selbstverstaendlich. Aber das eine unbekannte Anwendung beliebig komplex sein kann steht wohl ausser Frage. > Und wie gesagt, allein das > Kompilieren und Deployment für die vielen Zielplattformen ist sehr viel > Frickelei. Hm...einmal zwischen der Zielplattform umschalten, danach auf kompilieren klicken ist viel Frickelei? Gut ich nutze es nur fuer Linux, Windows und Android, aber da ist das umschalten Kinderkram. Was eventuell anspruchsvoll sein kann, das ist wenn die Zielplattformen stark unterschiedliche DPIs haben, oder auch nur standard/hochkant bei Android. Allerdings wenn man als Embeddedentwickler nur eine kleine Anwendung braucht im irgendwas zu testen/spiel/konfigueren ist man echt fix dabei. Natuerlich nachdem man gelernt hat damit umzugehen. Aber sicher immer noch viel einfacher als noch zusaetzlich so eine andere Sprache zu lernen, noch dazu eine die keine Klammern benutzt. Das wuerde mich echt abtoernen. .-) Externe Libaries, nun ja, die muss man schon zweimal uebersetzen, je nach Zielprozessor. Aber das braucht man ja auch nur selten mal. Ich bisher nur einmal fuer die MQTT Libarie weil sie die nicht einfach so mitliefern. Aber zweimal configure/make hab ich auch noch geschafft. Alles andere ging bisher einfach so... Vanye
Norbert schrieb: > jaaa, dan laasen wia di rechtSchreibung doch Am bästen glaich gans wek. DAS sage ich erstens mit keinem Wort, da ich dich aber trotz deiner verbesserungswürdigen Rechtschreibung verstanden habe, könnte man sich fragen, ob die wirklich so wichtig ist, wie ihr hier behauptet. Und zweitens tritt dieser Wastl nur in Erscheinung, wenn es Deppenapostrophen oder "dass das" oder Wiederstand anzumerken gibt, Sachlich hilfreiches hab ich von ihm schon lange nicht gesehen. Sind wir hier im Rechtschreibforum oder im Elektronikforum? Wenn man sonst nichts hat, um sich profilieren zu können, nimmt man halt die Rechtschreibung, mein lieber Scholli kannst du aber toll schreiben, du bist ein gaaanz wertvolles Mitglied der Gesellschaft.
:
Bearbeitet durch User
Vanye R. schrieb: > Hm...einmal zwischen der Zielplattform umschalten, danach auf > kompilieren klicken ist viel Frickelei? Gut ich nutze es nur fuer Linux, > Windows und Android, aber da ist das umschalten Kinderkram. Hast du schon mal andere Sprachen oder Frameworks genutzt? Wenn du ernsthaft behauptest C++ cross-platform Anwendungen sind "Kinderkram", dann lese ich da ehrlich gesagt raus dass du mit anderen Sprachen schlichtweg keine Erfahrung hast. Ich schreib selbst beruflich seit 8 Jahren C++ und so gern ich dieses alte Monster auch habe, so wenig würde ich es ohne wirklich guten Grund (z.B. bestehender Code) empfehlen. /edit Neben den von Niklas G. genannten Sprachen werfe ich noch Flutter/Dart in den Raum. Die Desktop-Unterstützung ist dort noch lange nicht so tief wie etwa bei Qt, aber je nach Anwendungsfalls ist das kein Beinbruch.
:
Bearbeitet durch User
Johannes F. schrieb: > Gerd E. schrieb: >> Qt ist zwar sehr mächtig und auch ganz brauchbar zu programmieren - aber >> wenn Dein Programm nicht OpenSource und GPL werden soll, dann lies Dir >> vorher unbedingt die Lizenzbedingungen von Qt genau durch. > > Kann man als Alternative dann vielleicht GTK und gtkmm für C++ in den > Raum werfen? Oder wxWidgets oder FLTK, die sind ja alle > nicht-kommerziell. QT ist LGPL oder GPL oder Proprietär/Abo. (Du wählst) GTK ist LGPL FLTK ist LGPL wxWidgets ist LGPL Bis auf ein paar Feinheiten in den LGPL-Versionen und hinzufgefügten Exceptions bist du mit der QT Lizenztechnisch weniger eingeschränkt als bei den genannten Alternativen. Hauptunterschied ist wohl: Wenn du auf die Lizenzbedingungen der GUI-Bibliothek schei***t, und kriminelle Raubmordkopiersoftware verkaufen willst, hat QT ein paar Anwälte, die dir auf die Füße treten. Die reinen Community-Projekte eher weniger.
Vanye R. schrieb: > Hm...einmal zwischen der Zielplattform umschalten, danach auf > kompilieren klicken ist viel Frickelei? Nein, aber das Einrichten des (C)MakeFile schon, um allen Befindlichkeiten der jeweiligen Plattformen, Architekturen, Libraries gerecht zu werden. Das dann noch in QtCreator einrichten damit man einigermaßen komfortabel umschalten kann ist auch umständlich. Vanye R. schrieb: > Was eventuell anspruchsvoll sein kann, das ist wenn die Zielplattformen > stark unterschiedliche DPIs haben DAS sollte das jeweilige GUI-Framework sowieso unbedingt abhandeln; wenn es das nicht tut, ist es das falsche Framework. Das native Android GUI-Framework tut das natürlich, und mit den gängigen JS-Frameworks geht es ebenso. Vanye R. schrieb: > immer noch viel einfacher als noch zusaetzlich so eine andere > Sprache zu lernen Markus spricht ja sogar von JavaScript... Vanye R. schrieb: > die muss man schon zweimal uebersetzen, je > nach Zielprozessor - Windows i386 - Windows amd64 - Windows AArch64 - Linux i386 - Linux amd64 - Linux AArch32 - Linux AArch64 - Linux RISC-V - Mac OS X amd64 - iOS AArch64 - Android AArch64 - Android amd64 (z.B. für den "Emulator", der in Wahrheit eine VM ist) - Android RISC-V (zukünftig) Hab ich welche vergessen...? MIPS & sonstige Architekturen die nur für Embedded-Systeme ohne GUI genutzt werden erstmal außen vor gelassen. Und das für alle Libraries und ihre drölfzig Abhängigkeiten. Ich hab z.B. mal eine Anwendung mit Pango implementiert, was einen kleinen Bruchteil der Abhängigkeiten vom GTK+ darstellt; das für 4 der o.g. Plattformen zu übersetzen war schon ein Kampf von mehreren Wochen der in so diversen Bugreports bei den jeweiligen Projekten gemündet ist. Das für alle o.g. Plattformen und alle Abhängigkeiten vom Gtk+ zu machen möchte ich mir nicht vorstellen. Außer natürlich das hat sich alles in den letzten paar Jahren dramatisch geändert, obwohl das Publikum für C++ GUI Entwicklung kontinuierlich schrumpft und obwohl die "native" Szene ziemlich verhaftet in gewissen Paradigmen ist. Das kann ich mir kaum vorstellen. Bei JVM/CLR-Sprachen muss man nur ein Mal übersetzen, und das haben die meisten Library-Autoren eh schon fertig, also effektiv muss man gar nix übersetzen. Bei JS ja sowieso nicht. Vanye R. schrieb: > Aber das braucht man ja auch nur selten mal. Ich > bisher nur einmal fuer die MQTT Libarie Man braucht ständig irgendwelche libraries für alles Mögliche, z.B. Datenformate & Protokolle die man definitiv nicht selber implementieren möchte. Rein zufällig haben .net und Java eine riesige Menge an Funktionalität in der Standardbibliothek, was bei C++ auch nicht der Fall ist.
:
Bearbeitet durch User
Markus meinte: > C++ Builder finde ich da aktuell am interessantesten. Das trifft auch > von der Lizenz ganz brauchbar zu. Ich möchte ein Projekt erstmal > hobbymäßig starten mit der Idee es später zu lizenzieren. Es geht quasi > um eine Remote-Kontrolle von einem Embedded-System. Wir haben die Architekt-Version zur Laborautomatisierung. Ziehe ne serielle Schnittstellenkomponente, ob gekauft, Shareware oder selbst programmiert ins Fenster, Stell im Objektinspektor Parameter und Protokoll ein verbinde Ein und Ausgabestream mit Deinem Code und es läuft. Es gibt 100 ternde Komponenten, Du dast die VCL, Firemonkey Boost und alles zum Proggen zur Verfügung. Embarcadero hat dazu nen Appstore. Und bei Win64x dann alles, was dem COFF Standard entspricht. mfg
Markus W. schrieb: > ich bin eigentlich eher im Embedded Bereich unterwegs. Trotzdem muss ich > hier und da mal ein paar rudimentäre GUI's am PC bauen. Seit vielen Jahren entwickle ich keine klassischen GUI-FatClients mehr, um Probleme wie jenes des TO in diesem Thread [1] von vorneherein zu vermeiden. Stattdessen entwickle ich nurmehr Webapps -- die können nicht nur auf einem Webserver (oder mit Docker, und mit entsprechenden Placement-Policies auch in einem Cluster wie Docker Swarm, Apache Mesos oder Kubernetes), sondern auch lokal laufen. Die Entwickler von PgAdmin4 haben das so gemacht: da läuft ein Webservice mit Python [2] und Flask [3], und wenn die Software lokal genutzt wird, startet ein rudimentärer Webbrowser ohne Addresszeile und Menüs etc., mit dem die Inhalte angezeigt und bedient werden. Python und Flask sind aus meiner Sicht eine hervorragende Wahl, allerdings erfüllt Python Deine Anforderung nach einer C-ähnlichen Syntax nicht. Aber dafür gibt es Golang, das nicht nur diese Anforderung erfüllt, sondern auch besonders gut für die Entwicklung von Webservices geeignet ist. Golang hat außerdem auch noch einige andere Vorzüge, zum Beispiel, daß sich sehr leicht statische Standalone-Binaries (sogar mit eingebetteten Ressourcen und HTML-Templates) für die üblichen Verdächtigen auf gebräuchlichen Architekturen (siehe [4]) erzeugen lassen -- und das nur durch Setzen der Environment-Variablen GOOS und GOARCH. Gleichzetig bietet Golang die Typsicherheit und Performance einer kompilierten Sprache. Zur Demonstration habe ich eine kleine Applikation angehängt, im Zip-Archiv ist der Quellcode, die Datei "gdmo" ist für Linux und die Datei "gdmo.exe" ist für Windows, jeweils als statisch gelinkte Binaries für x86_64 (amd64), -- und zudem sind jeweils alle statischen Ressourcen (hier: JQuery [5], Simplegrid [6], Flot [7] und eine eigene CSS-Datei) eingebettet. Das Programm lauscht nach dem Start auf http://localhost:8000/ -- bei Bedarf kann das natürlich geändert werden, in der Datei main.go Zeile 31. [1] Beitrag "Windows Anwendung im Browser anzeigen lassen" [2] https://www.python.org/ [3] https://flask.palletsprojects.com/en/stable/ [4] https://gist.github.com/zfarbp/121a76d5a3fde562c3955a606a9d6fcc [5] https://jquery.com/ [6] https://simplegrid.io/ [7] https://www.flotcharts.org/
Für Windows, Linux und Mac kann ich dir Go empfehlen. Die Syntax ist so ähnlich wie in C. Die Sprache arbeitet jedoch mit Garbage Collector (kennst du vielleicht von Java oder C#). Der Go Compiler Kann Code für "fremde" Plattformen erzeugen, ohne dass man diese selbst vorliegen haben muss. Angeblich wird sogar Adroid unterstützt, das habe ich allerdings noch nicht ausprobiert. Ein Ansatz wie man einen Web-Browser für die GUI "missbraucht", findest du auf meiner Homepage http://stefanfrings.de/go_webserver/index.html > - Wysiwyg-Editor der eine Bibliothek an graphisch modernen und > ansprechenden Control-Items mitbringt (idealerweise auch paar > Beispiel-Projekte) Schau dir Qt Creator an. http://stefanfrings.de/qt_lernen/index.html
:
Bearbeitet durch User
Den Ansatz werden vielleicht nur wenige hier verstehen, aber: Nimm eine Spiele-Engine, z.B. Godot. ;) Kannst du auch mit C# benutzen wenn du willst.
Kaj G. schrieb: > Den Ansatz werden vielleicht nur wenige hier verstehen, aber: > Nimm eine Spiele-Engine, z.B. Godot. ;) Gerade wenn es nur wenige verstünden, wäre es doch besonders sinnvoll, Deine Empfehlung zu begründen -- etwa mit ihren spezifischen Vorzügen. :-)
Wenn es nicht unbedingt in C u.s.w. sein muss dann würde ich Purebasic nehmen. Es läuft auf Windows und Linux und erzeugt nur eine Datei, man braucht nichts weiter sonst. Die IDE und auch der GUI-Designer sind OK. Und der Preis völlig ok.
900ss schrieb: > dann würde ich Purebasic nehmen. > Es läuft auf Windows und Linux Ein bisschen knapp: Markus W. schrieb: > Im Idealfall kann ich meine Software > also dann für Windows, Linux, Mac, Android und iOS parallel bauen.
> Hast du schon mal andere Sprachen oder Frameworks genutzt? Wenn du > ernsthaft behauptest C++ cross-platform Anwendungen sind "Kinderkram", Was ist das denn fuer ein absurder Angriff? Ich benutze Qt jetzt seit mehr wie 20Jahren fuer das was der TO fordert: ich bin eigentlich eher im Embedded Bereich unterwegs. Trotzdem muss ich hier und da mal ein paar rudimentäre GUI's am PC bauen. Genau dafuer leistet es mir beste Dienste! >Nein, aber das Einrichten des (C)MakeFile schon, um allen >Befindlichkeiten der jeweiligen Plattformen, Architekturen, Libraries >gerecht zu werden. Das dann noch in QtCreator einrichten damit man >einigermaßen komfortabel umschalten kann ist auch umständlich. Kann es sein das du eine andere Sprache nutzt die zufaellig auch Qt heisst? Wenn ich ein neues Projekt aufsetze dann waehle ich die Toolchain durch anklicken aus und fertig. Die einzige Besonderheit die ich bei Android habe ich das ich noch den Manifestgenerator ausfuelle. > Hab ich welche vergessen...? MIPS & sonstige Architekturen die > nur für Embedded-Systeme ohne GUI genutzt werden erstmal > außen vor gelassen. Du hast nicht verstanden was der TO will. Er will nicht der allmaechtige Gott aller denkbaren Plattformen werden sondern Probleme fuer eine handvoll gaengiger Sachen loesen. Also das was ich damit auch mache. (siehe Zitat von oben) Vanye
Vanye R. schrieb: > Kann es sein das du eine andere Sprache nutzt die zufaellig auch Qt > heisst? Welche Sprache heißt Qt? Ich gehe von C++ aus. Vanye R. schrieb: > Wenn ich ein neues Projekt aufsetze dann waehle ich die Toolchain durch > anklicken aus und fertig Ja wenn du nur nackten Qt brauchst geht das so. Aber wann reicht das schon... Vanye R. schrieb: > sondern Probleme fuer eine handvoll gaengiger Sachen loesen Ich habe eine Handvoll gängiger Plattformen aufgezählt. Der TO hat von genau diesen Betriebssystemen gesprochen, und ich habe die gängigen Architekturen auf denen diese Systeme laufen aufgeführt.
Ich verwende gerne Python und tkinter. Das läuft als Skript auf jeder Plattform, für die es Python gibt. Einfache Programme wie auch lifeplots z.B. mit canvas und pyplot sind möglich. Zusätzlich hat man mit pyserial, python-can, ... halbwegs saubere Abstraktionspakete für das Interface mit der Wunschhardware, da ändern sich dann nur marginale Dinge von Plattform zu Plattform. Zur Not kann man auch Executables draus machen, wenn man unbedingt muss.
Franko S. schrieb: > Wo bleibt das Lazaruslager? Bei Lazarus artet es in Frickelei aus, wenn man da cross compilieren will. Ich habe das selbst schon mehrfach versucht von Windows aus eine Anwendung für Linux oder MacOS zu kompilieren, aber es hat leider nie richtig funktioniert. Wenn man dann alles runter lädt und versucht die Buildumgebung neu zu kompilieren, bricht er mittendrin irgendwo ab. Lange Rede kurzer Sinn: Das Konzept von Lazarus ist zwar vom Ansatz her gut, nur leider funktioniert es nicht wie erwartet. Das einzige was geht ist, wenn man den Quelltext nimmt und auf dem Zielsystem kompiliert. Funktioniert allerdings auch nur, wenn man im Quelltext nix OS-Spezifisches drin hat. Das einzige was funktioniert ist in der Tat der von Lotta vorgeschlagene C++ Builder bzw. das RAD-Studio, welches Delphi (Objectpascal) und den genannten C++ Builder enthält. RAD-Studio gibt es halt nur als 30 Tage Testversion. Den C++ Builder und Delphi gibt es als Community Edition mit unbegrenzter Laufzeit. Die damit erstellte SW darf man, wie von Lotta geschrieben, nicht geschäftlich nutzen, außer der Umsatz bleibt unter 5000$.
Ein T. schrieb: > wäre es doch besonders sinnvoll, > Deine Empfehlung zu begründen -- etwa mit ihren spezifischen Vorzügen Stimmt natürlich :) Vorzüge sind ja relativ und für jeden individuell. Was aus meiner Sicht dafür spricht, sich mal eine Game-Engine, hier Godot, anzuschauen: - Die Hauptaufgabe einer Game-Engine ist es, Dinge auf den Monitor zu malen und es gibt so unendlich viele Beispiele dafür. Es gibt Tutorials ausschließlich für GUI Design damit. - Godot ist open-source, MIT Lizenz - Godot ist absolut kostenfrei nutzbar. Auch für kommerzielle Projekte. Keine verstecken Kosten, Umsatzeinschränkungen oder Lizenzgedöns. - Compilieren für Linux, Windows, Mac, Android, iOS, Web ist einfach nur ein klick im Export Fenster. (Web Export für Godot-C#-Projekte ist broken in Godot 4.3, sollte aber mit der nächsten Version gefixt werden) - Sprachen: Godot kommt per default mit GDScript (sehr Python ähnlich), kann aber auch mit C++, C#, Rust und anderen Sachen genutzt werden. - Dokumentation ist gut - Editor ist schlank und schnell (der Texteditor ist eher so meh, ist aber kein Problem wenn man einen externen editor nutzt) - Bringt komponenten für Client/Server Netzwerkkommunikation mit (Multiplayer) - Wenn man die Möglichkeit nicht hat, bzw. es schwer/kompliziert umzusetzen ist, wird man es vermutlich oft nicht machen. Aber vielleicht möchte man ja, je nach Anwendung, hier und da einen coolen Effekt (audio oder visuel) haben, z.B. wenn Temperaturen überschritten werden, oder was auch immer. Mit einer Game-Engine überhaupt kein Problem. - Abfragen von Tastatur-Input oder der Mausposition ist super einfach - Für einige Sachen (z.B. Effekte) muss man oftmals nicht mal Code Schreiben, einfach ein paar Schieberegler bewegen, boom, fertig. - GUIs müssen nicht wie 1995 aussehen ;) Wie gesagt, sind alles keine K.O. Argumente und jeder hat seine eigenen Vorzüge. Ich finde Godot mitlerweile deutlich Angenehmer als Qt. Godot: https://godotengine.org/ Godot Docs: https://docs.godotengine.org/en/stable/ Godot UI Tutorial: https://docs.godotengine.org/en/stable/tutorials/ui/index.html
:
Bearbeitet durch User
Angehängte Dateien:
-
korad1.jpg
130 KB -
korad2.jpg
120 KB -
korad3.jpg
230 KB -
ThermoWood.jpg
240 KB
> Welche Sprache heißt Qt? Ich gehe von C++ aus. Naja, das ist im Prinzip richtig, aber wie du doch sicher weisst wurde Qt ein bisschen erweitert. Ausserdem wird es von den Anwendern manchmal auch mehr als C genutzt, denn als C++. :D > Ja wenn du nur nackten Qt brauchst geht das so. Aber wann reicht das > schon... Immer? Klar, man kann sich jetzt etwas herbeikonstruieren, aber ich bin so zufrieden. Nimm als Beispiel mal die kleine Anwendung im Anhang. Hab ich vor einigen Jahren mal schnell zusammengeschludert. Ich denke so eine Woche Feierabend programmieren plus noch 2-3Wochen ab und an mal eine Kleinigkeit verbessert. Vermutlich 100-1000x besser wie das was Korad im Original mitliefert und laeuft unter Linux und Windows. Einfach so klick-klick... Oder noch eine zweite Sache. Hab ich eigentlich nur mal schnell zusammengeklickt um ein neu geschriebendes Nixie Widget zu testen. Lauft unter Linux und auf meinem Handy unter Android. Ein Klick und es wird das passende Binaerfile/APK erzeugt. Dafuer hab ich die MQTT Librarie gebraucht die ich einmal fuer Linux und einmal fuer Android uebersetzt habe. War glaub ich so 1-2Tage Feierabendprogrammierung. Vanye
Harald K. schrieb: > Ein bisschen knapp: Die eierlegende Wollmilchsau, so wie gewünscht, ist halt noch nicht erfunden. Wo ist denn dein nicht so knapper Vorschlag? Außer wieder einfach einen zweifelhaften Kommentar abzugeben. Es gibt da noch B4X, kennt kaum keiner, weil sich meist Cxx Entwickler zieren (*), mal über den Tellerrand zu schauen (Basic ist halt pfui). https://www.b4x.com/ B4X suite supports more platforms than any other tools..... ANDROID | IOS | WINDOWS | MAC | LINUX | ARDUINO | RASPBERRY PI | ESP8266/ESP32 | AND MORE… Ist sehr gut. Und könnte schon fast die eierlegende Wollmilchsau sein. Und kostet, außer für die iOS-Entwicklung, nichts. Und ich bleibe dabei, für schnelle kleine GUIs (und auch deutlich mehr) ist Purebasic wirklich gut. Wenn man natürlich Mobil-Anwendungen abdecken möchte, ist es nicht geeignet. Aber ich halte den Wunsch des TOs für etwas überambitioniert. (*) Ich gehörte auch zu den Leuten die sich sträubten gegen Basic. Bis ich gezwungen wurde, ein großes Projekt in der Industrie (Produktion) damit zu realisieren. Ich weiß jetzt, dass Basic (heute) gut ist.
:
Bearbeitet durch User
Markus W. schrieb: > - Es sollte Multi-Plattform sein. Im Idealfall kann ich meine Software > - Ich wäre dankbar, wenn es auf Syntax ähnlich C / C# oder > Java/JavaScript aufbauen würde Hast du dir mal https://www.electronjs.org/ angesehen? Das wird z.B. von Visual Studio Code verwendet und das läuft auf Windows, Linux, MacOS und auch in WebPages. Das fühlt sich als Anwender in allen Umgebungen gut und flott an, was die Schwuppdizität angeht. Ob man dafür auch zusammenclickbare UIs bauen kann weiß ich nicht, ich habe electronjs nicht selbst als Entwickler verwendet. Michael
Vanye R. schrieb: > Ich denke so eine Woche Feierabend programmieren plus noch 2-3Wochen ab > und an mal eine Kleinigkeit verbessert Also genau wie bei Java, C#, JavaScript, aber musst immer noch mit mehreren Programmdateien rumhantieren. Vanye R. schrieb: > Ein Klick und es wird das passende Binaerfile/APK erzeugt. Das muss man dann noch manuell installieren, ein Zertifikat generieren, und der User muss überhaupt erstmal die Installation von fremden APKs erlauben. Bei einer Webapp muss man eine URL aufrufen (zB per QR-Code) und fertig. Vanye R. schrieb: > und einmal fuer Android uebersetzt habe Nur einmal? Funktioniert also nur auf einem Teil der Androids. Und Glück gehabt dass diese Library wohl keine Abhängigkeiten hat. Viele OpenSource Libraries sind überhaupt nicht auf crosscompilieren ausgelegt. Viele nutzen irgendwelche total exotischen Buildsysteme. Da muss man sich jedes mal individuell reinfuchsen um die Bugs zu fixen die das crosscompilieren verhindern. Deine GUIs sind auch reaktiv, ja? Die Korad GUI verschiebt sich automatisch sodass sie sowohl auf Smartphones als auch auf dem PC, mit unterschiedlichen DPIs, gut aussieht? 900ss schrieb: > Es gibt da noch B4X, kennt kaum keiner, weil sich meist Cxx Entwickler > zieren (*), mal über den Tellerrand zu schauen Das Ding generiert offenbar C oder Java Code. Dann zu behaupten: 900ss schrieb: > B4X suite supports more platforms than any other tools... Wenn man nichtmal einen Compiler hat, sondern nur einen Code-Generator, naja. Die Dokumentation der Sprache ist, naja, "minimalistisch". Die OOP Features sind so halb statisch, halb dynamisch typisiert? So wie Java ganz früher? Na dann möchte ich mir 900ss schrieb: > ein großes Projekt in der Industrie (Produktion) damit zu realisieren. Nicht so recht vorstellen wollen.
Niklas G. schrieb: > Bei einer Webapp muss man eine URL aufrufen (zB per QR-Code) > und fertig. Du hast eine "Kleinigkeit" unterschlagen. Für eine Webanwendung, die das Smartphone via URL aufrufen kann, braucht man einen Server.
:
Bearbeitet durch User
Sherlock 🕵🏽♂️ schrieb: > Für eine Webanwendung braucht man einen Webserver. Markus hatte sogar selbst schon die Intention, diesen direkt auf dem Embedded Gerät laufen zu lassen, also zB ESP32. Und man kann JS GUIs auch lokal laufen lassen, als PWA.
Niklas G. schrieb: > Das Ding generiert offenbar C oder Java Code. Und? Was ist daran zu kritisieren? Läuft unter der Haube. Bekommt man weder als Anwender noch als Entwickler mit. Niklas G. schrieb: > Wenn man nichtmal einen Compiler hat, sondern nur einen Code-Generator, > naja. siehe oben.... Laufzeit? Gähn.... vor 20 Jahren ein Argument. Heutige Anwendungen sind nicht langsam weil es z.B. interpretiert oder kein native Maschinencode erzeugt. Bei den Rechenleistungen sind Anwendungen heute langsam, weil das Design unterirdisch ist. Und OOP ist sicher gut, wird aber zu oft als das Heilmittel schlechthin verkauft. Und da kenne ich wenige, die das so beherrschen, dass es wirklich ein Heilmittel ist. Auch damit muss man gutes Design beherrschen. Dann geh mal suchen.... Niklas G. schrieb: > Nicht so recht vorstellen wollen. Ja, das mag sich der Vorstellung manch einem entziehen. Ich weiß halt, woran ich einige Jahre gearbeitet habe. Automatisierung einer großen mehrstöckigen Produktionshalle eines Weltkonzerns. Eines der grössten Parfüm und Aromenhersteller weltweit. Anbindung an verschiedene SPS-en (unter anderem Siemens), und die meisten mit unterschiedlichen Bussystemen zum PC hin. Das war schon vor längerer Zeit. Was andere sich nun vorstellen, ja das bleibt deren Vorstellung. Aber das driftet hier ab. Das war nicht die Frage ob diesem Faden.
900ss schrieb: > Und? Was ist daran zu kritisieren Das pompöse Marketing was andere schlecht macht, während man sich aber dennoch auf die anderen verlässt. Und natürlich dass man so immer nur den gemeinsamen Nenner der Zielsprachen unterstützen kann. zB kann man C++ nicht vernünftig nach C übersetzen weil es "mächtiger" ist. Basic scheint das nicht zu sein. 900ss schrieb: > Heutige Anwendungen sind nicht langsam weil es z.B. interpretiert oder > kein native Maschinencode erzeugt. Jau, daher ist es auch nicht so sinnvoll C zu generieren sondern könnte auch einfach direkt C#, Java, Javascript nutzen. 900ss schrieb: > Und OOP ist sicher gut, wird aber zu oft als das Heilmittel schlechthin > verkauft In den 90ern vielleicht. Dennoch hilft es enorm, eine komplexe Anwendung zu strukturieren. Wenn man kein OOP bietet, braucht man halt was anderes, zB funktionale Programmierung oder sogar die Kombination aus beidem. Was hat b4x als Ersatz? Alles prozedural zu machen ist doch sehr "*im* Tellerrand". Immerhin hat es Coroutines, aber die haben so ziemlich alle anderen außer C auch. 900ss schrieb: > Automatisierung einer großen mehrstöckigen Produktionshalle eines > Weltkonzerns. Und das war eine große Anwendung oder viele kleine? Wie viele Zeilen Code? Wie komplexe Datenstrukturen? Asynchrones IO und Abläufe? Hätte die Anwendung vielleicht von Metaprogrammierung profitiert? 900ss schrieb: > zum PC hin Wenn man sowieso nur eine Zielplattform hat, hätte man auch ein System nutzen können, was auf diese optimiert ist. zB C#.
Michael D. schrieb: > https://www.electronjs.org/ angesehen? Der Tiefpunkt der Diskussion ist erreicht.
Niklas G. schrieb: > Und das war eine große Anwendung oder viele kleine? Mehrere "große", je nach Aufgabenbereich. Die Firmen Datenbank im Hintegrund. Aber es ist alles relativ. Niklas G. schrieb: > Wenn man sowieso nur eine Zielplattform hat, hätte man auch ein System > nutzen können, was auf diese optimiert ist. zB C#. War noch nicht erfunden. Und sonst: man hätte, hätte hätte..... Hinterher sind alle schlauer, auch man selbst. Meistens aber die Leute, die nur die Lufttemperatur und Feuchte erhöhen, wenn sie reden und eigentlich keinen Einblick haben. Gehört hier aber nicht mehr her.
:
Bearbeitet durch User
Franko S. schrieb: > Der Tiefpunkt der Diskussion ist erreicht. Ohne Begründung leider nichts wert diese Aussage. Und wenn ich die Referenzen ansehe, kann es sooo schlecht nicht sein. Nein ich kenne es nicht. Du?
:
Bearbeitet durch User
900ss schrieb: > War noch nicht erfunden. B4J gibt es offenbar seit 2013. Da war C# schon 13 Jahre alt. 2009 hatte ich mit C# eine GUI-Anwendung für einen großen Energiekonzern geschrieben zur Auswertung von Messwerten. Das ging super.
Niklas G. schrieb: > In den 90ern vielleicht. Dennoch hilft es enorm, Nachtrag: Nein, auch heute noch. Und ja es kann helfen. Aber leider beherrschen das nur wenige, damit es wirklich hilft.
900ss schrieb: > Und ja es kann helfen. Aber leider beherrschen das nur wenige, damit es > wirklich hilft Naja, man kann mit OOP, genau wie allen anderen Paradigmen, Unfug treiben. Aber selbst eine simple "konservative" Anwendung von OOP hilft schon gewaltig bei der Code-Strukturierung. Nicht umsonst sind so gut wie alle GUI-Frameworks objektorientiert. Selbst der Linux Kernel ist objektorientiert umgesetzt, halt umständlich "zu Fuß" in C.
900ss schrieb: > Ohne Begründung leider nichts wert diese Aussage. Und wenn ich die > Referenzen ansehe, kann es sooo schlecht nicht sein. Nein ich kenne es > nicht. Du? ElectronJS verheiratet einfach eine Web-Applikation mit der Chrome-Renderengine. Lässt sich dann alles in einem Rutsch installieren, läuft lokal, und du musst bei der Web-App keine Rücksicht auf verschiedene Browser nehmen. Nachteile sind u.A. dass das Installationspaket riesig ist, enthält ja einen Chrome, und du eigentlich gefühlt alle drei Tage ein Sicherheits-Update für deine App veröffentlichen müsstest, jedes Mal wenn Chrome selber ein Update hat... Das genannte VSCode lässt sich übrigens von electron "entbundeln", und dann klassisch mit Webserver & Webbrowser benutzen: Michael D. schrieb: > Das wird z.B. von > Visual Studio Code verwendet und das läuft auf Windows, Linux, MacOS und > auch in WebPages. Genau das "in WebPages" ist keine Eigenschaft vom ElectronJS. Das wird einfach durch einen normalen Webbrowser ersetzt... Durch PWA ist ElectronJS für sehr viele Anwendungen überflüssig geworden. Offline-Fähige Web-Apps lassen sich inzwischen auch so realisieren, mit einem Bruchteil des Speicherbedarfs, automatischen Updates, direkt lauffähig am Desktop, Handy, Tablet usw.
Als Alternative zur Strukturierung mittels OOP fällt mir ein, wie Go es macht: a) Funktionen liegen in Packages (Verzeichnisse) und werden stets zusammen mit dem Namen des Packages aufgerufen
1 | zip.OpenReader("testdata/readme.zip") |
b) Strukturen können Funktionen haben, aber ohne weitere Komplexität wie z.B. Vererbung.
1 | a := person{name: "a", age: 25} |
2 | a.display() |
Beides reicht aus, um Programme mit mehreren zig tausend Zeilen Code vernünftig zu strukturieren. Wer die Komplexität von C++, Java, ... scheut, der findet vielleicht an Go Gefallen.
Εrnst B. schrieb: > ElectronJS verheiratet einfach Danke, damit kann ich was anfangen und verstehe was du meinst.
Niklas G. schrieb: > 900ss schrieb: >> Und ja es kann helfen. Aber leider beherrschen das nur wenige, damit es >> wirklich hilft > > Naja, man kann mit OOP, genau wie allen anderen Paradigmen, Unfug > treiben. Aber selbst eine simple "konservative" Anwendung von OOP hilft > schon gewaltig bei der Code-Strukturierung. Nicht umsonst sind so gut > wie alle GUI-Frameworks objektorientiert. Selbst der Linux Kernel ist > objektorientiert umgesetzt, halt umständlich "zu Fuß" in C. Ach? geht also sogar in C ;) Ich wollte den Linux-Kernel als Beispiel nicht bringen. Ich möchte garnichts gegen OOP sagen. Nur manchmal wird das zur Religion und das nervt mich.
900ss schrieb: > Ach? geht also sogar in C ;) Ja. Aber ist halt total umständlich. Besser geht es in einer Sprache, welche das explizit unterstützt. Wie Java, C++, C#, Python... 900ss schrieb: > manchmal wird das zur Religion "OOP ist böse" wird mit mehr religiösem Eifer propagiert als "OPP ist hilfreich"...
:
Bearbeitet durch User
> Markus hatte sogar selbst schon die Intention, diesen direkt auf dem > Embedded Gerät laufen zu lassen, also zB ESP32. Also die meisten meiner Embeddedsachen sollen mit Batterie moeglichst lange laufen oder haben aus anderen Gruenden kaum Energie. Beruflich hab ich gerade ausnahmsweise ein Geraet realisiert wo es wirklich eine Homepage auf dem Geraet gibt. Das ich uebermegakomplizierter Dreck der praktisch nur Nachteile hat. Das kostet von vorne bis hinten Geld und Resourcen. Aber Strom kommt ja aus der Steckdose oder? Vanye
Vanye R. schrieb: > Also die meisten meiner Embeddedsachen sollen mit Batterie moeglichst > lange laufen oder haben aus anderen Gruenden kaum Energie Wenn das Gerät also mit dem PC oder Smartphone kommunizieren kann aber dennoch nur sehr wenig Energie zur Verfügung hat, muss es wohl ein BLE Gerät sein. In diesem speziellen Fall kann man die Webapp auch auf einem beliebigen Webserver ablegen und dann als PWA lokal installieren.
Angehängte Dateien:
-
key.jpg
290 KB
Hier noch eine kleine Anwendung die ich auf meinem ebook laufen habe. Auch mit Qt schnell zusammengeschustert. Oh..und dasselbe hab ich auch auf meinem TV laufen. .-) Und jetzt komm nicht wieder an das ich fuer sowas banales einen fetten Browser installieren muss und einen Server und was noch fuer einen dummen Firlefanz bloss weil heute kaum noch einer programmieren kann oder will. Vaney
Vanye R. schrieb: > Und jetzt komm nicht wieder an das ich fuer sowas banales einen fetten > Browser installieren muss Da ist kein Browser vorinstalliert? Dafür musst du fettes Qt installieren, bzw es ist Teil der App. Vanye R. schrieb: > weil heute kaum noch einer programmieren kann > oder will. Na wenn du so toll programmieren kannst kriegst du das Design bestimmt auch noch besser hin und weißt dass Android Apps keine "Quit" Buttons brauchen. Und da sowieso beide Geräte Android sind hättest du es auch direkt in Kotlin machen können und die nativen Steuerelemente nutzen können die sich ins Design einfügen.
Wirf mal einen Blick auf "Xojo". Ist nicht kostenlos*, wenn es fertige eigenständige Apps compilieren soll, zum Lernen in der IDE aber schon. Die einthält auch einen komfortablen GUI-Builder. Events werden per Klick aktiviert oder ausgeblendet, erscheinen nicht als aufwändiges Code-Konstrukt á la "event listener" (Java, JS), sondern fertig gewrappt als OOP-Methode ... man muss sich dran gewöhnen, aber dann will man es nicht mehr anders. Ich jedenfalls. XOjo kann compilieren für Windows 32/64, MacOS Intel u. Silicon, Linux Intel und ARM (Raspi), sowie iOS und Android. Ein Compilat-Ordner enthält alles, was auf der jeweilgen Plattfprm nötig ist, keine weiteren Abhängigkeiten. Auf dem Zielsystem ist keine "Installation" erforderlich, es genügt die Ablage in einem geeigneten Ordner. Wenn man keine Systemfunktionen direkt aufruft, geht das Alles aus ein und dem selben Sourcecode. Einer meiner wichtigsten Punkte: Die GUI-Elemente haben wirklich den jeweiligen System-Stil und sehen nicht, wie oft bei Java-Programmen, aus wie "selbstgemalt" oder zuindest irgendwie fremd. *aus Promotion-Gründen war oder ist eine Version, die für Raspi compilieren kann, frei.
:
Bearbeitet durch User
Kaj G. schrieb: > Was aus meiner Sicht dafür spricht, sich mal eine Game-Engine, hier > Godot, anzuschauen: Lieben Dank für Deine schöne und sehr verständliche Argumentation! Allerdings hätte ich bei einer Game-Engine die Sorge, daß ich jedes Widget selbst bauen muß und es hinterher womöglich doch nicht so aussieht wie die Elemente einer gebräuchlichen Library wie Qt, WxWidgets, GTK und Ähnlichen. Dabei hast Du natürlich vollkommen Recht, daß nicht jede GUI aussehen muß wie in den späten Neunzigern. Allerdings ist meine Erfahrung aus der Usability-Perspektive, daß gewohnte Elemente mit gewohnter Funktionalität nicht nur unbedarften Nnutzern sehr dabei helfen, sich zurecht zu finden. Hinzu kommt, insbesondere für datenzentrierte Anwendungsfälle, daß es für die gebräuchlichen GUI-Libraries häufig noch eine Vielzahl vorhandener, getesteter und mitunter gut dokumentierter Zusätze gibt. Mir fallen da gerade zum Plotten von Daten zum Beispiel die Bibliotheken QCustomPlot und Qwt ein, und wer mehr Interaktivität will, könnte sogar Python-Libraries wie Seaborn, Bokeh, Plotly oder die gute alte Matplotlib verwenden und sie mit der QWebEngine einbinden. Klar, die Hauptfunktionalität einer Gameengine wie Godot ist es, Inhalte auf Bildschirme zu malen, insofern ließe sich das alles sicherlich noch irgendwie entwickeln und darstellen. Aber wenn ich einfach nur schnell eine kleine GUI für mein $Superduper-Gerät bauen möchte, will ich möglicherweise nicht damit beginnen, indem ich mir ein eigenes Plottingwidget schreibe. Das ist übrigens auch der Grund, warum ich mich der hier im Thread schon genannten Empfehlung für Python und Tkinter nicht anschließen mag, wenngleich ich die Kombination mitunter für kleine Dateneingaben nutze: eine GUI-Library, die keine Widgets für tabellarische Daten enthält... ja, es gibt Projekte wie tkintertable und tksheets, aber mit deren Benutzung würde ich mich und meine Applikation von diesen Projekten und der Lust ihrer Maintainer abhängig machen... Insofern finde ich Deinen Hinweis wirklich gut und glaube, er ist zumindest für Leute nützlich, die (auf die eine oder andere Weise) einmal andere Wege beschreiten möchten. Es kommt nunmal -- wie ja irgendwie immer -- auf einen konkreten Anwendungsfall an -- und je nach Anwendungsfall kann eine Antwort natürlich auch ganz unterschiedlich aussehen. Daher: dankeschön! > Wie gesagt, sind alles keine K.O. Argumente und jeder hat seine eigenen > Vorzüge. Ich finde Godot mitlerweile deutlich Angenehmer als Qt. Nunja, Qt ist allerdings auch -- so ehrlich muß man sein -- ein Monster und hat deswegen eine gewisse Einstiegshürde. Allerdings muß man ja nicht alles kennen, um Teile davon zu benutzen... :-)
Frank E. schrieb: > Wirf mal einen Blick auf "Xojo". Wieder so ein Exotenscheiss den keiner kennt. Warum soll man sich sowas ans Bein binden? Ist das hier ne Krankheit im Forum möglichst obskures Zeug zu verwenden? Da es auf Java aufsetzt kann man auch gleich das nehmen und hat weniger Ärger am Hals und spart noch Geld. So ein auf ekliges VB poliertes Java braucht kein Mensch, wer nutzt denn sowas überhaupt freiwillig und gibt noch Geld dafür aus?
Ein T. schrieb: > Nunja, Qt ist allerdings auch -- so ehrlich muß man sein -- ein Monster > und hat deswegen eine gewisse Einstiegshürde. Allerdings muß man ja > nicht alles kennen, um Teile davon zu benutzen... Eben. Ich finde die Einstiegshürde eher niedrig. Zum Beispiel http://stefanfrings.de/avr_io/serial_io.html#qtexample Das ist jetzt nur ein Fenster mit einem Button. Aber es zeigt, dass man mit 15 Minuten schon anfangen kann.
900ss schrieb: > Aber das driftet hier ab. Das stimmt. Nehmt Euch ein Zimm^W^Weinen eigenen Thread, danke.
Sherlock 🕵🏽♂️ schrieb: > Das ist jetzt nur ein Fenster mit einem Button. Aber es zeigt, dass man > mit 15 Minuten schon anfangen kann. Das zeigt eigentlich nur, dass du den Komplexitätsunterschied zwischen „Hello World!“ und nutzbaren Programmen in keinster Weise verstanden hast. Es stimmt schon, die Lernkurve bei Qt ist steil, wenn man was wirklich sinnvolles damit machen will. Oliver
> Na wenn du so toll programmieren kannst kriegst du das Design bestimmt > auch noch besser hin und weißt dass Android Apps keine "Quit" Buttons > brauchen. Ich mag Quit Buttons und sehe keinen Grund mich da von irgendjemanden bevormunden zu lassen. .-) Vanye
Franko S. schrieb: > Frank E. schrieb: >> Wirf mal einen Blick auf "Xojo". > Wieder so ein Exotenscheiss den keiner kennt. Warum soll man sich sowas > ans Bein binden? Ist das hier ne Krankheit im Forum möglichst obskures > Zeug zu verwenden? Da es auf Java aufsetzt kann man auch gleich das > nehmen und hat weniger Ärger am Hals und spart noch Geld. So ein auf > ekliges VB poliertes Java braucht kein Mensch, wer nutzt denn sowas > überhaupt freiwillig und gibt noch Geld dafür aus? Es steht dir völlig frei, Xojo nicht zu mögen, aber wenn du dich schon äusserst, sollte es auch Substanz haben. Xojo setzt NICHT auf Java auf (verwechselst du möglichereweise mit Processing). https://www.dev-insider.de/cross-plattform-programmierung-rad-tools-xojo-a-f7029fe1a6ec77b0fd3f1ee79ebf5f8f/
Franko S. schrieb: > Frank E. schrieb: >> Wirf mal einen Blick auf "Xojo". > Wieder so ein Exotenscheiss den keiner kennt. Warum soll man sich sowas > ans Bein binden? Das hieß früher REALbasic https://de.wikipedia.org/wiki/Xojo Eine der besonderen Eigenschaften war, daß es ziemlich kompatibel zu altem Visual Basic 6 war, und damit Entwicklern helfen konnte, die mit der (erheblichen) Umstellung auf VB.net nicht zurechtkamen. Franko S. schrieb: > Da es auf Java aufsetzt kann man auch gleich das > nehmen und hat weniger Ärger am Hals und spart noch Geld. Wie kommst Du auf diese interessante Idee?
Norbert schrieb: > jaaa, dan laasen wia di rechtSchreibung doch Am bästen glaich gans wek. https://www.fehler-haft.de/wissen/buchstabensalat.html zum Topic, die Frage stelle ich mir auch gerade. Früher (TM) gab es zu jedem Computer eine Programmiersprache mitgeliefert, von Commodore Basic, über apple Basic, PC1500 Basic. Heute Fehlanzeige ohne sich gleich einem Hersteller auszuliefern. Ich glaube ich muß python lernen.
:
Bearbeitet durch User
Joachim B. schrieb: > Heute Fehlanzeige ohne sich gleich einem Hersteller auszuliefern. Hä? Was magst Du meinen?
Joachim B. schrieb: > Früher (TM) gab es zu jedem Computer eine Programmiersprache > mitgeliefert, > von Commodore Basic, über apple Basic, PC1500 Basic. > Heute Fehlanzeige ohne sich gleich einem Hersteller auszuliefern. Wenn du das mitgelieferte Basic verwendet hattest, hingst du genau so an dessen Hersteller. Mitliefern macht heute auch wenig Sinn, denn wir können downloaden. Falls du mut "ausliefern" den Anneldezwang meinst: es gibt genug Alternativen ohne diesen.
:
Bearbeitet durch User
Zum Thema Webgui: Ich gehe davon aus, dass sich die Browser in ein paar Jahren weigern werden unverschlüsselte Verbindungen aufzubauen. Sie werden auch keine selbst-signierten Zertifikate mehr akzeptieren. Meine embedded Geräte sollen auch eigentlich nicht ins Internet, um sich irgendwelche Zertifikate upzudaten. Es gibt dafür Lösungsansätze und das liegt ja alles noch einige Jahre in der Zukunft, aber es bedeutet, dass man dann alle seine embedded Webserver Geschichten überarbeiten muss.
Markus K. schrieb: > Ich gehe davon aus, dass sich die Browser in ein paar Jahren weigern > werden unverschlüsselte Verbindungen aufzubauen. Ich nicht, denn das macht im lokalen Netz keinen Sinn. > Sie werden auch keine selbst-signierten > Zertifikate mehr akzeptieren. Damit würden sich die Entwickler selbst ausschließen, ebenso Tester. > es bedeutet, dass man dann alle seine embedded Webserver Geschichten überarbeiten muss. Einfach einen vernünftigen Browser installieren.
:
Bearbeitet durch User
Joachim B. schrieb: > Heute Fehlanzeige ohne sich gleich einem Hersteller auszuliefern. Zum Glück gibt es standardisierte Programmiersprachen. Standardkonforme Programme funktionieren dann mit konformen Compilern vieler verschiedener Hersteller. Zu diesen Programmiersprachen gehören C, C++, JavaScript (ECMAScript). Java eigentlich auch aber es gibt praktisch nur eine Implementation. Joachim B. schrieb: > Früher (TM) gab es zu jedem Computer eine Programmiersprache > mitgeliefert, Die meisten Desktop-Linuxe haben gleich mehrere dabei, wie Shell/Bash, Perl, Python, Tcl, viele auch C und C++. Weitere sind ruckzuck installiert. Windows hat immerhin den CMD-Interpreter und Powershell. Das Visual Studio kann man sich auch gratis dazu passend installieren.
Niklas G. schrieb: > Das Visual > Studio kann man sich auch gratis dazu passend installieren. nicht ohne Anmeldung, habe ich versucht! Niemand weiß was M$ hinterrücks von mir noch übermittelt
Sherlock 🕵🏽♂️ schrieb: > Markus K. schrieb: >> Ich gehe davon aus, dass sich die Browser in ein paar Jahren weigern >> werden unverschlüsselte Verbindungen aufzubauen. > > Ich nicht, denn das macht im lokalen Netz keinen Sinn. Bei Zero Trust Security geht man davon aus, dass es keine vertrauenswürdigen Netze gibt. Ich habe durchaus den Eindruck, dass größere Firmen in diese Richtung wollen. https://de.wikipedia.org/wiki/Zero_Trust_Security >> Sie werden auch keine selbst-signierten >> Zertifikate mehr akzeptieren. > > Damit würden sich die Entwickler selbst ausschließen, ebenso Tester. Man kann dem Browser eine eigene CA geben. Das funktioniert aber praktisch gesehen nur im eigenen Netz, weil sich die IT der Kunden natürlich weigern wird sowas zu installieren. Es ändert auch nichts an dem Problem, dass das embedded Gerät sich das Zertifikat auch irgendwie besorgen muss. Meine Geräte hängen üblicherweise am 2. Netzwerkadapter und haben nur zu meinem PC eine Verbindung. >> es bedeutet, dass man dann alle seine embedded Webserver Geschichten > überarbeiten muss. > > Einfach einen vernünftigen Browser installieren. Für die Entwicklung kann man sowas natürlich machen, aber wenn die Kunden sich einen speziellen Browser installieren müssen, dann führt man das Prinzip einer Webgui ja ad absurdum.
Joachim B. schrieb: > nicht ohne Anmeldung, habe ich versucht! Kurios, bei mir ist es ohne MS-Account installiert. Markus K. schrieb: > Ich gehe davon aus, dass sich die Browser in ein paar Jahren weigern > werden unverschlüsselte Verbindungen aufzubauen. Da es ja eine Unmenge an kommerziellen Geräten ohne SSL gibt, insbesondere z.B. DSL-Router, dürfte es da eine Menge Widerstand geben. Und obwohl ein DSL-Router eine Internetverbindung hat, kann er wohl kaum ein Zertifikat für "192.168.2.1" bekommen.
Niklas G. schrieb: > Kurios, bei mir ist es ohne MS-Account installiert. vielleicht hast du schon einen ohne es zu wissen? Ich sollte mich ja schon für den download anmelden!
Frank E. schrieb: > äusserst, sollte es auch Substanz haben. Xojo setzt NICHT auf Java auf > (verwechselst du möglichereweise mit Processing). Nein, B4X meinte ich.
Joachim B. schrieb: > nicht ohne Anmeldung, habe ich versucht! Das hier, oder ein anderes? https://visualstudio.microsoft.com/de/vs/community/
Markus K. schrieb: > Bei Zero Trust Security geht man davon aus, dass es keine > vertrauenswürdigen Netze gibt. Dann bittest du halt jemand anderen, es für dich herunter zu laden.
Sherlock 🕵🏽♂️ schrieb: > Dann bittest du halt jemand anderen, es für dich herunter zu laden. Dem musst Du dann aber vertrauen.
Franko S. schrieb: > ekliges VB poliertes Java braucht kein Mensch, wer nutzt denn sowas > überhaupt freiwillig und gibt noch Geld dafür aus? Franko S. schrieb: > Nein, B4X meinte ich. Auch Recherche muss man beherrschen. B4X kostet nur für iOS etwas. Ansonsten darf ja jeder gerne nutzen was er möchte. Hast dieses eklige VB schon benutzt, auch noch mit Java darunter? Nein? Aber wissen dass es "blöd" ist. Nur weil da Java drunter liegt. Wie ernst ist so etwas zu nehmen? Ich hab den Eindruck, da fehlt doch etwas Objektivität. Schade.
:
Bearbeitet durch User
900ss schrieb: > Nur weil da Java drunter liegt. So war das nicht gemeint. Java ist grundsätzlich in Ordnung und eine umfangreiche Programmiersprache. Da dann wiederum Basic drauf zu setzen ist kurios, warum nicht direkt Java nehmen, das kann immerhin vollwertiges OOP und es gibt eine gigantische Menge an Literatur, Tools, Frameworks dafür... Wird da eigentlich Java-Code generiert oder wenigstens direkt JVM-Bytecode?
:
Bearbeitet durch User
Sherlock 🕵🏽♂️ schrieb: > Ein T. schrieb: >> Nunja, Qt ist allerdings auch -- so ehrlich muß man sein -- ein Monster >> und hat deswegen eine gewisse Einstiegshürde. Allerdings muß man ja >> nicht alles kennen, um Teile davon zu benutzen... > > Eben. Ich finde die Einstiegshürde eher niedrig. Zum Beispiel > http://stefanfrings.de/avr_io/serial_io.html#qtexample > > Das ist jetzt nur ein Fenster mit einem Button. Aber es zeigt, dass man > mit 15 Minuten schon anfangen kann. Das kann man in 15 Minuten schreiben, wenn man bereits Erfahrungen mit der Entwicklung von Qt-Applikationen hat. Wer diese Erfahrung nicht hat, wird zweifellos ein wenig länger brauchen... und "COM3" fix vorzugeben, anstatt einen Auswahl- bzw. Konfigurationsdialog zur Verfügung zu stellen... :-)
900ss schrieb: > Nein? Aber wissen dass es "blöd" ist. Nur weil da Java drunter liegt. Nein, weil eckliges VB drübergepinselt wurde.
> So war das nicht gemeint. Java ist grundsätzlich in Ordnung und eine > umfangreiche Programmiersprache. Da dann wiederum Basic drauf zu setzen > ist kurios, warum nicht direkt Java nehmen, Aber warum dann nicht gleich C++. Java ist doch vermutlich nur eine Teilmenge davon. :-D Die Antwort ist natuerlich, jeder kann nur das was er kann und hat wenig Bock/Zeit daran etwas zu aendern. > und "COM3" fix vorzugeben, > anstatt einen Auswahl- bzw. Konfigurationsdialog zur Verfügung zu > stellen... :-) Ja, vor allem weil bei mir und vielen anderen da /dev/ttyUSB0 stehen koennte. .-) BTW: Das gehoert zu den wenigen Dingen die ich unter Qt speziell behandeln muss wenn etwas auf verschiedenen Betriebssystemen laufen soll. Gar nicht davon zu reden das z.b mein oben gezeigtes Programm zum steuern eines KA3005P sowas hier erwartet: (natuerlich automatisch vom Betriebssystem erzeugt) [vanye] ~: l /dev/korad lrwxrwxrwx. 1 root 7 23. Feb 03:32 /dev/korad -> ttyACM0 Vanye
Hans schrieb: > Franko S. schrieb: >> Wo bleibt das Lazaruslager? > Bei Lazarus artet es in Frickelei aus, wenn man da cross compilieren > will. Ich habe das selbst schon mehrfach versucht von Windows aus eine > Anwendung für Linux oder MacOS zu kompilieren, aber es hat leider nie > richtig funktioniert. Hm, also unter Linux zu Windows crosscompilieren funktioniert wunderbar (sowohl zu 32-als auch 64 bit Win). Das Einrichten dazu war mal tatsaechlich ziemliche Frickelei, funktioniert mittlerweile aber recht gut. > Das einzige was geht > ist, wenn man den Quelltext nimmt und auf dem Zielsystem kompiliert. > Funktioniert allerdings auch nur, wenn man im Quelltext nix > OS-Spezifisches drin hat. Das war bei mir mal eine Weile die Methode der Wahl, weil unkompliziert. OS spezifisches fange ich mit compiler direktiven ab.
Niklas G. schrieb: > Wird da eigentlich Java-Code generiert oder wenigstens direkt > JVM-Bytecode? Ersteres könnte besser sein, weil man dann von den zunehmend besseren Optimierungen des Java Compilers profitieren kann. Ich vermute mal, dass die Entwickler dieses Nieschenproduktes nicht so viel Hirnschmalz in den Optimizer stecken können, wie Oracle und die Java Community. Man Bedenke, daß das ursprünglich extrem lahmarschige Java inzwischen so nahe an C++ heran gekommen ist, daß die Performance-Unterschiede uninteressant geworden sind.
Ein T. schrieb: > und "COM3" fix vorzugeben, anstatt einen Auswahl- bzw. > Konfigurationsdialog zur Verfügung zu stellen... :-) Es ist halt ganz bewusst ein Minimal-Beispiel. Im Arduino Umfeld wird auch das Passwort vom Wlan üblicherweise hardcodiert. Es sind halt nur einfache Beispiele, keine fertigen Programme.
Vanye R. schrieb: > Aber warum dann nicht gleich C++. Java ist doch vermutlich nur eine > Teilmenge davon. :-D Java ist so konzipiert dass es jeder lernen kann weil es so simpel ist. C++ hingegen nicht. Und Java kompiliert nicht zu C++... Sherlock 🕵🏽♂️ schrieb: > Ersteres könnte besser sein, weil man dann von den zunehmend besseren > Optimierungen des Java Compilers profitieren kann Die Optimierungen stecken doch in der JVM, nicht im Compiler... Der Bytecode darf also ineffizient sein
Niklas G. schrieb: > Die Optimierungen stecken doch in der JVM, nicht im Compiler... Der Java Compiler optimiert auch vieles. Zum Beispiel werden einfache Getter und Setter inzwischen ge-inlined (keine Ahnung, wie man das grammatikalisch richtig schreibt).
:
Bearbeitet durch User
Vanye R. schrieb: >> Welche Sprache heißt Qt? Ich gehe von C++ aus. > > Naja, das ist im Prinzip richtig, aber wie du doch sicher weisst wurde > Qt ein bisschen erweitert. Ausserdem wird es von den Anwendern manchmal > auch mehr als C genutzt, denn als C++. :D Qt ist keine eigenständige Programmiersprache, sondern ein in C++ geschriebenes Framework, um plattformübergreifende grafische Oberflächen zu entwickeln.
> Qt ist keine eigenständige Programmiersprache, ... Ein kleines bisschen mehr als nur C++ ist es schon: https://en.wikipedia.org/wiki/Meta-object_System Vanye
Andreas B. schrieb: >> Das einzige was geht >> ist, wenn man den Quelltext nimmt und auf dem Zielsystem kompiliert. >> Funktioniert allerdings auch nur, wenn man im Quelltext nix >> OS-Spezifisches drin hat. > Das war bei mir mal eine Weile die Methode der Wahl, weil unkompliziert. > OS spezifisches fange ich mit compiler direktiven ab. Ja natürlich muß man OS-Spezifisches mit Compilerdirektiven abfangen. Das ist unter Delphi bzw. C++ Builder auch nicht anders. Allerdings ist es eben deutlich angenehmer, wenn das Crosscompilieren vernünftig funktioniert. Solange man nur für's aktuelle System compiliert, vergißt man die Direktiven gerne und dann muß man das zwangsläufig nachholen, was dann bei großen Projekten eher nicht trivial ist. Wie gesagt der Ansatz von Lazarus ist schon nicht schlecht, aber es hakt auch noch an vielen Stellen und da nehme ich dann doch lieber das Orginal. Da ich in dieser Richtung nur noch privat unterwegs bin, kann ich problemlos die CE Varianten nutzen, wenn es notwendig sein sollte eine plattformübergreifende GUI zu machen.
Sherlock 🕵🏽♂️ schrieb: > Es ist halt ganz bewusst ein Minimal-Beispiel. Im Arduino Umfeld wird > auch das Passwort vom Wlan üblicherweise hardcodiert. Es sind halt nur > einfache Beispiele, keine fertigen Programme. Das ist mir schon klar, allerdings halte ich es für etwas... fragwürdig, so ein Minimalbeispiel als Beispiel dafür zu benutzen, wie einfach Qt sei. :-)
Ein T. schrieb: > Das ist mir schon klar, allerdings halte ich es für etwas... fragwürdig, > so ein Minimalbeispiel als Beispiel dafür zu benutzen, wie einfach Qt > sei. :-) Ok. Eigentlich dient das Beispiel dazu, zu zeigen, wie man vom PC aus so ein externes I/O Modul ansteuert. Ich habe es hier in einem nicht ganz passenden Kontext missbraucht.
Franko S. schrieb: > Nein, weil eckliges VB drübergepinselt wurde 900ss schrieb: > weil sich meist Cxx Entwickler zieren (*), mal über den Tellerrand zu > schauen (Basic ist halt pfui). :)) Dann quäle dich weiter auch mit schlechten GUI-Designern. Außer QT, aber bis man das am laufen und einen Workflow hat. Mir macht das nichts dass sich viele zieren, ich bezeiche andere Sprachen und Entwicklungsumgebungen auch nicht als "eklig" o.ä., was für ein qualifizierter Begriff für eine Software. Da nimmt man solche Aussagen gleich viel ernster.
Hans schrieb: > Ja natürlich muß man OS-Spezifisches mit Compilerdirektiven abfangen Was meinst du mit Compiler Direktiven? Präprozessor-Verzweigungen à la "#ifdef WIN32"...?
> > weil sich meist Cxx Entwickler zieren (*), mal über den Tellerrand zu > > schauen (Basic ist halt pfui). > > :)) Ach wo, ich hab letzte Woche erst im beruflichem Umfeld "goto" in C++ benutzt und wurde nicht exkommuniziert. :-D > Dann quäle dich weiter auch mit schlechten GUI-Designern. Außer QT, aber > bis man das am laufen und einen Workflow hat. Also bei mir ist es jetzt schon eine Weile her das ich das gelernt habe, ich fand es aber relativ einfach. Das lag aber vermutlich daran das ich ein Buch gekauft habe und das durchgearbeitet habe. Irgendwie scheint man heute eher zu glauben das man nur etwas googlet, kopiert, zwei Youtubevideos und dann muss es gehen. Nein, so ist nicht. Ausserdem muss gerade bei Qt unterscheiden werden zwischen der Sprachkenntnis und dem Wissen um die Moeglichkeiten der bereitgestellten Klassen. Gerade zu Anfang habe ich sicher oftmals etwas programmiert das ich einfach fertig in QString haette finden koennen. Aber dadurch funktioniert ein Programm jetzt nicht schlechter. Und man muss auch nicht den kompletten Sprachumfang von C++ zu 100% drauf haben. Ich denke mal ausser Bjoern dem Ersten kann das sowieso niemand. :-D Vanye
900ss schrieb: > Dann quäle dich weiter auch mit schlechten GUI-Designern. Außer QT, aber > bis man das am laufen und einen Workflow hat. Wobei gerade bei Qt die paar Zeilen Code, die der GUI-Designer generiert, mit etwas Übung schneller von Hand geschrieben sind. Oliver
Hans schrieb: > Wie gesagt der Ansatz von Lazarus ist schon nicht schlecht, aber es hakt > auch noch an vielen Stellen und da nehme ich dann doch lieber das > Orginal. Da ich in dieser Richtung nur noch privat unterwegs bin, kann > ich problemlos die CE Varianten nutzen, wenn es notwendig sein sollte > eine plattformübergreifende GUI zu machen. Dann solltest Du aber schnell reagieren, um noch die 11.3 Version zu bekommen, da die 12 er Versionen nur C++ für Windowa können. Die CE -Versionen sind immer 1 Hauptversion vor den Bezahlversionen, und die neue Version 13 wird im September/Oktober 2025 herauskommen. Da die CE Lizenz 1 Jahr läuft hast Du dann bis 2026 Zeit und steigst dann auf die 13 er um wenn die 14 er 2026 herauskommt. mfg
Niklas G. schrieb: > Hans schrieb: >> Ja natürlich muß man OS-Spezifisches mit Compilerdirektiven abfangen > > Was meinst du mit Compiler Direktiven? Präprozessor-Verzweigungen à la > "#ifdef WIN32"...? ja, genau das
:
Bearbeitet durch User
Andreas B. schrieb: > Niklas G. schrieb: >> Hans schrieb: >>> Ja natürlich muß man OS-Spezifisches mit Compilerdirektiven abfangen >> >> Was meinst du mit Compiler Direktiven? Präprozessor-Verzweigungen à la >> "#ifdef WIN32"...? > > ja, genau das Damit meint man eher sowas wie #pragma , denn #ifdef sind Präprozessor-Anweisungen. Diese Fallunterscheidungen sollte man am Besten in einer Datei/Modul sammeln und dort die Spezifika abhandeln, und den ganzen Rest des Codes davon frei halten. Oder noch besser, man schreibt alles Windows-spezifische in eine Source-Datei, alles Unix-Spezifische in eine weiter etc. und lässt im Buildsystem nur die korrekte mit kompilieren, bzw. den korrekten Include-Pfad hinzufügen.
Harald K. schrieb: > Das hier, oder ein anderes? sorry laden konnte ich aber bei der Installation bekam ich Zweifel erst mal schon mit Bedingungen und was die möglicherweise alles an M$ übertragen wollen. Nee ich hasse die mittlerweile, vor allem seit sie von Kaufsoftware auf Abo umgestellt haben.
Joachim B. schrieb: > sorry laden konnte ich aber bei der Installation bekam ich Zweifel erst > mal schon mit Bedingungen und was die möglicherweise alles an M$ > übertragen wollen. Das klingt eher nach einem psychologischen Problem. Aber niemand und nichts zwingt Dich dazu, den Monsterbrocken "Visual Studio" zu verwenden. Wenn Du das .Net-Geraffel nutzen willst, sieht das anders aus. Aber das ist auch von Microsoft, da kann man auch Zweifel bekommen, wegen Bedingungen und was das alles an M$ übertragen können wollte. Wer einfach nur einen anständigen C- oder C++-Compiler haben will, sollte sich Clang/llvm ansehen.
Harald K. schrieb: > Wer einfach nur einen anständigen C- oder C++-Compiler haben will, > sollte sich Clang/llvm ansehen. Und sich den Embarcadero C++Builder, CE Edition holen, da ist er unter Anderem betriebsfertig eingebaut. ;-P mfg
Lotta . schrieb: > Embarcadero C++Builder Ich wusste garnicht, dass es den ehemals C++ Builder von Borland noch gibt. Ich habe auch einiges mit Ihm gemacht und er war damals ein sehr gutes Werkzeug. Wenn das immer noch so ist und man mit "Windows only" zurecht kommt, dann ist das bestimmt ein schönes Werkzeug, gerade auch für GUIs. Der Designer war damals sehr gut. Danke, das schaue ich mir mal an. Da ich inzwischen auf Linux umgestiegen bin, wird das leider nur ein ein mal über "den Tellerrand schauen" sein.
Windows, Android, iOS und macOS deckt Maui (https://learn.microsoft.com/de-de/dotnet/maui/what-is-maui) ab. Linux leider nicht, ist derzeit auch nicht geplant. Dafür kann man wie gewohnt Pakete aus nuget einbinden und es gibt auch viele kommerzielle Pakete dafür. Ich habe es nicht getestet, aber die Android-Version einer Maui App müsste man z.B. mit https://waydro.id/ auch unter Linux einsetzen können.
Niklas G. schrieb: > Was meinst du mit Compiler Direktiven? Präprozessor-Verzweigungen à la > "#ifdef WIN32"...? Bei Delphi gibt es keinen Präprozessor im Sinne von C/C++. Dort nennt sich das Compilerdirektiven und wird vom Compiler selbst verarbeitet. Die Syntax ist allerdings ähnlich. Dein Beispiel würde in Delphi so aussehen: {$IFDEF WIN32} ... {$ENDIF} Eine Übersicht was es da an Direktiven vom Compiler selbst gibt, wäre hier https://docwiki.embarcadero.com/RADStudio/Sydney/en/Conditional_compilation_(Delphi) zu finden. Es ist einem allerdings unbenommen eigene Direktiven zu definieren. Das geht dann mit {$DEFINE xxxx}.
Lotta . schrieb: > Dann solltest Du aber schnell reagieren, > um noch die 11.3 Version zu bekommen, da die 12 er Versionen > nur C++ für Windowa können. Ich denke das ich bezüglich Delphi ganz gut versorgt bin. Ich habe mehrere RAD-Studioversionen in der professionell Version und da ist alles dabei was ich brauche. C++ mache ich eher selten, wenn man mal von Arduino absieht. Ich bin schon meist mit Delphi, also Objectpascal, unterwegs und da kann man ja in aktuelleren Versionen auch cross compilieren. Allerdings ist auch der private Bedarf an cross compilierten Anwendungen eher gering. Mir reicht es meist aus, wenn der Kram unter Win läuft. Da nehme ich dann sogar am liebsten ein recht altes Delphi (Delphi 7). Wenn's wirklich mal was plattformübergreifendes sein soll, komme ich mit Python ganz gut zu recht - sich nicht professionell aber für meine Belange völlig ausreichen. Trotzdem Danke für den Hinweis - vielleicht denke ich ja auch noch mal drüber nach.
Niklas G. schrieb: > Damit meint man eher sowas wie #pragma , denn #ifdef sind > Präprozessor-Anweisungen. Diese Fallunterscheidungen sollte man am > Besten in einer Datei/Modul sammeln und dort die Spezifika abhandeln, > und den ganzen Rest des Codes davon frei halten. Oder noch besser, man > schreibt alles Windows-spezifische in eine Source-Datei, alles > Unix-Spezifische in eine weiter etc. und lässt im Buildsystem nur die > korrekte mit kompilieren, bzw. den korrekten Include-Pfad hinzufügen Nö, man generiert sich mit diesen Direktiven eine Includedatei, die man an passender Stelle in seinen Quelltext mit {$I <Includedatei>}. Alles in spezifischen Dateien unterbringen ist zumindest bei Delphi eher suboptimal undf bläht am Ende den Quelltext nur unnötig auf.
Markus W. schrieb: > C++ Builder finde ich da aktuell am interessantesten. Das trifft auch > von der Lizenz ganz brauchbar zu. Ich möchte ein Projekt erstmal > hobbymäßig starten mit der Idee es später zu lizenzieren. Es geht quasi > um eine Remote-Kontrolle von einem Embedded-System. pvbrowser/pvserver-Loesung schon gesehen? Fuer Prozessmonitoring aller Arten ist das ziemlich gut zu handhaben. Die Masken macht man mit einem RAD-Tool, compiliert den Code, legt ihn auf dem Linux-Backend ab, und hat nur den einen Browser fuer alle Geraete. Geht halt etwas ueber eine gewoehnliche GUI hinaus, aber man kann damit eine ganze Fabrik steuern und monitoren. Bei Embedded Geraeten, die die Resourcen fuer einen embedded pvserver nicht haben, muss man halt einen Proxy reinschleifen, der modbus, CAN, oder was auch immer spricht, oder schauen, wie man eine Beschreibungsdatei oder ein Property-basiertes Protocol im Target unterbringt. Ein Knackpunkt, der solche SCADA-Ansaetze moeglichst nach Prinzipien der "Selbstbeschreibung" effizient macht: Die Geraete sollen selber wissen, was sie koennen und das dem Client mitteilen. Man will nicht jedesmal, wenn ein Embedded-Register hinzukommt, die GUI updaten, und per Versionsabfragen sicherstellen, dass Anfragen nicht ins Leere laufen, weil der Target es nicht unterstuetzt.
Niklas G. schrieb: > Kurios, bei mir ist es ohne MS-Account installiert. Ja, die Installation klappt bei den VS2022 community editions noch ohne MS-Account. Auf Dauer sinnvoll benutzbar sind sie aber nicht mehr. Das war bei den 2019ern noch anders.
Auf die Gefahr mich wieder unbelirbt zu machen..wenn du wirklich 0 Stress mit Lizenzen haben willst nimm Lazaraus Pascal! Einfacher gehts nicht eine GUI zu erstellen und es gibt KEINERLEI Bedingungen, wenn du es kommerziell nutzen willst, die Pascal Community freut sich aber, wenn du Pascal unter Hilfe oder Info erwähnst, eine Pflicht ist das aber nicht Auch für android kann das Programm dann genutzt werden, ob auch Apple, weiß ich gerade nicht UPDATE: Oh, ich sehe gerade, Delphi ist auch schon im Gespräch
Stefan schrieb: > wenn du wirklich 0 > Stress mit Lizenzen haben willst nimm Lazaraus Pascal! > Einfacher gehts nicht eine GUI zu erstellen und es gibt KEINERLEI > Bedingungen Da machst du dir das etwas zu einfach. Die LCL-Komponenten stehen unter einer leicht modifizierten LGPL. D.H. dieselben Lizenzbedingungen wie bei Qt (wenn nicht gekauft), GTK usw. Die Modifikation der LGPL bezieht sich darauf, dass du statisch linken darfst. Kannst also einfacher ein All-in-One Binary ohne Installer verteilen, weil keine .dll/.so dazugepackt werden müssen. Kann ein großer Vorteil sein, ist aber weit von "KEINERLEI Bedingungen" entfernt.
genau formuliert zusammengefasst Also tatsächlich sehr frei, aber irgendwas ist halt immer;-) 1. Free Pascal Compiler (FPC) Lizenz Der Free Pascal Compiler (FPC) steht unter der GNU General Public License (GPL) mit einer speziellen Library Exception. Das bedeutet, dass du Programme, die du mit FPC kompilierst, ohne Einschränkungen kommerziell vertreiben kannst. Dein Code bleibt dein Eigentum und muss nicht als Open Source veröffentlicht werden. 2. Lazarus-Komponenten und LCL (Lazarus Component Library) Die Lazarus Component Library (LCL) steht unter der GNU Lesser General Public License (LGPL) mit einer Linking Exception. Das bedeutet, dass du Programme, die die LCL nutzen, kommerziell vertreiben kannst, ohne den Quellcode offenzulegen, solange die LCL nur als dynamische Bibliothek (z. B. .dll oder .so) eingebunden wird. Falls du die LCL statisch linkst, musst du entweder den Quellcode deines Programms veröffentlichen oder eine Möglichkeit anbieten, dass der Nutzer die LCL-Bibliotheken selbst ersetzen kann.
Stefan schrieb: > Die Lazarus Component Library (LCL) steht unter der GNU Lesser General > Public License (LGPL) mit einer Linking Exception. Ja. Stefan schrieb: > Falls du die LCL statisch linkst, musst du entweder > den Quellcode deines Programms veröffentlichen oder > eine Möglichkeit anbieten, dass der Nutzer die LCL-Bibliotheken selbst > ersetzen kann. Nein, denn genau deshalb ist die Linking Exception da. https://wiki.lazarus.freepascal.org/FPC_modified_LGPL Was bleibt, ist also das übliche Thema, dass man für die (L)GPL-Komponenten den Source Code mitliefern oder anbieten muss.
Den TExt hatte nicht ich verfasst, also die Zusammenfassung. Wo genau siehst du das, was du meinst? Das wäre mir komplett neu, ich kenne es so, wie in der Zusammenfassung Aus deinem Link Im grudne aber auch nicht so dramataisch, so oder so, bietet sich LAzaraus da an udn macht es einfacher als bei QT etc, und das ist doch erstmal was gutes:-) "Der Unterschied zur regulären LGPL besteht darin, dass sie nicht verlangt, dass Programme/Bibliotheken, die modifizierte LGPL-lizenzierte Software (wie RTL, FCL, LCL, ...) verwenden, vom Endbenutzer gegen neuere Versionen dieser modifizierten LGPL-Komponenten relinkbar sein müssen. In der Praxis bedeutet dies, dass Programme/Bibliotheken, die statisch auf diese unter der modifizierten LGPL lizenzierten Komponenten verlinken, weitergegeben werden können, ohne dass die Objektdateien, die den Rest des Programms/der Bibliothek ausmachen, zur Verfügung gestellt werden. Quellcode-Änderungen, die an den modifizierten LGPL-lizenzierten Komponenten selbst vorgenommen werden, müssen den Empfängern des Programms/der Bibliothek jedoch weiterhin zur Verfügung gestellt werden." Übersetzt mit DeepL.com (kostenlose Version)
Stefan schrieb: > Wo genau siehst du das, was du meinst? > Das wäre mir komplett neu "The difference with the regular LGPL is that it does not require programs/libraries using Modified LGPL licensed software (such as the RTL, FCL, LCL, ...) to be relinkable by the end user against newer versions of these Modified LGPL components. In practice, it means that programs/libraries that link statically to these Modified LGPL licensed components can be distributed without making available the object files that constitute the rest of the program/library." Stefan schrieb: > macht es einfacher als bei QT etc Wenn man statisch linken will, ja. Ansonsten macht es keinen Unterschied, solange man sich bei Qt auf die LGPL-Komponenten beschränkt.
Hallo, Hmmm, Respekt! Mal an alle OM's hier: Bei Delphi ist es ja so, das man die Fremd - Komponenten beim Umstieg auf eine Neue Version auch neu kompilieren muß, (oder updaten muß), weil sich in der VCL irgendwelche Kleinigkeiten geändert haben. (etwa von 11.0 zu 12.0) Ist das in Lazarus auch so? Kann ich die Delphi - Komponenten nach neukompiliering in Lazarus auch dort verwenden oder gibts da Schwierigkeiten mit der Kompatibltät? mfg
:
Bearbeitet durch User
Lotta . schrieb: > Bei Delphi ist es ja so, [...] > Schwierigkeiten mit der Kompatibltät? Das gehört in einen eigenen Thread, statt einen fremden zu hijacken.
Ein T. schrieb: > Lotta . schrieb: >> Bei Delphi ist es ja so, [...] >> Schwierigkeiten mit der Kompatibltät? > > Das gehört in einen eigenen Thread, statt einen fremden zu hijacken. Oh, sorry, mein Typ, kannst Du mir nochmal verzeihen? mfg
Der TO/TE also Markus W. hat sich hier auch noch gar nicht zurückgemeldet. Schade eigentlich.
Vielleicht war er ja von den Reaktionen abgeschreckt. Und jetzt bringt er sich aus Rache bei, wie man Windows-GUI-Anwendungen in x86_64-Assembler schreibt. Aus Rache!
Lotta . schrieb: > Bei Delphi ist es ja so, das man die Fremd - Komponenten > beim Umstieg auf eine Neue Version auch neu kompilieren > muß, (oder updaten muß), weil sich in der VCL irgendwelche > Kleinigkeiten geändert haben. (etwa von 11.0 zu 12.0) Das ist in Pascal schon immer so, daß man Units neu kompilieren muß, wenn der der Compiler geändert wird - es also einen neuen Compiler gibt. Solange man bei der gleichen Hauptrevision, z.B. 11.x bleibt ist i.d.R. kein Neucompilieren erforderlich, wechselt man aber zu 12.x dann schon. Solange man die Unit bzw. Komponente als Quelltext vorliegen hat ist das ja auch kein Problem. Ich verwende z.B. in meiner aktuellsten Delphiversion XE3 Komponenten die ursprünglich für Delphi 4 geschrieben wurden. Probleme gibt es nur ab Delphi 6, wo eine strikte Trennung zwischen Runtime und Designtime eingeführt wurde, bei Komponenten die Design- und Runtimeanteile enthalten. Da kommt es dann ab Delphi 6 zu dem allseits bekannten DESIGN-IDE Fehler. Mit viel Mühe läßt sich das aber beheben, aber das kann am Ende recht aufwändig werden. Ein weiter Punkt ist, wenn die Units/Komponenten nur im Binärformat vorliegen. Dann kann man sie nur mit der Kompilerhauptversion benutzen mit der sie kompiliert wurden. Das ist z.B. auch der Grund, warum ein sehr großes Projekt von mir immer noch mit Delphi 4 kompiliert werden muß - aber das nur am Rande. Lotta . schrieb: > Ist das in Lazarus auch so? > Kann ich die Delphi - Komponenten nach neukompiliering > in Lazarus auch dort verwenden oder gibts da > Schwierigkeiten mit der Kompatibltät? Units/Komponenten von Delphi im Binärformat kann man meines Wissens nicht so ohne weiteres in Lazarus benutzen. Man braucht die im Quelltext und kann sie dann für Lazarus compilieren. Speziell die grafischen Elemente, die in Delphi in der VCL definiert werden, müssen in die LCL (Lazarus) überführt werden, da sich beide unterscheiden. Die Konvertierung von VCL nach LCL macht Lazarus allerdings automatisch und es funktioniert auch meistens. Wenn die Kompilation der Delphikomponenten in Lazarus fehlerfrei durchläuft, dann kann man sie problemlos mit Lazarus benutzen.
Harald K. schrieb: > Vielleicht war er ja von den Reaktionen abgeschreckt. Und jetzt bringt > er sich aus Rache bei, wie man Windows-GUI-Anwendungen in > x86_64-Assembler schreibt. Aus Rache! Qt-Anwendung in Assembler! Windows-GUI-Anwendungen in Assembler sind kein Problem.
Zino schrieb: > Harald K. schrieb: >> Vielleicht war er ja von den Reaktionen abgeschreckt. Und jetzt bringt >> er sich aus Rache bei, wie man Windows-GUI-Anwendungen in >> x86_64-Assembler schreibt. Aus Rache! > > Qt-Anwendung in Assembler! Windows-GUI-Anwendungen in Assembler sind > kein Problem. Warum nicht? Ist doch Kindereinfach. Du brauchst nur Deinen Compiler auf ASM-Ausgabe umzustellen. ;-))) ;-P mfg
Gerd E. schrieb: > Qt ist zwar sehr mächtig und auch ganz brauchbar zu programmieren - aber > wenn Dein Programm nicht OpenSource und GPL werden soll, dann lies Dir > vorher unbedingt die Lizenzbedingungen von Qt genau durch. > > Für kommerzielle Entwicklungen langen die ordentlich zu. Und vor allem > kannst Du die Qt-Lizenzen nicht dauerhaft kaufen. Du musst die ständig > mieten solange Du in der Lage sein willst Dein Programm an andere > weiterzugeben (=verkaufen, verschenken, Updates,...). Wie die Preise und > Bedingungen für Qt in Zukunft aussehen weißt Du nicht. Das ist ein > ziemliches Risiko wenn Du da viel Zeit reinsteckst und die Bedingungen > irgendwann nicht mehr tragbar sind. Solange du nur die LGPL Komponenten verwendest kann man das auch kommerziell nutzen ohne eine Lizenz zu erwerben. Man muss eben nur aufpassen die dynamischen Bibliotheken machen und austauschbar halten. GPL heißt übrigens nicht, dass der Quellcode veröffentlicht werden muss. Man kann ihn auch auf Nachfrage bereitstellen. Im kommerziellen Umfeld will deine Anwendung sowieso niemand neu linken.
Gustav G. schrieb: > Man muss eben nur aufpassen die dynamischen Bibliotheken machen und > austauschbar halten. Statisches Linken geht bei der LGPL durchaus, in dem Fall musst Du halt von Deinem Code die Object Files (nicht den Source Code) bereitstellen, damit der User sich ein neues Binary mit modifizierten Libraries bauen kann. Gustav G. schrieb: > GPL heißt übrigens nicht, dass der Quellcode veröffentlicht werden muss. > Man kann ihn auch auf Nachfrage bereitstellen. Ja, allerdings darf ihn derjenige, der ihn erhält, dann nach Belieben zu den Bedingungen der GPL veröffentlichen. Gustav G. schrieb: > Im kommerziellen Umfeld will deine Anwendung sowieso niemand neu linken. Im kommerziellen Bereich kann es aber passieren, dass man von Mitbewerbern gelinkt wird. Dass der eigene Code plötzlich unter der GPL steht, wie es bei GPL-Libraries (nicht LGPL!) der Fall ist, ist je nach Geschäftsmodell eher hinderlich.
Hmmm schrieb: > Statisches Linken geht bei der LGPL durchaus, in dem Fall musst Du halt > von Deinem Code die Object Files (nicht den Source Code) bereitstellen, > damit der User sich ein neues Binary mit modifizierten Libraries bauen > kann. Wenn man dynamisch linkt muss man auch keine Quellen zur Verfügung stellen. Idealerweise reicht der Austausch der DLL oder so Datei. Hmmm schrieb: > Ja, allerdings darf ihn derjenige, der ihn erhält, dann nach Belieben zu > den Bedingungen der GPL veröffentlichen. Richtig deswegen schließe ich in meinen kommerziellen Projekten GPL Abhängigkeiten grundsätzlich aus. Hmmm schrieb: > Im kommerziellen Bereich kann es aber passieren, dass man von > Mitbewerbern gelinkt wird. Dass der eigene Code plötzlich unter der GPL > steht, wie es bei GPL-Libraries (nicht LGPL!) der Fall ist, ist je nach > Geschäftsmodell eher hinderlich. Das verstehe ich nicht. Wenn meine Anwendung LGPL Abhängigkeiten benutzt wird meine Anwendung dadurch weder LGPL noch GPL. Meine Anwendung kann bei LGPL kommerziell bleiben. Meine Aussage zielte darauf ab, dass es sehr selten ist, dass jemand die LGPL Komponenten einer kommerziellen Anwendung austauschen will. Ich schließe damit weiteren Support aus und das hilft enorm. Jeder hat die Freiheit das zu machen aber ich muss dann nicht mehr Support leisten für Murks anderer.
Gustav G. schrieb: > Wenn man dynamisch linkt muss man auch keine Quellen zur Verfügung > stellen. Idealerweise reicht der Austausch der DLL oder so Datei. Ich sprach davon, dass auch statisches Linken bei der LGPL durchaus geht, man muss dann eben die Object Files (NICHT den Source Code!) zur Verfügung stellen. Bei einem Single-EXE-Installer sind mitgelieferte DLLs z.B. unpraktisch. Was man natürlich immer zur Verfügung stellen muss, ist der Source Code der (L)GPL-Komponenten. Gustav G. schrieb: > Das verstehe ich nicht. Wenn meine Anwendung LGPL Abhängigkeiten benutzt > wird meine Anwendung dadurch weder LGPL noch GPL. Deshalb schrieb ich explizit "wie es bei GPL-Libraries (nicht LGPL!) der Fall ist", das bezog sich rein auf GPL-Libraries. Im Fall von Qt muss man deshalb aufpassen, keine solchen zu verwenden, z.B. Qt Graphs.
Hmmm schrieb: > Ich sprach davon, dass auch statisches Linken bei der LGPL durchaus > geht, man muss dann eben die Object Files (NICHT den Source Code!) zur > Verfügung stellen. Bei einem Single-EXE-Installer sind mitgelieferte > DLLs z.B. unpraktisch. > > Was man natürlich immer zur Verfügung stellen muss, ist der Source Code > der (L)GPL-Komponenten. Mitgelieferte DLLs mögen unpraktisch sein aber im Fall von Qt wird man dem Benutzer seiner Software kaum klar machen können, dass die Bitte noch extra installiert werden sollen. Daher alles schön mitliefern. Benutzer wollen sich nicht um Abhängigkeiten kümmer und Microsoft hat es bis zum heutigen Tage nicht geschafft mal eine Paketverwaltung einzuführen.
Gustav G. schrieb: > Mitgelieferte DLLs mögen unpraktisch sein aber im Fall von Qt wird man > dem Benutzer seiner Software kaum klar machen können, dass die Bitte > noch extra installiert werden sollen. Liest Du eigentlich immer nur die Hälfte von dem, was man schreibt? Wenn ich einen Installer (!) baue, den man sich irgendwo runterladen kann, sollte der tunlichst als Standalone-EXE laufen. Und wenn der z.B. eine GUI-Library braucht, sollte die dementsprechend statisch gelinkt sein. Die fertig installierte Anwendung darf natürlich gerne DLLs benutzen, um die kümmert sich ja der Installer.
:
Bearbeitet durch User
Hmmm schrieb: > Was man natürlich immer zur Verfügung stellen muss, ist der Source Code > der (L)GPL-Komponenten. Soweit ich weiß muss man die Sourcen von LGPL Bibliotheken nur zur Verfügung stellen, wenn man sie verändert hat.
Hmmm schrieb: > Wenn ich einen Installer (!) baue, den man sich irgendwo runterladen > kann, sollte der tunlichst als Standalone-EXE laufen. Und wenn der z.B. > eine GUI-Library braucht, sollte die dementsprechend statisch gelinkt > sein. In Windows sind MSI Pakete üblich. Der Installer dazu ist Bestandteil des Betriebssystems. Alle anderen Betriebssysteme handhaben das auch so. Die klassische Standalone-EXE weicht grob vom Standard ab. Im letzten Jahrtausend war das noch üblich, heute (seit Windows 95) ist es schlechter Stil.
Sherlock 🕵🏽♂️ schrieb: > Soweit ich weiß muss man die Sourcen von LGPL Bibliotheken nur zur > Verfügung stellen, wenn man sie verändert hat. Nein. Du musst genau die Version mitliefern (oder auf Anfrage zur Verfügung stellen), die Du verwendet hast. Sherlock 🕵🏽♂️ schrieb: > In Windows sind MSI Pakete üblich. Deshalb wird auch die meiste Software NICHT als MSI ausgeliefert, selbst bei Microsoft-Produkten siehst Du die MSI-Pakete erst unter der Haube. Sherlock 🕵🏽♂️ schrieb: > Die klassische Standalone-EXE weicht grob vom Standard ab. Nö, die Registry-Keys zum Hinterlegen eines eigenen Uninstallers sind offiziell dokumentiert, und genau die nutzen auch die Nicht-MSI-Installer.
Zino schrieb: > Qt-Anwendung in Assembler! Windows-GUI-Anwendungen in Assembler sind > kein Problem. Das ist tatsächlich so, liegt aber natürlich vor allem daran, dass die in Windows "eingebauten" GUI-Komponenten doch ziemlich überschaubar sind. Klar, selbst damit ließe sich für viele Fälle ein hinreichendes GUI bauen. Aber: selbst für diese Fälle und als bekennender Asm-Liebhaber tut man sich das im Normalfall doch eher nicht an, schon deshalb, weil die aufgerufenen oder aufrufenden Funktionen selber wiederum in C/C++ geschrieben sind und entsprechend "lame". Aber man könnte es immerhin, wenn man es wollte... Der Kornpichler kann es halt selber nicht und sieht sich deshalb gemüßigt, Leute herabzuwürdigen, die es können. Mit der (durch nichts bestätigten Attitüde, dass diese Leute das halt auch ohne zwingenden Grund machen würden...) Der Typ ist einfach ein C-Only-Freak, der mit Zähnen und Klauen seine kleine Welt nach oben und nach unten verteidigen muss. Der Honk ignoriert dabei, dass das Einbinden von Assemblercode grundsätzliches Feature jedes C-Compilers ist (und sein muss). Anders könnte der Compiler nämlich schlicht nicht funktionieren. Ist nämlich im Kern nur ein Makro-Assembler. Wenn auch mit übelst ausgeufertem Makro-Unterbau. Ist aber egal, so lange es funktioniert. Der Kornpichler wird halt nur auf die Schnauze fallen, wenn mal was nicht funktioniert. Manchmal (zugegebenermaßen eher sehr selten) haben Compiler nämlich Fehler. Der Kornpichler wird nicht in der Lage sein, diese zu detektieren oder gar zu berichtigen. Dazu muss man halt mehr als nur C können.
Oh, danke, der "C-Hater" hat mal wieder eine seiner Weisheitswürste in die Keramik abgeseilt. Sehr schön.
Sherlock 🕵🏽♂️ schrieb: > > Die klassische Standalone-EXE weicht grob vom Standard ab. Im letzten > Jahrtausend war das noch üblich, heute (seit Windows 95) ist es > schlechter Stil. Mit .NET Core 3.0 (2019) wurden SelfContained Apps (wieder) eingeführt. https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview?tabs=cli
Markus W. schrieb: > QT habe ich mir angesehen - das mit der jährlichen Lizenz finde ich > ehrlich gesagt schwierig. Qt ist gar nicht so schwierig wie hier immer getan werden - der größte Teil des Qt Framework ist LGPL und mit der LGPL hat man im kommerziellen Bereich keine Probleme. Du musst nur ein paar wenige Punkte beachten: - Du musst dynamisch linken (macht man bei Qt-Anwendungen aber sowieso fast immer) - Du musst deinen Usern erlauben die Qt-shared libraries gegen selbstgebaute zu ersetzen - Du musst den Sourcecode der Qt-Lizenz (NICHT deiner Anwendung!) zum Download anbieten - Du musst bei allen Qt-Modulen schauen, dass sie unter LGPL oder MIT stehen. Es gibt auch GPL-Module, da ist es komplexer! https://opensource.stackexchange.com/questions/8804/do-i-need-a-commercial-license-for-the-qt-framework
Torben H. schrieb: > Markus W. schrieb: >> QT habe ich mir angesehen - das mit der jährlichen Lizenz finde ich >> ehrlich gesagt schwierig. > > Qt ist gar nicht so schwierig wie hier immer getan werden - der größte > Teil des Qt Framework ist LGPL und mit der LGPL hat man im kommerziellen > Bereich keine Probleme. > > Du musst nur ein paar wenige Punkte beachten: > - Du musst dynamisch linken (macht man bei Qt-Anwendungen aber sowieso > fast immer) Du musst nicht dynamisch linken. Du musst nur: oben alles schon erklärt. > - Du musst deinen Usern erlauben die Qt-shared libraries gegen > selbstgebaute zu ersetzen Dynamisches Linken ist ein einfacher, aber nicht der einzige Weg, das zu tun. Wurde aber eigentlich oben alles schon mal erklärt. > - Du musst den Sourcecode der Qt-Lizenz (NICHT deiner Anwendung!) zum > Download anbieten Nein, es gibt mehrere Optionen, die im Prinzip auf diese drei Möglichkeiten rauslaufen: - Du lieferst den Quellcode gleich mit - Du bietest ihn zum Download an - Du legst deinem Programm ein Angebot bei, dass du auf Nachfrage den Quellcode zum Selbstkostenpreis verschickst > - Du musst bei allen Qt-Modulen schauen, dass sie unter LGPL oder MIT > stehen. Es gibt auch GPL-Module, da ist es komplexer! Komplexer ist es nicht. Sobald du ein GPL-Modul verwendest, gilt das obige nicht nur für das Modul, sondern für das komplette Programm.
Hier wird wieder groß und breit das Lizenz-Thema aufgerollt. Ist das denn für den TE überhaupt relevant? Markus W. schrieb: > Trotzdem muss ich > hier und da mal ein paar rudimentäre GUI's am PC bauen. Klingt eher nach Hobby-Gefrickel.
Da ich prinzipiell sehr wissbegierig und aufgeschlossen bin, hab ich mal ernsthaft versucht, mich mit QT vertraut zu machen und es unter MacOS zu installieren. Das "Gegenewicht" für den Vergleich war mein geliebtes "Xojo". Das hier ist zwar nicht der gleiche und passende Thread, aber ich hab mich auch mal für Free Pascal/Lazarus interessiert, deshalb können wir das hier gleich mit abarbeiten. Alleine die (aus meiner Sicht) völlig abstrusen Installations-Orgien (mit dem manuellen Zusammensuchen irgendwelcher Komponenten im Web uva.) haben mich beide Versuche nach ca. 30 min entnervt abbrechen lassen. Nicht dass ich das nicht hätte zuende bringen können, aber ich hatte einfach keinen Bock auf dieses Gefummel. Warum tut man sich sowas im Jahr 2025 an? Wer es mag - bitte, ICH mag es nicht. Bei Xojo klickt man auf "install" und nach ca. 3 ... 5 Minuten verfügt man über eine voll funktionale IDE, egal ob unter Windows, MacOS oder Linux. Dass dieser Komfort etwas kostet, ist mir klar, aber das nehme ich gerne in kauf ...
:
Bearbeitet durch User
Frank E. schrieb: > Alleine die (aus meiner Sicht) völlig abstrusen Installations-Orgien > (mit dem manuellen Zusammensuchen irgendwelcher Komponenten im Web uva.) > haben mich beide Versuche nach ca. 30 min entnervt abbrechen lassen. > Nicht dass ich das nicht hätte zuende bringen können, aber ich hatte > einfach keinen Bock auf dieses Gefummel. Warum tut man sich sowas im > Jahr 2025 an? Wer es mag - bitte, ICH mag es nicht. Bei Qt? Man installiert den Qt Online Installer und der bringt sowohl QtCreator IDE als auch das Framework, als auch Buildautomation und C++ Toolchain auf die Platte. Ich wüsste nicht was man sich da zusammensuchen muss und was daran abstrus sein soll. QtCreator benötigt man nicht unbedingt. Wenn man ausschließlich QML verwenden will, so reicht es, das SDK zu installieren und mit dem Kommandozeilentool `qmlscene` das Hauptdokument aufzurufen. Entwickelt wird dann im Texteditor der Wahl. Qt ist in erster Linie ein ausgewachsenes Multiplattform C++ Framework nebst ein paar Kommandozeilentools und der QML Engine bzw. QML Bibliothek. Mit Felgo gibt es davon auch einen Ableger speziell für mobile Applikationen. Ich persönlich empfinde QML als eine äußerst intuitive Sprache in der man sehr schnell Fortschritte erzielt. Wobei, Sprache ist eigentlich übertrieben. Im wesentlichen ist es JavaScript mit einem deklarativen Überbau und dem leistungsfähigen Property Bindings Konzept. Wenn man das einmal gerafft hat, wirken andere GUI-Lösungen irgendwie umständlich. Ist zumindest mein Empfinden. Qt hat aber nicht die gleiche Marktmacht wie Google und Apple und fristet seit Nokias Ausstieg ein Nischendasein.
> Bei Qt? Man installiert den Qt Online Installer und der bringt sowohl > QtCreator IDE als auch das Framework, Das muss man nicht. Ich installier auch lieber aus einem lokalen Paket damit es spaeter zu 100% reproduzierbar ist. Aber da hab ich unter Linux und Windows bisher nur einmal die Installation gestartet und fertig. Aber wer weiss, vielleicht ist Macos einfach schlechter? :-D Das ganze aber mit der Einschraenkung das ich bisher bei Qt5 geblieben bin! Ich muss nicht immer das neueste Pferd "kaufen" bloss weil irgendwo auf der Welt ein paar Programmierer denken wieder was neues raushauen zu muessen. So wichtig sind die nicht. Vanye
Richard W. schrieb: > Ich wüsste nicht was man sich da zusammensuchen muss und was daran > abstrus sein soll. Ich auch nicht. Genau deswegen empfehle ich die IDE auch Anfängern, die gerade nur an Konsole Anwendungen interessiert sind.
Hallo an Alle! Nachdem jetzt doch einige hier geantwortet haben, wollte ich mich mal zurück melden. Ich habe mir alle Vorschläge mal durchgesehen. Am Ende fand ich den Reiz das mit Web-Tech zu machen doch am interessantesten. Ich bin für den Augenblick jetzt mal bei Vue.JS mit Vuetify hängen geblieben. Mit "mal schnell" und "wysiwyg" ist da leider nichts - mir kommt das aber vor als ob man da recht leistungsfähige und vor allen Dingen modern wirkende Oberflächen mit bauen kann. Connection zum Backend mach ich dann per Websockets. Das habe ich mal rudimentär getestet und läuft prinzipiell auch. Werde wohl noch eine Weile brauchen bis ich da mal richtig Fuß gefasst habe. Ist doch eine komplett andere Welt als C. Ich habe aber das Gefühl, dass es das Wert sein könnte.
Markus W. schrieb: > Mit "mal schnell" und "wysiwyg" ist da leider nichts Ja, man muss sich erst einarbeiten, aber wenn man es einmal beherrscht kann man recht schnell was zusammen zaubern. Ist bei Embedded Entwicklung ja auch so. WYSIWYG ist eh etwas "out" und bei der Unzahl an verschiedenen Geräten auch nicht so super sinnvoll. Markus W. schrieb: > Ich habe aber das Gefühl, dass es das Wert sein könnte. Denke auch, Web-Oberflächen braucht man immer. Man hat einfach mehr Möglichkeiten.
Im Rahmen der Vorbereitung zu einem Kurses sah ich mich genötigt, mich mal intensiver mit der Powershell (die es ja auch für Linux und Mac gibt) auseinanderzusetzen. Und ich muss sagen, nach anfänglicher Skepsis bin ich einigermaßen beeindruckt. Vieles ist simpel, wie in allen C-verwandten Sprachen, wie if, runde Klammern, geschweifte Klammer, else ... oder die Schleifen mit while oder for und foreach. Einiges ist von der Syntax etwas gewöhnungsbedürftig, aber durchaus nachvollziehbar und damit machbar. Es gibt die Möglichkeit, mit Datebnanken zu kommunizieren (nativ und per ODBC), man kann Sockets generieren ... ist schon 'ne Menge. Und es ist auch möglich, eine grafische GUI mit allen typischen Controls zu erstellen, die Skripte müssen keinesfalls nur in der CLI laufen! Klassen und Methoden sind ebenfalls vorhanden. Was ich noch nicht probiert habe, ist Grafik, z.B. Diagramme, aber ich bin sicher, das gibts auch was. Der Editor ISE ist m.E. auch ganz brauchbar, mit Syntax-Highlighting und Befehls-Vorschlägen. Und das Beste: Ist auf jedem Win-PC für Umme vorhanden und bestens ins System integriert, quasi schlüsselfertig!
Slint wäre auch noch noch eine Möglichkeit: https://slint.dev/ Das ist ein Projekt vom ehemaligen Maintainer der QML Engine in Qt und es ist mittlerweile als ausgewachsen anzusehen. Das schöne daran ist dass es mehrere Language Bindings gibt.
Frank E. schrieb: > Und es ist auch möglich, eine grafische GUI mit allen typischen Controls > zu erstellen Auch unter macOS und Linux?
Harald K. schrieb: > Frank E. schrieb: >> Und es ist auch möglich, eine grafische GUI mit allen typischen Controls >> zu erstellen > > Auch unter macOS und Linux? Gute Frage, das weiss ich momentan nicht. Werde aber recherchieren ...
Harald K. schrieb: > Frank E. schrieb: >> Und es ist auch möglich, eine grafische GUI mit allen typischen Controls >> zu erstellen > > Auch unter macOS und Linux? Soweit ich das verstanden habe, laufen die damit erstellten GUI's im Webrowser. Somit sollten sie mit allen OS funktionieren. Ich habe mich mal auf der Webseite von Vue.js umgesehen und mir einige Beispiele angeschaut. Ist im Wesentlichen JS, CSS und HTML. Schau Dir mal auf deren Webseite das Hello World Beispiel (https://vuejs.org/examples/#hello-world) an. Dort kann man sich dann den Quelltext für das Beispiel anzeigen lassen (in den Vorschaubereich Rechtsklick und "Frame-Quelltext anzeigen"). Für meinen Geschmack ein Haufen Code für nix - ein paar Zeilen HTML führen zum gleichen Ergebnis. PS: Ich sitze gerade am Mac und da funktionieren die Beispiele. Allerdings schöne GUI ist anders - ist aber meine persönliche Meinung.
:
Bearbeitet durch User
Hans schrieb: > Ich habe mich mal auf der Webseite von Vue.js ... Was hat Vue.js mit der Powershell zu tun?
Harald K. schrieb: > Was hat Vue.js mit der Powershell zu tun? Dort tippt man vue create ... ein, also kann jetzt Powershell jetzt GUIs mit vue.js. Nicht lachen, viele "Entwickler" glauben das wäre so.
Franko S. schrieb: > also kann jetzt Powershell jetzt GUIs In der Powershell kann man doch auch alle .net APIs nutzen, also auch beliebige GUIs erstellen. Ob das jetzt besser ist als es direkt in C# zu machen...
Niklas G. schrieb: > Franko S. schrieb: >> also kann jetzt Powershell jetzt GUIs > > In der Powershell kann man doch auch alle .net APIs nutzen, also auch > beliebige GUIs erstellen. Das hat mich jetzt interessiert. Ich habe die allmächtige KI gebeten mir eine kleine GUI zu schreiben. Siehe Anhang. Allerdings brauchte ich ein kleines batch-file, um das Skript auszuführen. Man kann PS-Scripte wohl nicht direkt per Doppelklick ausführen. > Ob das jetzt besser ist als es direkt in C# zu machen... Wenn man schon was hat und nur kurz was ändern will ist das Script wahrscheinlich einfacher. Ansonsten gebe ich dir schon recht.
Ich hab da auch immer wieder die gleichen Probleme:
Mit welcher Programmiersprache mach ich's jetzt?
Javascript über Node.js (vllt. mit electron o.ä.)? Ist mir nicht nativ
genug.
Normales C#/.NET mit WPF/UWP? Ist mir irgendwie zu blöd und
Zeitaufwändig.
flutter? Ja, nein, vielleicht.
Java? Vielleicht javaFX? Auch wieder altbacken, auch nicht so Recht...
Ich kann dir auf jeden Fall einmal empfehlen, dir flutter anzuschauen.
Frank E. schrieb:
> Wirf mal einen Blick auf "Xojo".
Was ist das denn für ein Noname Zeugs? Das kenne ich selbst als
erfahrener Entwickler nicht, der relativ Up-to-Date ist.
Aber wenn ich auf deren Seite schon direkt in der Navigation "Buy" sehe,
weiß ich warum das niemand kennen wird.
:
Bearbeitet durch User
Adrian schrieb: >> Wirf mal einen Blick auf "Xojo". > Was ist das denn für ein Noname Zeugs? Das hieß früher "RealBasic" und existiert schon sehr lange. Damals war eine der herausragenden Eigenschaften die recht große Kompabilität zu Visual Basic 6, weswegen etliche Entwickler von VB zu RB umgestiegen sind, denen die Änderungen zu Visual Basic .Net zu groß waren. Davon abgesehen ist RealBasic/Xojo in der Lage, Code nicht nur für Windows, sondern auch für Linux und macOS zu generieren. (Nein, ich nutze es nicht)
Harald K. schrieb: > Davon abgesehen ist RealBasic/Xojo in der Lage, Code nicht nur für > Windows, sondern auch für Linux und macOS zu generieren. Naja, MUltiplattform ist ja mittlerweile keine Kunst mehr. Das schaffen auch flutter & co. Für macOSX allerdings braucht man natürlich sowieso XCode und einen Mac.
Cross Plattform für Linux, Windows, Mac, Android und iOs kann ich fyne empfehlen (fyne.io). Fyne setzt auf go auf und ist wie go auch leicht zu lernen. Widgets sind die wichtigsten vorhanden, auch wenn andere Systeme mehr zu bieten haben, dafür aber auch schwerer zu lernen sind. Euen GUI-Builder hibt es, der für kommerzielle Projekte allerdings kostenpflichtig ist. Go ist von Natur aus Cross Plattform was fue Entwicklung extrem vereinfacht. Da hier schon mehrfach QT vorgeschlagen wurde und im Titel 2025 vorkommt: 2025 noch neue Projekt in QT und C++ zu beginnen ist meiner Meinung nach eine dumme Idee, sofern es keinen sehr wichtigen Grund gibt. Beides ist aus der Zeit gefallene überkomplexe Monster, die fast niemand richtig beherrscht.
Detlef W. schrieb: > Da hier schon mehrfach QT vorgeschlagen wurde und im Titel 2025 > vorkommt: 2025 noch neue Projekt in QT und C++ zu beginnen ist meiner > Meinung nach eine dumme Idee, sofern es keinen sehr wichtigen Grund > gibt. Beides ist aus der Zeit gefallene überkomplexe Monster, die fast > niemand richtig beherrscht. Lieber alle drei Jahre eine neue und potentiell unausgereifte Sau durch's Dorf treiben? Damit hätte ich ein Problem. Für einfache, kleine Applikationen muss man diese Frameworks auch nicht perfekt in- und auswendig kennen. Obschon sie ziemlich gut dokumentiert sind.
Adrian schrieb: > Frank E. schrieb: >> Wirf mal einen Blick auf "Xojo". > Was ist das denn für ein Noname Zeugs? Das kenne ich selbst als > erfahrener Entwickler nicht, der relativ Up-to-Date ist. Es zwingt dich ja niemand, es zu mögen, aber "noname" ist es ganz bestimmt nicht, nur weil du es nicht kennst ... https://xojo.com/company/about.php
:
Bearbeitet durch User
Detlef W. schrieb: > Beides ist aus der Zeit gefallene überkomplexe Monster, die fast > niemand richtig beherrscht. Mit der bei einigen Zeitgeistprogrammieren verbreiteten Vorstellung, Programmiersprachen und Frameworks nicht erlernen zu müssen, sondern No-Code-mäßig mit nur ein paar Mausklicks was zusammenzustoppeln, mag das stimmen. Aber vielleicht sollte man sich dann einen anderen Job suchen; wer auf diese Art und Weise "programmiert", wird auch ganz schnell durch eine "KI" ersetzt, die kann das nämlich genausoschlecht.
> Da hier schon mehrfach QT vorgeschlagen wurde und im Titel 2025 vorkommt: 2025
noch neue Projekt in QT und C++ zu beginnen ist meiner Meinung nach eine dumme
Idee, sofern es keinen sehr wichtigen Grund gibt. Beides ist aus der Zeit
gefallene überkomplexe Monster, die fast niemand richtig beherrscht.
Wenn man bereits C++ beherrscht, warum nicht? Und das bisschen
JavaScript lernt sich von selbst. Auf der Embedded World wirkten die am
Stand gezeigten Demos auf der Höhe der Zeit. Auch bei Felgo wirkten die
Demos nicht angestaubt.
Was mir allerdings auch sehr gut gefallen hat und als GUI Kit
anscheinend sehr gut skaliert, ist Slint.
Ich habe Java FX für GUIs genutzt, vor allem da ich mich in der Java-Welt ein wenig auskenne. Es hat einige nette, sehr einfach zu integrierende Features, wie per Mouseover abrufbare Hilfeblasen, elementare Animationen, etc.. Seit Oracle die Weiterentwicklung aufgegeben hat, ist es etwas aus der Mode gekommen, wird aber als openjfx noch gepflegt.
Richard W. schrieb: > noch neue Projekt in QT und C++ zu beginnen ist meiner Meinung nach eine > dumme > Idee, sofern es keinen sehr wichtigen Grund gibt. Beides ist aus der > Zeit > gefallene überkomplexe Monster, die fast niemand richtig beherrscht. Es kommt darauf an ob man schon viel Code in C++ hat. Die grundlegende Geschäftslogik einer Anwendung sollte auf keinen Fall in einem GUI Framework geschrieben sein, sondern möglichst wenig Abhängigkeiten haben. Zumindest nicht Qt als Abhängigkeit. Wenn das untere Gerüst dann schon in C++ geschrieben ist muss man sich mit QML dann auch wieder Wrapper bauen. Das macht oft mehr Arbeit. Ich denke auch heute ist C++ noch ein gutes Tool um neue Projekte anzufangen. Es geht am Ende nicht um die Sprache sondern um die Umsetzung und Sicherheit. Die kann man übrigens mit QML, Rust, Go etc. auch ordentlich vergeigen.
> Wenn man bereits C++ beherrscht, warum nicht? Und das bisschen > JavaScript lernt sich von selbst. Auf der Embedded World wirkten die am Man muss bedenken wo man sich hier aufhaelt! Hier (mikrocontroller.net) sind Leute die erstmal Mikrocontroller programmieren und dann etwas fuer Handy oder PC machen das damit kommuniziert. Mit anderen Worten die Leute koennen immer schon gut C und muessen dann nur etwas auf C++ erweitern und man muss am Ende auch nicht 100% reines C++ programmieren und es reicht vermutlich aus wenn man nur 50% vom C++ Sprachstandard drauf hat. Ich verwende z.B auch lieber printf als iostream. :-D Klar, wenn man Wirtschaftinformatiker ist und ein neues Lohnsteuerprogramm abliefern soll dann mag man das anders sehen! Im uebrigen schadet es nicht seine Kenntnisse von C auf C++ zu erweitern weil man dieses Wissen dann hinterher auch sinnvoll auf seinem Mikcrocontroller einsetzen kann! Vanye
Vanye R. schrieb: > Im uebrigen schadet es nicht seine Kenntnisse von C auf C++ zu erweitern > weil man dieses Wissen dann hinterher auch sinnvoll auf seinem > Mikcrocontroller einsetzen kann! C++ ist NICHT C mit Klassen. Das ist leider ein Irrtum vieler und wenn man so denkt sieht der Code auch aus. Ich hatte in meiner Laufbahn diversen Code, den ich anpassen musste, wo man genau gesehen hat, dass ehemals C Programmierer zum ersten mal an Production Code gelassen wurden. Den Leuten kann man persönlich nichts vorwerfen. Es ist eine Lernkurve und wird auch besser. Das ist übrigens Sprachunabhängig. Wenn ich mir meine Projekte von vor 20 Jahren ansehe ist das auch grauenhaft.
Wenn es laut OP schnell und unkompliziert sein soll, würde ich immer noch Tcl/Tk empfehlen. Das kann man problemlos mit C/C++ erweitern (sofern es laufzeitkritische Dinge gibt, hier erfahrungsgemäß maximal 1% des Codes) oder man baut den Interpreter direkt in seinen C/C++-Code ein. Man hat mit der BSD-Lizenz alle Möglichkeiten, es ist plattformunabhängig und man kann die GUI quasi in "Echtzeit" basteln, also im laufenden Programm. Ich arbeite hier bei solchen Anwendungen immer in einer entsprechend komfortablen Tcl-Shell direkt im Code, während die GUI sofort erscheint und ich sie zur Laufzeit anpassen und testen kann. Die Zyklen sind daher sehr kurz bzw. eigentlich gar nicht vorhanden, weil man jede Änderung ja sofort sieht. Wenn das in einen µC gegossen werden soll, wird der Interpreter inkl. (selbst von X11 umgeschriebenem) Tk-Frontend und Code compiliert. Das klappt seit Jahren sehr gut: wir haben damit eine äußerst leistungsfähige Embedded-Oberfläche mit allem was man benötigt (inkl. Canvas). Das lässt sich selbst auf kleineren AVRs und STM32 problemlos unterbringen. Ich damals die Möglichkeit geschaffen, nicht benötigte Tcl- und Tk-Befehle automatisch rauszuwerfen. Ist heutzutage aber kaum noch nötig. Es ist dank Interpreter sogar möglich, auf dem Controller selbst die GUI in Echtzeit anzupassen. Auf dem PC lässt man das Skript so wie es ist. Es gibt auch entsprechende Module für Darstellung in Browsern usw. Dazu ist der Code gerade in den GUI-Teilen äußerst kompakt. Die Entwicklung "on the fly" ist ein sehr großer Pluspunkt. GUIs? Hier NUR noch per Skriptsprache! ;-)
:
Bearbeitet durch Moderator
Detlef W. schrieb: > Da hier schon mehrfach QT vorgeschlagen wurde und im Titel 2025 > vorkommt: 2025 noch neue Projekt in QT und C++ zu beginnen ist meiner > Meinung nach eine dumme Idee, sofern es keinen sehr wichtigen Grund > gibt. Beides ist aus der Zeit gefallene überkomplexe Monster, die fast > niemand richtig beherrscht. Finde ich überhaupt nicht. Gustav G. schrieb: > Es kommt darauf an ob man schon viel Code in C++ hat. Die grundlegende > Geschäftslogik einer Anwendung sollte auf keinen Fall in einem GUI > Framework geschrieben sein, sondern möglichst wenig Abhängigkeiten > haben. Zumindest nicht Qt als Abhängigkeit. Nicht unbedingt. Qt ist nicht nur ein GUI-Framework, sondern beinhaltet auch viele andere Dinge, die Plattformabhängigkeiten wegabstrahieren. Man kann damit auch Konsolenanwendungen und Services komplett ohne GUI implementieren. Die GUI-Komponenten werden dann ggf. gar nicht erst dazu gelinkt, und es gibt dann auch keinerlei GUI-Abhängigkeiten. Gerade bezüglich des Themas Abhängkgeiten sehe ich da einen Vorteil von Qt. Wenn ich alle möglichen Sachen brauche, die Qt schon mitbringt, für die ich mir ohne sie ein Dutzend separate Libs als Abhänkigkeiten reinholen müsste, dann finde ich es besser, nur Qt als einzige Abhängigkeit zu haben.
Chris D. schrieb: > (selbst von X11 umgeschriebenem) Tk-Frontend und Code compiliert. Das > klappt seit Jahren sehr gut: wir haben damit eine äußerst > leistungsfähige Embedded-Oberfläche mit allem was man benötigt (inkl. > Canvas). > Das lässt sich selbst auf kleineren AVRs und STM32 problemlos > unterbringen. Ich damals die Möglichkeit geschaffen, nicht benötigte > Tcl- und Tk-Befehle automatisch rauszuwerfen. Ist heutzutage aber kaum > noch nötig. > Dein Lobgesang wäre etwas überzeugender mit einer Demo und nachvollziehbarem Code. Ansonsten hast du nur aufgezählt was du alles tolles gemacht hast und wie toll das alles funktioniert. Da können wir uns rein gar nichts davon kaufen und der OP erst recht nicht. Hinzuzufügen wäre dass tcl eine recht nischenbehaftete Scriptsprache ist.
> C++ ist NICHT C mit Klassen. Das ist leider ein Irrtum vieler und wenn > man so denkt sieht der Code auch aus. Dessen bin ich mir durchaus bewusst. Aber man kann ja so anfangen und sich weiterentwickeln! Man muss nicht mit der reinen Lehre anfangen. Und wenn dann ein paar Informatiker einen Herzinfarkt bekommen so kann ich damit leben. Ausserdem muss man seine Programme auch nicht veroeffentlichen wenn man diesen Wadenbeissern entgehen will die selbst dann noch mosern wenn sie etwas geschenkt bekommen. .-) > Nicht unbedingt. Qt ist nicht nur ein GUI-Framework, sondern beinhaltet > auch viele andere Dinge, die Plattformabhängigkeiten wegabstrahieren. Korrekt! Alleine deshalb schaetze ich das weil ich halt Programme sowohl auf dem Handy wie auch auf dem PC nutzen kann und sie nur einmal neu kompilieren muss. Man muss nicht auch noch jedes mal die Betriebssystemabhaengigkeiten lernen weil die abstrahiert werden. Beispiel: Ich speicher eine Variable mit QSettings. Dann stehen die unter Linux in einem versteckten Verzeichnis unter $HOME, bei Windows in der Registry und bei Android keine Ahnung wo, klappt aber immer gleich. Vanye
Vanye R. schrieb: > Aber man kann ja so anfangen und sich weiterentwickeln! Ja, man kann aber auch mit anderen nützlichen Dingen anfangen, wie std::max etc, String-Verarbeitung, Algorithmen wie std::sort, Container wie std::vector oder std::variant usw. Ja, da sind Klassen im Spiel, aber man bekommt nicht viel davon mit. So kann man sich auch gut vom Nutzen überzeugen.
Richard W. schrieb: > Dein Lobgesang wäre etwas überzeugender mit einer Demo und > nachvollziehbarem Code. Ernsthaft? Jemand wie der OP (und Du sicherlich auch) sollte in der Lage sein, sich da selbst Beispiele rauszusuchen. Es gibt sie tonnenweise im Netz (bspw. auf www.tcl.tk) und wer auch dazu zu faul ist, kann sich von ChatGPT in wenigen Sekunden eine basteln und erklären lassen. Ich hab das gerade mal bei ChatGPT gemacht: "Erstelle mir eine GUI mit Tcl/Tk, die mir eine Steuerung einer einfachen CNC-Maschine erlaubt." Der ausgegebene Code ist bei Tcl fast selbsterklärend. > Ansonsten hast du nur aufgezählt was du alles > tolles gemacht hast und wie toll das alles funktioniert. Da können wir > uns rein gar nichts davon kaufen und der OP erst recht nicht. Damit habe ich angedeutet, was damit möglich WÄRE. Niemand muss das machen. Und der OP kann natürlich damit etwas anfangen, denn: Markus W. schrieb: > Trotzdem muss ich hier und da mal ein paar rudimentäre GUI's am PC > bauen. Geht in Tcl/Tk wunderbar und sehr schnell. Ursprünglich war es genau dafür vorgesehen: quick and dirty GUIs > Es sollte Multi-Plattform sein. Ist Tcl/Tk. Dazu noch mit unkomplizierter Lizenz. > Wysiwyg-Editor Ich habe meine Vorgehensweise dazu mMn ausreichend erklärt. > Es sollte Möglichkeiten geben über lokale Netzwerk-Interfaces z.B. > TCP/UDP Verbindungen aufzubauen oder auch Serielle-Schnittstellen > anzusprechen; insofern es keinen direkten Dateisystemzugriff (wie bei > iOS) gibt zumindest dann die Möglichkeiten einer rudimentären isolierten > Dateiverwaltung Das geht natürlich auch - hatte ich vergessen zu erwähnen. Damit hat Markus einen mMn recht guten Hinweis zu seinem Anliegen erhalten. Einarbeiten muss er sich schon selbst - wobei er sehen wird, dass die GUI-Erstellung mit Tk wirklich sehr einfach ist, gerade wenn man "mal eben schnell" eine GUI bauen muss. > Hinzuzufügen wäre dass tcl eine recht nischenbehaftete Scriptsprache > ist. Warum sollte das stören? Nur weil sich eine Mehrheit bei der GUI-Erstellung masochistisch verhält, muss man das ja nicht auch mitmachen :-) Wir nutzen hier auch ausschließlich Linux - eine sehr angenehme Nische. Die Langlebigkeit (die erste Version von Tcl ist von 1988) und trotzdem vorhandene Aktualität sprechen eher dafür, dass sie ein durchaus sehr erfolgreiches "Nischendasein" führt. Gerade erst (Dezember 2024) ist Version 9.0.1 rausgekommen.
:
Bearbeitet durch Moderator
Gustav G. schrieb: > Die grundlegende > Geschäftslogik einer Anwendung sollte auf keinen Fall in einem GUI > Framework geschrieben sein, sondern möglichst wenig Abhängigkeiten > haben. Zumindest nicht Qt als Abhängigkeit. Qt ist kein GUI Framework. Mann damit ohne Einschränkung Konsole-Anwendungen und Dienste programmieren. Die compilate sind auch nicht übermäßig groß. Mit der Javascript basierten GUI von Qt konnte ich mich nie anfreunden. Ich bin bei den Widgets hängen geblieben. Vanye R. schrieb: > Ich verwende z.B auch lieber printf als iostream. Das schöne an Qt ist, dass es beide Programmierstile unterstützt. Und wem Exceptions zu kompliziert sind, der wird sich darüber freuen, dass man diese bei Qt gar nicht braucht. Vanye R. schrieb: > Dessen bin ich mir durchaus bewusst. Aber man kann ja so anfangen und > sich weiterentwickeln! Man muss nicht mit der reinen Lehre anfangen. Bei der Programmiersprache Go hat man den wilden Mix aus Funktionen und Methoden zum neuen Standard erhoben. Mir gefällt es nicht, aber allen Kollegen, die jünger sind. Chris D. schrieb: > Einarbeiten muss er sich schon selbst - wobei er sehen wird, dass die > GUI-Erstellung mit Tk wirklich sehr einfach ist, gerade wenn man "mal > eben schnell" eine GUI bauen muss. Kann ich bestätigen. Um 2000 herum war Tcl/Tk mein Mittel der Wahl, um GUI Tools für Solaris zu basteln, die meinem Team die Arbeit erleichterten. Hauptsächlich Wrapper um Kommadozeilentools.
:
Bearbeitet durch User
Gustav G. schrieb: > Benutzer wollen sich nicht um Abhängigkeiten kümmer und Microsoft hat es > bis zum heutigen Tage nicht geschafft mal eine Paketverwaltung > einzuführen. winget gibt's seit vier Jahren und ist (keine Ahnung seit wann) zumindest bei W11 vorinstalliert. https://learn.microsoft.com/en-us/windows/package-manager/ https://github.com/microsoft/winget-cli Eher unbekannt, obwohl es von vielen bekannten Firmen eingesetzt wird wäre Sciter.JS. Ist ne HTML/CSS-Lib mit Bindings für C++, Go, Rust, Delphi, zwar auch kommerziell kostenlos, dann muss man aber auf Quelltext und Support verzichten können. .NET + Cross-Platform = Avalonia. Deckt Windows, Linux, Mac, iOS, Android und Browser (WASM) ab. https://avaloniaui.net/
Fritz G. schrieb: > Es hat einige nette, sehr einfach zu > integrierende Features, wie per Mouseover abrufbare Hilfeblasen Das ist aber nun wirklich nichts Besonderes. Das kann Delphi definitiv ab Version 4. Um dieses Feature einzuschalten bedarf es eines einzigen Klicks im Formulardesigner und schon werden die Hints für jedes Element der GUI angezeigt, sofern man einen hinterlegt hat. Wem der einfache Texthinweis nicht genügt, der muß einfach die Methode onHint des Formulars überschreiben und schon kann man grafische Hinweise mit beliebigen Inhalt und Form anzeigen lassen. Der j-Builder von Borland (etwa genauso alt wie D4) kanns auch. Alle modernen Programmiersprachen können das. Selbst in HTML kann man das realisieren. Dieses Feature ist nun wirklich kein Alleinstellungsmerkmal von Java FX.
Vincent H. schrieb: > Neben den von Niklas G. genannten Sprachen werfe ich noch Flutter/Dart Google hat das Flutterteam vor ca einem Jahr rausgeworfen. Es gibt zwar nen Fork aber erfahrungsgemäss ist da dann die Luft raus. Wieder ein weiteres Produkt auf dem Google Friedhof gelandet. React Native gibts auch noch, wurde noch nicht erwähnt wenn es Multiplatform sein soll.
Franko S. schrieb: > Google hat das Flutterteam vor ca einem Jahr rausgeworfen. Gibts dafür Belege das Google das FLutter/Dart Team rausgeworfen hat? Ist Flutter damit von Seiten Google aufgegeben worden und gehört hier hin: https://killedbygoogle.com/ ?
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.