Hallo, ich benötige den Rat von einem sehr erfahrenen python-Entwickler, da ich vor einer grundsätzlichen Entscheidung stehe.
Ich habe gefallen an der Sprache python gefunden und würde meine Kenntnisse gerne vertiefen, idealer Weise alles mit python verwirklichen. Ich habe Kenntnisse in vb.net und vba für Excel. Vor einiger Zeit habe ich begonnen eine open source software zu erstellen, die auf einer anderen open source software aufbaut. Es wäre auch meine erste Software, die ich veröffentlichen möchte (ich bin ein Hobby-Programmierer).
Allerdings bin ich vom Programmieren her zu 90 % fertig und sie ist in vb.net geschrieben, als Windows Forms App. Jetzt hat Microsoft Winui3 herausgebracht und ich hatte die Idee, dass ich meine App auch grafisch mit Winui3 Aufhübschen muss, damit sich die potentiellen Nutzer sich nicht beim ersten Anblick bereits grausen...
Dass die Funktion einer Software gut sein muss, ist klar... Aber die Leute wollen oft im Porsche von a nach b fahren, obwohl es der Trabbi auch, wenn auch hässlicher, erledigt.
Für das Aufhübschen mit winui3 müsste ich aber c# lernen. Habe mir ein Buch über das Modernisieren von Windows Forms Apps gekauft und festgestellt, dass es megaviel Aufwand ist nur dass es hübscher ist.
In python verwende ich Qt für GUIs. Meine App soll eine exe mit GUI werden. Findest du Qt ausreichend hübsch um mit Winui3 einigermaßen schritthalten zu können?
Eigentlich möchte ich (vielleicht auch ausschließlich) nur noch python verwenden... Ich verwende Windows 10 und möchte Programme dafür schreiben.
Kann ich es wagen und das winui3-gedöns einfach ignorieren? Welche GUI nutzt du für python? Schreibst du ausschließlich Programme in python für alles was du brauchst? Kann man auch ohne Microsoft (und winui3) glücklich werden und es fehlt einem nichts (und die GUIs sind konkurrenzfähig hübsch genug)?
Ich stehe gerade vor einer Weggabelung und überlege in welche Richtung ich gehen soll... Deswegen möchte ich einen sehr erfahrenen python-Programmierer um Rat fragen...
Ich weiß, dass ich viele Fragen habe und dass die sinnvolle Beantwortung auch nicht einfach ist... Ich hoffe auf eine Antwort, die mir weiterhelfen kann... Ich möchte mich schonmal recht herzlich für die Mühe bedanken, die es brauchen wird eine sinnvolle Antwort zu erstellen.
Viele Grüße,
kwon
Ich bitte um Rat... (vielleicht __blackjack__)
Ich wuerde ja erstmal in Frage stellen, dass du mit C# arbeiten musst. Und zB laut https://learn.microsoft.com/en-us/answe ... -net-forms stimmt das auch nicht. Die winui 3 ist auch unter VB ansprechbar. Alles in .NET sollte eigentlich nutzbar sein von jeder gehosteten Sprache.
Ob Qt huebsch genug ist oder nicht ist ja subjektiv, und letztlich musst du das entscheiden. Qt ist ein sehr maechtiges und gutes Framework, aber wenn man fest vorhat, im Windows-Oekosystem zu bleiben, ist es weniger nuetzlich - die Staerke ist ja die plattformunabhaengigkeit. Und Qt ist lizenztechnisch schwieriger, da musst du genau schauen, ob sich das mit deinen Anforderungen deckt. Fuer ein FOSS-Projekt sollte das kein Problem sein, aber verkaufen wird dann eine Herausforderung. Und Qt ist basierend auf C++, und auch nur wirklich darin dokumentiert. Ob man damit fruchtbar arbeiten kann, haengt also davon ab, ob man die Doku versteht. Das ist nicht besonders anspruchsvolles C++ darin, aber eine gewisse Vertrautheit braucht man schon.
Ob Qt huebsch genug ist oder nicht ist ja subjektiv, und letztlich musst du das entscheiden. Qt ist ein sehr maechtiges und gutes Framework, aber wenn man fest vorhat, im Windows-Oekosystem zu bleiben, ist es weniger nuetzlich - die Staerke ist ja die plattformunabhaengigkeit. Und Qt ist lizenztechnisch schwieriger, da musst du genau schauen, ob sich das mit deinen Anforderungen deckt. Fuer ein FOSS-Projekt sollte das kein Problem sein, aber verkaufen wird dann eine Herausforderung. Und Qt ist basierend auf C++, und auch nur wirklich darin dokumentiert. Ob man damit fruchtbar arbeiten kann, haengt also davon ab, ob man die Doku versteht. Das ist nicht besonders anspruchsvolles C++ darin, aber eine gewisse Vertrautheit braucht man schon.
-
noisefloor
- User
- Beiträge: 4187
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
also wenn eine Applikation wirklich gut und nützlich ist und gut bedienbar ist und es Spaß macht, sie zu nutzen, ist die GUI sekundär. Meine Meinung. Wenn eine Applikation schlecht gemacht, macht eine altbackene GUI sie gefühlt doppelt schlecht. Was am Ende eigentlich egal ist, weil die Applikation ja sowie schon schlecht ist. Und auch eine schlechte Applikation machst du durch eine Bleeding Edge GUI mit topmodernem Design nicht besser.
Wenn du "nur" für eine Plattform programmierst (also z.B. nur Win), dann macht es IMHO Sinn, sich wenn möglich an deren Standards, primäre unterstützen Sprachen und Bibliotheken zu halten. Unter Win als C#, VB bzw. alles aus .NET.
Wenn man Cross-Plattform programmieren willst (oder musst), muss man sich halt ein paar mehr Gedanken machen. a) braucht man eine Sprache, die Cross-Plattform unterstützt wird - da ist man Python gut bedient. b) braucht man eine GUI-Framework, dass Croos-Plattform unterstützt wird - da ist man mit Qt gut bedient, wenn man mit der Lizenz klar kommt.
Alternativ ginge nach Python + Tkinter, dann hat man aber i.d.R. eine GUI im old-school Look.
Plan B: das Projekt webbasiert umsetzen. Serverseitig ist Python eine gute Wahl, clientseitig hat man sowieso kein Problem, weil der Client der Browser ist und die Oberfläche mit HTML + CSS + ggf. JS umgesetzt ist.
Gruß, noisefloor
also wenn eine Applikation wirklich gut und nützlich ist und gut bedienbar ist und es Spaß macht, sie zu nutzen, ist die GUI sekundär. Meine Meinung. Wenn eine Applikation schlecht gemacht, macht eine altbackene GUI sie gefühlt doppelt schlecht. Was am Ende eigentlich egal ist, weil die Applikation ja sowie schon schlecht ist. Und auch eine schlechte Applikation machst du durch eine Bleeding Edge GUI mit topmodernem Design nicht besser.
Wenn du "nur" für eine Plattform programmierst (also z.B. nur Win), dann macht es IMHO Sinn, sich wenn möglich an deren Standards, primäre unterstützen Sprachen und Bibliotheken zu halten. Unter Win als C#, VB bzw. alles aus .NET.
Wenn man Cross-Plattform programmieren willst (oder musst), muss man sich halt ein paar mehr Gedanken machen. a) braucht man eine Sprache, die Cross-Plattform unterstützt wird - da ist man Python gut bedient. b) braucht man eine GUI-Framework, dass Croos-Plattform unterstützt wird - da ist man mit Qt gut bedient, wenn man mit der Lizenz klar kommt.
Alternativ ginge nach Python + Tkinter, dann hat man aber i.d.R. eine GUI im old-school Look.
Plan B: das Projekt webbasiert umsetzen. Serverseitig ist Python eine gute Wahl, clientseitig hat man sowieso kein Problem, weil der Client der Browser ist und die Oberfläche mit HTML + CSS + ggf. JS umgesetzt ist.
Gruß, noisefloor
Hallo,
Dankeschön für die Antworten!
Wäre das Programmieren mit Kivy nicht eine Möglichkeit für mich?
Ich könnte python verwenden, die App würde auf vielen Plattformen laufen und eine gui ist auch dabei?
Ich bin vorhin zum ersten Mal auf kivy gestoßen...
Dankeschön für die Antworten!
Wäre das Programmieren mit Kivy nicht eine Möglichkeit für mich?
Ich könnte python verwenden, die App würde auf vielen Plattformen laufen und eine gui ist auch dabei?
Ich bin vorhin zum ersten Mal auf kivy gestoßen...
-
__blackjack__
- User
- Beiträge: 14030
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@kwon: Ich dann auch noch mal, weil ich ja namentlich erwähnt wurde. Denn ansonsten kann ich mich inhaltlich meinen Vorrednern anschliessen.
Das man .NET-Assemblies in der Regel von allen .NET-Sprachen aus verwenden kann hat __deets__ ja bereits geschrieben. Wobei C# zu lernen letztlich auch nicht sooo schwer sein sollte, denn zumindest als ich mir das letzte mal dieses Ökosystem angeschaut hatte, war VB.NET im Grunde nur eine Alternative Syntax zu C# und eine relativ dünne Bibliotheksschicht, aber keine komplett andere Programmiersprache. Microsoft hat VB.NET im Grunde hauptsächlich um den ganzen klassichen VisualBasic-Entwicklern eine Brücke ins .NET-Universum zu bauen. Wo sich C# semantisch von klassischem VisualBasic unterscheidet, da unterscheidet sich auch VB.NET von klassischem VisualBasic. Ich kann mir nicht vorstellen, dass VB.NET sich in der Entwicklung in der Zwischenzeit wieder mehr zu einer eigenen Sprache, von C# weg entwickelt hat.
Ich bin schon etwas länger auf Distanz zum Windows-Ökosystem, darum kenne ich den Unterschied zwischen Windows Forms und Winui 3 nicht. Sollte das wirklich nur optischer Natur sein, wäre das für mich erst einmal kein Grund da viel Arbeit für einen Umstieg zu investieren. Insbesondere wenn das eine Entscheidung zwischen jetzt, oder zumindest in naher Zukunft veröffentlichen, oder viel Arbeit ohne tatsächlich Verbesserungen an der Funktionalität bedeutet. Dann würde ich eher veröffentlichen und auf Rückmeldungen von den Benutzern warten. Wenn da dann alle sagen die Optik wäre ein Problem, dann kann man das ja immer noch auf eine neue GUI-Bibliothek umziehen. Wenn die aber andere Probleme finden, oder Ideen für sinnvolle Verbesserungen und Erweiterungen an der Funktionalität beisteuern, dann ist die Zeit daran zu arbeiten sinnvoller genutzt. IMHO.
So ein potentieller GUI-Bibliotheksumstieg ist natürlich immer eine gute Motivation Programmlogik und GUI sauber zu trennen, so das ein Umstieg leicht(er) möglich ist. Gut wäre auch wenn man aus der gleichen Code-Basis, zumindestens übergangsweise, eine Anwendung für beide GUI-Bibliotheken bauen kann. Entweder hat man dann die Bestätigung, dass man schon sauber getrennt hat, oder man muss nacharbeiten und verbessert damit ein wenig die Architektur der Anwendung.
Ein weiterer ”nicht-funktionaler” Grund für einen Umstieg von einer Bibliothek zu einer anderen wäre noch wenn die alte Bibliothek „deprecated“ ist, und absehbar ist, dass die in Zukunft nicht mehr funktionieren wird auf neueren Systemen. Da hat man bei Microsoft oft recht viel Zeit. Zumindest in der Vergangenheit wurde da Wert drauf gelegt, dass auch Legacy-Kram nicht unnötig kaputt geht. Gibt ja beispielsweise immer noch VB.NET obwohl es da technisch nicht wirklich einen Grund für gibt.
Da ich wie gesagt nicht mehr auf dem neuesten Stand bin was native Windows-UIs angeht, kann ich auch zu Qt vs. Winui 3 nichts sagen. Allerdings ist Qt themeable und ich gehe davon aus, dass die Qt-Entwickler sich schon darum kümmern werden, dass die Optik auf den jeweiligen Systemen wettbewerbsfähig ist/bleibt. Die verdienen damit schliesslich auch Geld.
Ich bin nahezu microsoftfrei glücklich. Das ist aber letztlich auch eine persönliche Sache ob man das sein will und kann. Wenn ich hauptsächlich für und auf Windows entwickeln müsste, würde ich sicher mehr von Microsoft verwenden. Ich bin aber mehr auf Serverseite und mit Webanwendungen unterwegs. Und nur gelegentlich mal auf Windows und noch etwas seltener für Desktop-Rechner. Da kann man leichter auf Microsoft verzichten.
Mein Lieblings-GUI-Toolkit ist Qt. Wenn es aber nur etwas kleines einfaches sein muss, wo Tkinter nicht mit überfordert ist, nehme ich auch das. Webanwendungen wurden auch schon erwähnt. Die müssen nicht zwingend in Server- und Client-Rechner getrennt werden. Man kann auch ein Python-Modul zusammen mit `bottle.py` und einem Start-Skript (Batch oder Powershell) in einen Ordner werfen, und damit Windowsnutzer glücklich machen. Teilweise auch Kollegen die eher nicht programmieren, denn ein HTML-Template und ein Python-Skript sind niederschwelliger als eine Qt-Anwendung, die vielleicht noch als EXE verpackt ist, wenn es um kleine Anpassungen geht.
Da es in der .NET-Welt eigentlich egal sein sollte mit welcher Programmiersprache man die Bibliotheken benutzt, könnte man auch mehr als eine Sprache in einem Projekt benutzen. Also zum Beispiel auch IronPython mit dazu nehmen wenn man mag. Falls Du so gar nicht auf Python verzichten willst. Bei .NET hat man im Gegensatz zu Javas JVM sogar noch den Vorteil, dass es auch ”schon” Python 3.4 gibt. Jython hängt noch bei 2.7. Allerdings fühlt es sich in beiden Fällen ein wenig unpythonisch an. IMHO.
Beruflich versuche ich möglichst viel in Python zu lösen. In der Regel bin ich da in der Wahl der Sprache frei. Manchmal hat man natürlich auch Einschränkungen wo man entweder nichts, also auch kein Python zusätzlich installieren kann, oder wo schon Code in anderen Sprachen vorhanden ist. Das wird es auch mal 4GL, Bash, Jython, Perl, PHP, Powershell, …
Privat auch am liebsten Python, aber da spiele ich auch gerne mal sowohl mit neuen als auch mit alten Sprachen.
Wenn ich .NET als Ziel hätte, und das macht unter Windows-only durchaus Sinn, würde ich persönlich mich nach einer anderen Sprache als C# umsehen, denn das sehe ich so ähnlich wie Java für die JVM und da finde ich Kotlin deutlich besser als Java. Nach so etwas in der Richtung würde ich mich auch bei .NET umsehen.
Das man .NET-Assemblies in der Regel von allen .NET-Sprachen aus verwenden kann hat __deets__ ja bereits geschrieben. Wobei C# zu lernen letztlich auch nicht sooo schwer sein sollte, denn zumindest als ich mir das letzte mal dieses Ökosystem angeschaut hatte, war VB.NET im Grunde nur eine Alternative Syntax zu C# und eine relativ dünne Bibliotheksschicht, aber keine komplett andere Programmiersprache. Microsoft hat VB.NET im Grunde hauptsächlich um den ganzen klassichen VisualBasic-Entwicklern eine Brücke ins .NET-Universum zu bauen. Wo sich C# semantisch von klassischem VisualBasic unterscheidet, da unterscheidet sich auch VB.NET von klassischem VisualBasic. Ich kann mir nicht vorstellen, dass VB.NET sich in der Entwicklung in der Zwischenzeit wieder mehr zu einer eigenen Sprache, von C# weg entwickelt hat.
Ich bin schon etwas länger auf Distanz zum Windows-Ökosystem, darum kenne ich den Unterschied zwischen Windows Forms und Winui 3 nicht. Sollte das wirklich nur optischer Natur sein, wäre das für mich erst einmal kein Grund da viel Arbeit für einen Umstieg zu investieren. Insbesondere wenn das eine Entscheidung zwischen jetzt, oder zumindest in naher Zukunft veröffentlichen, oder viel Arbeit ohne tatsächlich Verbesserungen an der Funktionalität bedeutet. Dann würde ich eher veröffentlichen und auf Rückmeldungen von den Benutzern warten. Wenn da dann alle sagen die Optik wäre ein Problem, dann kann man das ja immer noch auf eine neue GUI-Bibliothek umziehen. Wenn die aber andere Probleme finden, oder Ideen für sinnvolle Verbesserungen und Erweiterungen an der Funktionalität beisteuern, dann ist die Zeit daran zu arbeiten sinnvoller genutzt. IMHO.
So ein potentieller GUI-Bibliotheksumstieg ist natürlich immer eine gute Motivation Programmlogik und GUI sauber zu trennen, so das ein Umstieg leicht(er) möglich ist. Gut wäre auch wenn man aus der gleichen Code-Basis, zumindestens übergangsweise, eine Anwendung für beide GUI-Bibliotheken bauen kann. Entweder hat man dann die Bestätigung, dass man schon sauber getrennt hat, oder man muss nacharbeiten und verbessert damit ein wenig die Architektur der Anwendung.
Ein weiterer ”nicht-funktionaler” Grund für einen Umstieg von einer Bibliothek zu einer anderen wäre noch wenn die alte Bibliothek „deprecated“ ist, und absehbar ist, dass die in Zukunft nicht mehr funktionieren wird auf neueren Systemen. Da hat man bei Microsoft oft recht viel Zeit. Zumindest in der Vergangenheit wurde da Wert drauf gelegt, dass auch Legacy-Kram nicht unnötig kaputt geht. Gibt ja beispielsweise immer noch VB.NET obwohl es da technisch nicht wirklich einen Grund für gibt.
Da ich wie gesagt nicht mehr auf dem neuesten Stand bin was native Windows-UIs angeht, kann ich auch zu Qt vs. Winui 3 nichts sagen. Allerdings ist Qt themeable und ich gehe davon aus, dass die Qt-Entwickler sich schon darum kümmern werden, dass die Optik auf den jeweiligen Systemen wettbewerbsfähig ist/bleibt. Die verdienen damit schliesslich auch Geld.
Ich bin nahezu microsoftfrei glücklich. Das ist aber letztlich auch eine persönliche Sache ob man das sein will und kann. Wenn ich hauptsächlich für und auf Windows entwickeln müsste, würde ich sicher mehr von Microsoft verwenden. Ich bin aber mehr auf Serverseite und mit Webanwendungen unterwegs. Und nur gelegentlich mal auf Windows und noch etwas seltener für Desktop-Rechner. Da kann man leichter auf Microsoft verzichten.
Mein Lieblings-GUI-Toolkit ist Qt. Wenn es aber nur etwas kleines einfaches sein muss, wo Tkinter nicht mit überfordert ist, nehme ich auch das. Webanwendungen wurden auch schon erwähnt. Die müssen nicht zwingend in Server- und Client-Rechner getrennt werden. Man kann auch ein Python-Modul zusammen mit `bottle.py` und einem Start-Skript (Batch oder Powershell) in einen Ordner werfen, und damit Windowsnutzer glücklich machen. Teilweise auch Kollegen die eher nicht programmieren, denn ein HTML-Template und ein Python-Skript sind niederschwelliger als eine Qt-Anwendung, die vielleicht noch als EXE verpackt ist, wenn es um kleine Anpassungen geht.
Da es in der .NET-Welt eigentlich egal sein sollte mit welcher Programmiersprache man die Bibliotheken benutzt, könnte man auch mehr als eine Sprache in einem Projekt benutzen. Also zum Beispiel auch IronPython mit dazu nehmen wenn man mag. Falls Du so gar nicht auf Python verzichten willst. Bei .NET hat man im Gegensatz zu Javas JVM sogar noch den Vorteil, dass es auch ”schon” Python 3.4 gibt. Jython hängt noch bei 2.7. Allerdings fühlt es sich in beiden Fällen ein wenig unpythonisch an. IMHO.
Beruflich versuche ich möglichst viel in Python zu lösen. In der Regel bin ich da in der Wahl der Sprache frei. Manchmal hat man natürlich auch Einschränkungen wo man entweder nichts, also auch kein Python zusätzlich installieren kann, oder wo schon Code in anderen Sprachen vorhanden ist. Das wird es auch mal 4GL, Bash, Jython, Perl, PHP, Powershell, …
Privat auch am liebsten Python, aber da spiele ich auch gerne mal sowohl mit neuen als auch mit alten Sprachen.
Wenn ich .NET als Ziel hätte, und das macht unter Windows-only durchaus Sinn, würde ich persönlich mich nach einer anderen Sprache als C# umsehen, denn das sehe ich so ähnlich wie Java für die JVM und da finde ich Kotlin deutlich besser als Java. Nach so etwas in der Richtung würde ich mich auch bei .NET umsehen.
„A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP” — Leonard Nimoy's last tweet.