Technische Neuigkeiten zu PySimpleGUI
(github.com/PySimpleGUI)- Nachdem PySimpleGUI seinen Kommerzialisierungsversuch abgeschlossen hat, wurden aus dem PySimpleGUI-5-Code die Lizenz- und Sicherheitskomponenten entfernt; anschließend wurde es auf GitHub und PyPI als PySimpleGUI 6 unter der LGPL3-Lizenz wieder veröffentlicht
- Die aktuelle Version kann mit
python -m pip install PySimpleGUIinstalliert werden; auch die ältere Version4.60.5.1, dermaster-Branch auf GitHub oder ein bestimmtes Release wie6.1lassen sich direkt per pip installieren - PySimpleGUI wird als Wrapper für GUI-Bibliotheken wie tkinter beschrieben: Es macht GUI-SDKs einfacher und kompakter, bietet zugleich detaillierte Anpassungsmöglichkeiten und soll keine vorherige Erfahrung mit GUI-Programmierung erfordern
- Version 6.2 enthält unter anderem einen Bugfix für
Window.settings_save, Inline-Ausgabe von Bildern in Multiline,psgupgrade, programmatische Auswahl von Tree-Nodes,"H:M:S"-String-Timer fürWindow.start_timersowie die Konfiguration der Rahmenfarbe von Frames - Das Projekt wird ohne Annahme von Pull Requests gepflegt; die langfristige Zukunft ist ungewiss, doch der Autor erklärt, weiter Code schreiben und das Ökosystem aufräumen zu wollen
PySimpleGUI 6 ist wieder Open Source
- PySimpleGUI unternahm einen Kommerzialisierungsversuch, konnte damit aber nicht die Ressourcen schaffen, die nötig gewesen wären, um das Projekt im erhofften Umfang fortzuführen
- Im Februar 2025 wurden das Ende von PySimpleSoft und die Fortsetzung des Supports bis Ende 2025 angekündigt; danach blieb die Frage, was mit Code, Dokumentation und Repository geschehen sollte
- Der PySimpleGUI-5-Code wurde nach Entfernung der Lizenz- und Sicherheitskomponenten auf GitHub und PyPI veröffentlicht
- Die neu veröffentlichte Version verwendet die LGPL3-Lizenz
- Der Udemy-Kurs ist eine Zeit lang kostenlos verfügbar; der Gutscheincode lautet
033334A16163C571B739
Installation
- Aktuelle Version v6 von PyPI installieren:
python -m pip install PySimpleGUI
- Ältere Version
4.60.5.1installieren:python -m pip install PySimpleGUI==4.60.5.1
- Der aktuelle Code aus dem GitHub-Repository kann direkt installiert werden:
python -m pip install --upgrade https://github.com/PySimpleGUI/PySimpleGUI/zipball/master
- Um ein bestimmtes Release von GitHub zu installieren,
masterdurch die Release-Nummer ersetzen:python -m pip install --upgrade https://github.com/PySimpleGUI/PySimpleGUI/zipball/6.1
- Nach dem Klonen oder Herunterladen des Repositorys ist auch eine lokale Installation möglich:
python -m pip install .
Rolle von PySimpleGUI
- PySimpleGUI ist ein Wrapper um tkinter und andere GUI-Bibliotheken
- Es überführt GUI-SDKs in eine einfachere und kompaktere Struktur, bietet aber dennoch detaillierte Anpassungsmöglichkeiten
- Es wird damit beworben, dass keine vorherige Erfahrung mit GUI-Programmierung nötig ist
- Das Beispiel im README erstellt eine interaktive Fenster-App nur mit
Text,Input,Button,Window, einer Event-Loop,window.read()undwindow.close() - Die Dokumentation ist unter Docs.PySimpleGUI.com verfügbar
Entwicklungsmodell und langfristiger Ausblick
- PySimpleGUI sei eher in einer Weise entwickelt worden, die einem proprietären Produkt ähnelt, als einem traditionellen Open-Source-Projekt
- Pull Requests werden nicht angenommen
- Die langfristige Zukunft ist nicht sicher, doch derzeit hat der Autor Freude daran, Code zu schreiben und zu helfen
- Die PySimpleGUI-Erfahrung wird als „once-in-a-lifetime“-Erlebnis beschrieben, weil man sehen konnte, was Menschen damit geschaffen haben
Funktionen und Korrekturen in Version 6.2
- 6.2 enthält einen Bugfix für
Window.settings_save - Es wurde eine Funktion hinzugefügt, um Bilder in Multiline-Elementen inline zu „printen“
- Die Funktion zum Upgrade auf das neueste Maintenance-Release ist wieder in PySimpleGUI integriert
- Dafür kann das Home Window oder die Kommandozeile mit
psgupgradeverwendet werden - Release Notes lassen sich ansehen und neue Versionen installieren
- Dafür kann das Home Window oder die Kommandozeile mit
- Bug #5750 wurde behoben, bei dem
Graph-Events in eine Endlosschleife gerieten, wenn siewrite_event_value-Events erhielten- Die Korrektur erfolgt durch Löschen des Realtime-Button-Flags
- Der Änderungsumfang sei auf die Bedingung des Graph-Elements beschränkt, sodass die Wahrscheinlichkeit von Regressionen gering sei
Tree.updatewurde um den Parameterselect_node_keyserweitert, sodass Tree-Nodes programmatisch so ausgewählt werden können, als hätte der Nutzer sie ausgewählt- Die Funktion und der Parameter
echo_stdout_stderrvon Multiline wurden korrigiert- Echo erfolgt nur, wenn stdout oder stderr auf das entsprechende Element umgeleitet wurde
- Diese Funktion führt die Umleitung nicht selbst durch
- Mit dem Fix für #6686 wurde ein Problem behoben, bei dem der Calendar-Chooser-Button ein Feld löschte, das erst zum Zeitpunkt der Rückgabe von
window.readgelöscht werden sollte - Im Home Window wird die Versionsnummer des Maintenance-Release angezeigt, und die Position des Installationsbuttons wurde verschoben
- Beim Aufruf von
Window.start_timerkann der Timer als"H:M:S"-String angegeben werden - Für scrollbare Column-Elemente wurde Unterstützung für ausschließlich horizontales Scrollen hinzugefügt
- Frame-Elemente erhielten die Parameter
border_colorundborder_width_no_relief, mit denen die Rahmenfarbe gesetzt werden kann- Wenn keine eigene Einstellung vorhanden ist, verwendet die Rahmenfarbe eines Frames standardmäßig die Farbe des Textelements
- Der Abschnitt „call reference“ der Dokumentation wurde für das Release 6.2 aktualisiert
Drag-and-drop und angrenzende Projekte
- Drag-and-drop sei eine lange gewünschte Funktion, und es wurde ein Weg gefunden, sie im User-Code-Space ohne Änderungen am PySimpleGUI-Code zu implementieren
psgdndist ein neues Paket, das Drag-and-drop zu PySimpleGUI hinzufügt- Es kann per pip installiert und verwendet werden
- Weitere Informationen und Beispiele befinden sich im entsprechenden Repository
psgdnd6.0.1 wurde auf PyPI veröffentlicht und funktioniert unter Windows- Version 6.0.2 auf GitHub enthält die für Linux nötigen Korrekturen
- Der Support-Status für Mac ist noch unbekannt
- Im Repository
PSGMicroPythonwurde Code ergänzt, der mit MicroPython-basierten Mikrocontrollern kommuniziert- Er läuft auf Raspberry Pi Pico und ESP32
- Er könnte auch auf anderen Boards funktionieren
- Er ist nicht als robustes oder großes Projekt gedacht, sondern wird als Code beschrieben, der nützlich sein kann
PSGWeb-Prototyp
- PSGWeb ist ein Prototyp, der PySimpleGUI in einem Browserfenster ausführt
- Er funktioniert mit den meisten Demo-Programmen
- Wenn man einer GitHub-URL einer PySimpleGUI-Anwendung
psgweb.usvoranstellt, kann man versuchen, sie auszuführen- Beispiel:
https://github.com/PySimpleGUI/PySimpleGUI/… - Umgewandeltes Beispiel:
https://psgweb.us/github.com/PySimpleGUI/…
- Beispiel:
- PSGWeb entstand als Teil der größeren PSG-5-Arbeiten, wurde aber nicht veröffentlicht
- Es gibt keine Pläne, diesen Prototyp zu veröffentlichen oder zu erweitern
Haltung zur Nutzung von KI
- Der Autor nutzt LLMs für die Suche und Zusammenfassung von Dokumentation, die Recherche von Fehlern, Untersuchungen und den Erwerb von Wissen
- Er schreibt keinen Code mit LLMs
- Als Grund nennt er schlicht, dass er das Schreiben von Code selbst mag
- Auch dass das Projekt nicht für Pull Requests geöffnet wurde, erklärt er damit, lieber selbst Code schreiben zu wollen, statt andere den Code schreiben zu lassen
- Zur Frage, ob PySimpleGUI im KI-Zeitalter noch relevant ist, meint er, es reiche aus, dass täglich Menschen PySimpleGUI entdecken und installieren und mindestens eine Person es nutzt
- Der Autor sagt, er könne sich das Erstellen von Windows-Apps ohne PySimpleGUI nur schwer vorstellen
- Bei einer jüngsten Arbeit an einem 6502-Breadboard-Computer habe er mit zwei Raspberry Pi Pico und einer PySimpleGUI-App einen Bus-Analyzer gebaut
- Er habe damit leicht eine Frontend-App unter Windows erstellen können, um das Werkzeug zu steuern
Projektgeschichte und Finanzierungsprobleme
- PySimpleGUI begann 2018 als Einmal-Code für eine benötigte GUI eines Media-Player-Prototyps
- Ziel war es, Tkinter ohne Erfahrung mit objektorientierten GUI-Frameworks linearer und intuitiver zu umhüllen, damit schnell etwas lauffähig wurde
- Der Autor stellte es ohne Erfahrung mit Python oder Open Source auf GitHub und ging eher wie bei einem Startup vor als wie bei einem traditionellen Open-Source-Projekt
- Zeitachse:
- Juli 2018: Version 1
- Juni 2019: Version 4
- Januar 2020: Finanzierungsprobleme wurden zum Hauptanliegen, und Kommerzialisierung wurde erwähnt
- November 2020: Ankündigung des Udemy-Kurses und Ergänzung eines öffentlichen Hilferufs
- Dezember 2021: Veröffentlichung des Kurses
- Februar 2024: kommerzielles Release von Version 5
- April 2026: Version 6
- Das Announcements Issue auf GitHub wurde wie ein Blog zur Projekthistorie genutzt und wuchs auf mehr als 1.700 Einträge an
- Zur besseren Lesbarkeit wurde im Tab Announcements 2018-2024 der Dokumentation ein Snapshot veröffentlicht
- Vollzeit-Open-Source-Arbeit erzeugte unmittelbaren und anhaltenden finanziellen Druck
- Sponsoring und Spenden über GitHub Sponsors und Buy Me a Coffee erreichten selbst auf dem Höhepunkt nur etwa 150 US-Dollar pro Monat
- Der Udemy-Kurs mit 61 Lektionen und 11,5 Stunden Inhalt kam anfangs kurzzeitig auf etwa 2.000 US-Dollar pro Monat, fiel danach aber unter 100 US-Dollar
- Keine der beiden Varianten reichte aus, um das Projekt langfristig zu erhalten
Ergebnis der Kommerzialisierung und Lizenzerfahrung
- Die Einführung des kostenpflichtigen Produkts Version 5 war keine abrupte Entscheidung, sondern wurde über Jahre hinweg öffentlich im README und in Ankündigungen diskutiert
- Anfang 2024 wurde nach Ausschöpfen anderer Optionen die kommerzielle Version veröffentlicht
- Ziel war es, Zugänglichkeit zu erhalten, statt Hürden aufzubauen
- Nach dem Maßstab finanzieller Nachhaltigkeit lief es nicht gut, nach den Maßstäben Erfahrung, Lernen und Beziehungen war es jedoch wertvoll
- Nach der Kommerzialisierung gingen nicht die meisten Nutzer verloren, und viele Unternehmen verwendeten PySimpleGUI weiter
- Das Problem bestand darin, Unternehmen zum Kauf von Lizenzen zu bewegen
- Gewählt wurde eine Hobbyist License, bei der Hobby-Nutzer und Studenten kostenlos nutzen können und Unternehmen zahlen
- In der Praxis identifizierte sich die große Mehrheit der Nutzer als Hobby-Nutzer
- Zehntausende Unternehmensnutzer registrierten sich für den Free-Tier, und selbst in großen Unternehmen waren Hunderte Nutzer, aber nur wenige kostenpflichtige Lizenzen, keine Seltenheit
- Die Entscheidung, eine kostenlose Option anzubieten, bereut der Autor nicht
- Seine persönliche Schlussfolgerung ist, dass es eine starke kulturelle Erwartung gibt, Python-Tools und -Bibliotheken müssten kostenlos sein
- Preis oder Beschwerden schienen nicht das Kernproblem zu sein; die Menschen nutzten PySimpleGUI weiter, fühlten sich aber nicht verpflichtet zu zahlen
- Auch klare Lizenzbedingungen änderten das Verhalten nicht immer
Aktuelle Lizenz
- Der Copyright-Hinweis lautet
Copyright 2018-2026 PySimpleGUI. All rights reserved. - Die aktuelle Lizenz ist LGPL3
1 Kommentare
Meinungen auf Hacker News
Bei der Arbeit musste ich Arbeitszeit in Jira erfassen, aber ich wollte die Website nicht ständig offen lassen, und auch der Prozess, das aktuelle Issue zu finden, den Link zur Zeiterfassung zu suchen und einen Kommentar hinzuzufügen, war langsam.
Ich wollte eine Desktop-App mit einer Liste der mir zugewiesenen Issues und Buttons zum Hinzufügen von Kommentaren/Arbeitszeit. Mit Tkinter habe ich lange herumprobiert, um es gut aussehen zu lassen, aber nachdem ich PySimpleGUI entdeckt hatte, konnte ich Jira-API-Hooks anbinden und bauen, was ich wollte; es war ein gutes Projekt, um UI-Entwicklung zu lernen.
Ein Freund erzählte ebenfalls, dass er an einer Arbeitsstelle einen internen Qt-Client für grundlegende Jira-Aufgaben gebaut hatte, und als auch ich Arbeit mit Jira nachverfolgen musste, habe ich mit https://github.com/go-jira/jira mehrere Konsolenskripte verwendet, um Änderungen zu erledigen.
Solche GUI-Frameworks finde ich wirklich vielversprechend. Eine native Desktop-Erfahrung ist deutlich besser als eine Webview-Kombination, und die vereinfachte Event-Loop von PySimpleGUI sowie der Multi-Backend-Ansatz wirken tatsächlich neu auf mich.
Allerdings frage ich mich, warum es nicht mehr „Auto-GUIs“ gibt, denen man einfach Datenstrukturen und Funktionen gibt und die daraus automatisch ein passendes Interface zur Bearbeitung erzeugen. Wenn man per Heuristik entscheidet, ob Panels vertikal/horizontal angeordnet werden oder ob man Tabs beziehungsweise Popups nutzt, könnte das viele Möglichkeiten eröffnen für Dinge, die für eine CLI zu verschachtelt sind und für eine Webapp zu viele native Funktionen brauchen.
https://github.com/chriskiehl/Gooey
Man kann eine Struct definieren und sie an die Funktion
dialogübergeben; dann wird passend zu den Feldern der Struct automatisch ein Dialog erzeugt, und wenn der Nutzer OK drückt, wird ein Callback aufgerufen. Mit benutzerdefinierten Attributen kann man auch festlegen, welches Widget verwendet werden soll: Wenn man zum Beispiel einintmit@ControlledBy!VerticalSlider(0, 100)versieht, wird statt eines Zahlen-Eingabefelds ein Slider von 0 bis 100 daraus. Auch Menüfunktionen kann man etwa mit@menu("Search") Find(string text) { ... }annotieren, um Menüs und Dialoge automatisch zu erzeugen, und es gibt auch einDataControllerWidget, das bei jedem Änderungs-Event einen Callback aufruft. Vor ein paar Jahren habe ich auch einen entsprechenden Artikel geschrieben, aber der Fortschritt ist sehr langsam: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...Es ist interessant genug, dass ich gern mehr Zeit investieren würde, aber da ich es nicht in meinem Hauptjob brauche, arbeite ich nur stückweise daran, wenn ich am Wochenende Lust zum Coden habe.
Die Beispielästhetik sieht aus, als wäre sie direkt aus den 90ern übernommen worden, wie [0]. Für Prototypen oder interne Tools für Leute, die keine CLI verwenden können, ist das perfekt, aber ich frage mich, was man tun soll, wenn man eine gut aussehende UI braucht.
In Sachen Performance ist eine native UI immer gut, aber ich hatte immer den Eindruck, dass Styling schwieriger ist als bei Webseiten. Ich frage mich, was in Python-GUIs dem Paket aus gestylten Komponenten entspricht, das wie Flutter oder SwiftUI ohne großen Aufwand modern aussieht.
[0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...
Zumindest die vom Betriebssystem bereitgestellten Standard-UI-Stile können Menschen in einer App lernen und auf andere Apps übertragen. Da ich kein herausragender UI-Designer bin, ist die Wahrscheinlichkeit groß, dass die Betriebssystem-Defaults besser sind als alles, was mir einfallen würde. Wenn dann noch der Satz dazukommt, den man im Marketing fürchtet – „Unsere Software sieht alt aus“ –, steigen die Entwicklungskosten auf ein ohnehin kaum noch tragbares Niveau.
Solche Software gab es auch in den 90ern, aber das ist nicht die Ästhetik der 90er, von der die Leute üblicherweise sprechen. In das UI-Design von Windows 95 ist viel Arbeit geflossen.
Die großen Leerflächen heutiger UIs, Buttons, die nicht wie Buttons aussehen, verschwindende Scrollbars und Hamburger-Menüs mag ich noch weniger.
Die Trennung von Frontend und Backend ist ebenfalls standardmäßig gegeben, und wenn man sie später braucht, ist auch Remote-Zugriff möglich. Wenn es sich wie eine native App nutzen lassen soll, reicht in einer kleinen Tkinter-artigen GUI auch ein einzelner Button „Open browser UI“. Wenn der Start-Button einen Token in die URL einfügt, kann man sich sogar gegen einen Daemon schützen, der als anderer Nutzer auf derselben Maschine läuft; ich habe allerdings noch nicht gesehen, dass das tatsächlich jemand so macht.
SystemDefaultForRealumstellt, sehen native Windows-Widgets modern aus, aber Tkinter wurde überhaupt nicht aktualisiert und wirkt deshalb befremdlich.Sieht in Ordnung aus. Allerdings ist diese Bibliothek vielleicht schon so ausgereift, dass größere Änderungen schwierig sind, aber es wäre gut, statt Listen Dictionaries zu verwenden. Neuere Python-Dictionaries merken sich die Einfügereihenfolge.
Bei einem früheren Arbeitgeber habe ich etwas Ähnliches als deutlich dünneren Wrapper über PyQt gebaut, und der Code war ebenfalls erstaunlich klein. Der wesentliche Unterschied war, dass das Setzen von Eigenschaften/Signalen und das Verschachteln von Widgets gemeinsam behandelt wurden. Statt Eigenschaften im Konstruktor zu setzen, hatte das den Vorteil, dass man Eigenschaften im Body der View-Definition setzen konnte, selbst wenn man später einen Widget-Namen brauchte, um den Text zu ändern. Eine einzige Funktion
setup_viewwar die gesamte API, und für das schnelle Erstellen einfacher GUIs war das ziemlich praktisch. Auch diese Bibliothek sieht nach einer guten Alternative aus, danke fürs Teilen.https://docs.python.org/3/whatsnew/3.7.html#summary-release-...
Data Binding sollte man besser dem Framework überlassen. Sowohl Web als auch Desktop bewegen sich zunehmend in diese Richtung. Statt Widgets direkt zu ändern, sollte man Widget-Eigenschaften an einen Datenspeicher binden und bei Änderungen automatisch neu rendern lassen. Das Eingabe-/Ausgabe-Beispiel auf der Seite zeigt etwas Ähnliches.
getElementById()verwendet inzwischen niemand mehr.Es scheint der Benutzerfreundlichkeit von VB6 oder Delphi/Lazarus näherzukommen. Es gibt definitiv Fortschritte, und jetzt bräuchte es nur noch einen interaktiven GUI-Builder, dann könnte man die erstellten Forms per
#importdirekt verwenden und wäre fertig.Vor ein paar Jahren habe ich versucht, WxPython zusammen mit WxFormBuilder zu verwenden, und dabei im Projekt enorm viel Zeit verloren. Schon kleine Änderungen am Formular haben das gesamte Backend kaputtgemacht, und obwohl ich selbst dünnen Glue-Code für die Zwischenschicht geschrieben hatte, ging wieder alles kaputt, als ich den Typ eines Feldes änderte. Gut, dass so etwas hier wohl nicht passieren wird.
Aus Sicht der Entwicklung einer Python-GUI-Anwendung [1] ist meiner Meinung nach das größte Problem bei Python für Desktop-Apps das Packaging.
Die bestehenden Tools zum Erstellen auslieferbarer Binaries funktionieren oft nicht mehr oder erfordern erhebliche Hacks, sobald mehr als ein paar Abhängigkeiten im Spiel sind. Selbst bei beliebten Paketen treten schwer nachvollziehbare Probleme auf, etwa fehlende versteckte Imports oder unbemerkte fehlende Datendateien. Auch dynamisches Modulladen kann kaputtgehen, wenn man es aus der normalen Python-Umgebung heraus in etwas wie PyInstaller oder cx_freeze bringt. Ich weiß nicht, was man da tun kann, aber vielleicht braucht Python einen Standard für eigenständiges Anwendungs-Packaging, das ähnlich wie JARs in Java nur vom Interpreter abhängt.
Mit Tools wie shiv oder PEX kann man eine zipapp inklusive Anwendungsabhängigkeiten erstellen, aber wenn binäre Erweiterungen dabei sind, bleibt das Artefakt weiterhin plattformspezifisch: https://github.com/linkedin/shiv#gotchas
Für meine Python-Programme empfehle ich Nutzern die Installation über pipx: https://github.com/pypa/pipx
Wenn die Zielnutzer auch nur ein wenig technisch sind, halte ich das für die beste Wahl. Es vermeidet Versionskonflikte von
pip install --userund den Aufwand, pro App manuell virtuelle Umgebungen anzulegen, und bietet insgesamt eine ordentliche User Experience. Wenn man pipx als Standard-Installationsmethode empfiehlt, kann man erwarten, dass die Leute die Installation schaffen. Mein Programm hat zwar binäre Abhängigkeiten, aber keine GUI.Persönlich gefällt mir CustomTKinter besser. Es ist deutlich eleganter, hat ein Aussehen wie ein Material-Theme und unterstützt unter Windows/Linux/macOS je nach Systemeinstellung Light-/Dark-Themes.
Es ist erstaunlich, dass im Bereich schneller Anwendungsentwicklung immer noch nichts die von VB6 hinterlassene Lücke wirklich gefüllt hat. Die Sprache selbst war nicht großartig, aber die Stärke von VB6 war der Drag-and-drop-GUI-Builder.
https://www.lazarus-ide.org/
https://gambas.sourceforge.net/en/main.html
https://qb64.com/inform.html
Praktischerweise kann man Layout-Dateien einfach neben das Python-Skript legen und sie dann in pyqt verwenden. Die Python-Unterstützung der IDE ist nicht gut, aber vielleicht liegt das auch daran, dass meine Installation kaputt ist.
https://xojo.com/
Ich überlege, einem Tool mit einem ziemlich gut gemachten CLI-Interface eine GUI überzustülpen, damit es auch Menschen nutzen können, die kein Desktop-Linux verwenden. PySimpleGUI könnte genau zu meinen Anforderungen passen
https://github.com/hiAndrewQuinn/finstem
Mein Tool hat gut definierte CSV-, TSV- und JSON-Flags. Mich würde interessieren, ob jemand Erfahrung damit hat, eine GUI über ein bestehendes, vollständiges CLI-Tool zu bauen, ohne dieses zu verändern, und welche Schwierigkeiten ich erwarten sollte
Engine und GUI folgen Protokollen wie WinBoard oder UCI[2] und tauschen über STDIN/STDOUT Textbefehle aus. Die Hauptschwierigkeiten sind dieselben wie beim Multithreading: Es kann zu Deadlocks kommen, bei denen GUI und CLI jeweils darauf warten, dass die andere Seite weitermacht. Deshalb sollten beide Seiten Ein- und Ausgabe in separaten Threads von der „Business-Logik“ verarbeiten, um reaktionsfähig zu bleiben. Ein weiteres häufiges Problem sind betriebssystemspezifische Eigenheiten beim Umgang mit Pipes; man muss also auf Buffer-Flushes und API-Unterschiede zwischen Linux, Mac und Windows achten
[0] http://hgm.nubati.net/
[1] http://www.playwitharena.de/
[2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
Ich hoffe, das klingt nicht unhöflich, aber es ist zu viel Text. Überall, wo Text stehen kann, stehen lange Sätze, die meistens zwar konsistent sind, aber in den ersten tausend Wörtern gibt es keinen einzigen relevanten Screenshot
Irgendetwas wirkt daran schief. Es fühlt sich an, als wäre es entweder ein junger, enthusiastischer Entwickler, oder als hätte jemand sehr viel Text eingefügt, um einen zur Nutzung zu überreden. Im README gibt es sogar einen „About me“-Abschnitt, in dem der Autor sich vorstellt. Als Beispiel: Scroll an irgendeine Stelle im README, lies ein paar Absätze und versuche dann wiederzugeben, was du gerade gelesen hast
Manche Leute lesen gern über ein Tool, statt mit der Haltung heranzugehen: „Wie führe ich es mit möglichst wenigen gelesenen Wörtern möglichst schnell aus?“ Du nutzt kostenlos ein Tool, das jemand anderes gebaut hat; hör also auf zu meckern und lass die Leute sich so ausdrücken, wie sie möchten
[1] https://github.com/PySimpleGUI/PySimpleGUI#about-me-
Ich hoffe, das ist nicht unhöflich, aber ich würde zurückfragen, ob du vielleicht schon vor der bloßen Tatsache zurückschreckst, einen Text lesen zu müssen, wenn er dir nicht als Schritt-für-Schritt-Zusammenfassung mundgerecht serviert wird
Den gleichen Gedanken hätte man auch mit „Bei einem visuellen Projekt würde ich erwarten, dass die Hauptbeschreibung mehr Screenshots enthält“ ausdrücken können, ohne beleidigende Mutmaßungen anzustellen
Wenn man Wörter wie Smart, Open, Trusted oder Secure in einen Projektnamen packt, ist es für Leute leicht, darauf hinzuweisen, dass das Projekt dem Ideal seines Namens nicht gerecht wird. Namen wie C oder BSD dagegen haben kein Gegenteil und keine solche Konnotation, sodass es schwer ist zu sagen: „Die Sprache C wird ihrem Namen nicht gerecht.“