Welche Sprache sollte ich verwenden?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
__deets__
User
Beiträge: 14480
Registriert: Mittwoch 14. Oktober 2015, 14:29

Du musst mit verschiedenen installer builders arbeiten. pyinstaller, py2app mindestens. Ggf noch was drittes für Linux. Und die machen Gerne mal Probleme.

Wenn du dir die Lizenz erlauben kannst, solltest du Qt nehmen. wx ist altbacken und grausam.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@fg_91:

Für die Umsetzung einer "nativen" Oberfläche finde ich Qt gut ja, hat aber damit zu tun, dass ich früher mit Qt viel zu hatte. Zu wxWidgets kann ich Dir nichts sagen. Im Prinzip haben alle GUIs ihre Eigenheiten, z.B. merkt man Qt in Python noch relativ stark die C++ Herkunft an (manchmal müssen explizite Referenzen gehalten werden, teilweise unpythonische Entwurfsmuster, Docs mit C++ Schippeln usw).

Zu einer Weboberfläche/Django kann ich Dir nur dann raten, wenn Du entweder Vorerfahrungen damit hast oder im Rahmen der Lüftersteuerung draufziehen möchtest. Da kommt halt viel aus unterschiedlichen Domänen zusammen, um das halbwegs sicher hinzubekommen.

Wenn Du bei beidem (GUI oder Weboberfläche) bei Null anfängst, kommst Du wahrscheinlich mit einer gut dokumentierten GUI-Bibliothek schneller zum Ziel. Qt fetzt diesbezüglich, ist aber nur für C++ gut dokumentiert. Das lässt sich mit etwas Vorkenntnissen in C++ aber relativ einfach auf Python + Qt übertragen. Wenn Deine Pythonkenntnisse im Vgl. zu C++ dünn sind, nimm C++ und Qt.
Benutzeravatar
DeaD_EyE
User
Beiträge: 1011
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Um einen Lüfter ein-/ausschalten zu können, kann man eine LOGO! mit Relaisausgängen verwenden.
Die Logo gibt es auch als 230V Version.

Logo kostet ca. 100€. Bekommt man auch gebraucht günstiger. Darauf achten, dass die CD beiliegt und ein Ethernet-Anschluss vorhanden ist. Dann kann man auch echte Taster anschließen und kann ohne GUI den Lüfter Ein-/Ausschalten. Programmiert wird die Logo grafisch mit der mitgelieferten Software Logosoft.

Die Logo kann man z.B. als Modbus-Master/Slave via TCP betreiben. Hat den Vorteil, dass die GUI unabhängig von der LOGO betrieben werden kann. Für Modbus gibt es eine Python Bibliothek (pymodbus). MQTT würde ich dafür nicht verwenden, da man sonst noch irgendwo einen Broker benötigt.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
anonym112

Danke für die Antworten

Wahrscheinlich werde ich dann bei C++ und QT bleiben. Die verschiedenen Platformen muss eh handeln?
Bin mir nur nicht sicher ob QT Lizenz technisch für mich das richtige ist. Da muss ich mal nochmal recherchieren.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Für Deine Verwendungszwecke sollte der Teil von Qt, der unter L/GPL3 daherkommt, völlig ausreichend sein. Du nutzt es ja nur intern, da sind OSS-Regeln ja eh erfüllt (Du hast Zugriff auf den Sourcecode). Anders sieht es aus, wenn Du die Anwendung weitergeben möchtest, dass geht dann nur mit dem Sourcecode. Oder halt mit der kommerziellen Lizenz, dann auch ohne Sourcecode.

Mit C++ würde ich wahrscheinlich sogar überlegen, die kleine Steuerapplikation statisch zu linken - da kommt zwar ein relativ großes Binary raus, allerdings hat das dann nur noch Abhängigkeiten gegen fundamentale Standard-APIs. Unter Windows ist so eine Anwendung über viele Releasezyklen lauffähig (APIs sind sehr stabil/konservativ), unter Linux zumindest bis zum nächsten Ausrollen einer fundamentalen Änderung (linux, glibc, X11/Wayland).
Aber Achtung - statisches Linken ist offiziell nicht empfohlen seitens Qt, und manche Dinge sind schlicht nicht verfügbar. Leider ist nicht sauber dokumentiert, was noch geht und was nicht. Wenn Dir das zu heisst ist, machs dynamisch, allerdings musst Du dann evtl. nach jedem größeren Distributionsupgrade die App neu linken. Ein Mittelweg wäre, die shared libs von Qt mit auszuliefern und nicht auf die Pakete der Linux-Distribution zu gehen (ist ein bisschen mehr bundling-Arbeit, geht aber z.B. mit AppImage leicht von der Hand, für Windows gibts windeployqt).
anonym112

Wenn ich es aber theoretisch mal weitergeben möchte, müsste ich den Source Code mitliefern. Das schreckt mich ein wenig ab. Das Problem sind ja nur die Bestandteile von QT die unter GPL stehen, nicht die LGPL, richtig?

Genau das fände ich gut, wenn es über mehrere Releasezyklen lauffähig bleiben würde..
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

fg_91 hat geschrieben: Dienstag 4. Mai 2021, 18:37 Wenn ich es aber theoretisch mal weitergeben möchte, müsste ich den Source Code mitliefern. Das schreckt mich ein wenig ab. Das Problem sind ja nur die Bestandteile von QT die unter GPL stehen, nicht die LGPL, richtig?
Auch bei der GPL musst Du den Quelltext nicht direkt mitliefern, allerdings den Empfängern eine Möglichkeit einräumen, an genau den Quelltext der weitergegebenen Version ranzukommen. Die meisten Kernkomponenten von Qt sind auch als LGPL verfügbar, damit kann Deine Anwendung auch closed source sein. Musst Du aber beim Linken und Benutzen anderer Bibliotheken höllisch aufpassen, sonst wird Dein Quelltext automatisch unter GPL gestellt.
Warum schreckt Dich die Quelltextweitergabe ab, zumal bei einer so kleinen Applikation? Wir diskutieren schon viel länger als die Umsetzung bräuchte...

fg_91 hat geschrieben: Dienstag 4. Mai 2021, 18:37 Genau das fände ich gut, wenn es über mehrere Releasezyklen lauffähig bleiben würde..
Das gibts nirgends als Garantie, spätestens wenn ein Betriebssystem wichtige ABIs ändert, läuft auch ein statischer Build nicht mehr. Allerdings schafft Windows, die Schnittstellen auch mal >15 Jahre stabil zu halten, unter Linux oder OSX werden die alten Zöpfe viel früher abgeschnitten.
anonym112

Danke für deine Antwort nochmal :) Du hast schon Recht, es ist wirklich eigentlich keine große Sache.
Antworten