Actualités techniques autour de PySimpleGUI

 (github.com/PySimpleGUI)
4 points par GN⁺ 2023-12-11 | 1 commentaires | Partager sur WhatsApp
  • Après avoir mis fin à sa tentative de commercialisation, PySimpleGUI a supprimé les composants de licence et de sécurité du code de PySimpleGUI 5, puis a été republié sur GitHub et PyPI sous la forme de PySimpleGUI 6 avec une licence LGPL3
  • La dernière version peut être installée avec python -m pip install PySimpleGUI, et l’ancienne version 4.60.5.1, la branche master sur GitHub ou une version spécifique comme 6.1 peuvent aussi être installées directement avec pip
  • PySimpleGUI est présenté comme un wrapper de bibliothèques GUI telles que tkinter, qui transforme les SDK GUI en une structure plus simple et plus compacte tout en offrant une personnalisation fine, sans nécessiter d’expérience préalable en programmation GUI
  • La version 6.2 inclut une correction de bug de Window.settings_save, l’affichage inline d’images dans Multiline, psgupgrade, la sélection programmatique de nœuds Tree, des minuteurs sous forme de chaîne "H:M:S" pour Window.start_timer, le réglage de la couleur de bordure des Frame, etc.
  • Le projet est maintenu sans accepter de pull requests ; son avenir à long terme est incertain, mais l’auteur indique vouloir continuer à écrire du code et à organiser l’écosystème

La remise en open source de PySimpleGUI 6

  • PySimpleGUI a tenté une commercialisation, mais n’a pas réussi à générer les ressources nécessaires pour maintenir le projet au niveau espéré
  • En février 2025, la fermeture de PySimpleSoft et la poursuite du support jusqu’à fin 2025 ont été annoncées ; il restait ensuite à décider quoi faire du code, de la documentation et des dépôts
  • Le code de PySimpleGUI 5 a été publié sur GitHub et PyPI après suppression des composants de licence et de sécurité
  • La nouvelle version publique utilise une licence LGPL3
  • Le cours Udemy sera disponible gratuitement pendant un certain temps, avec le code promo 033334A16163C571B739

Méthodes d’installation

  • Installer la dernière version v6 depuis PyPI :
    • python -m pip install PySimpleGUI
  • Installer l’ancienne version 4.60.5.1 :
    • python -m pip install PySimpleGUI==4.60.5.1
  • Le code le plus récent du dépôt GitHub peut être installé directement :
  • Pour installer une version précise depuis GitHub, remplacer master par le numéro de version :
  • Il est aussi possible de cloner ou télécharger le dépôt puis d’effectuer une installation locale :
    • python -m pip install .

Le rôle de PySimpleGUI

  • PySimpleGUI est un wrapper autour de tkinter et d’autres bibliothèques GUI
  • Il transforme les SDK GUI en une structure plus simple et plus compacte tout en offrant une personnalisation fine
  • Il est présenté comme ne nécessitant pas d’expérience préalable en programmation GUI
  • L’exemple du README construit une application de fenêtre interactive avec seulement Text, Input, Button, Window, une boucle d’événements, window.read() et window.close()
  • La documentation est disponible sur Docs.PySimpleGUI.com

Mode de développement et perspectives à long terme

  • PySimpleGUI est décrit comme ayant été développé d’une manière plus proche d’un produit propriétaire que d’un projet open source traditionnel
  • Les pull requests ne sont pas acceptées
  • L’avenir à long terme n’est pas certain, mais l’auteur actuel apprécie d’écrire du code et d’aider les autres
  • L’expérience PySimpleGUI est décrite comme une expérience “once-in-a-lifetime”, car elle a permis de voir ce que les gens ont créé

Fonctionnalités et corrections de la version 6.2

  • La version 6.2 inclut une correction de bug de Window.settings_save
  • Une fonctionnalité a été ajoutée pour “print” des images inline dans l’élément Multiline
  • La fonctionnalité de mise à niveau vers la dernière version de maintenance est de nouveau intégrée à PySimpleGUI
    • Il est possible d’utiliser la Home Window ou la commande psgupgrade
    • Les notes de version peuvent être consultées et une nouvelle version peut être installée
  • Le bug #5750, où les événements Graph entraient dans une boucle infinie à la réception d’événements write_event_value, a été corrigé
    • La correction consiste à effacer le flag de bouton en temps réel
    • Il est indiqué que le risque de régression est faible, car la portée du changement se limite à la condition de l’élément Graph
  • Le paramètre select_node_keys a été ajouté à Tree.update, permettant de sélectionner des nœuds d’arbre par programmation comme si l’utilisateur les avait sélectionnés
  • La fonctionnalité et le paramètre echo_stdout_stderr de Multiline ont été corrigés
    • L’écho ne se fait que si stdout ou stderr a été redirigé vers cet élément
    • Cette fonctionnalité n’effectue pas elle-même la redirection
  • La correction #6686 résout un problème où le bouton Calendar chooser effaçait un champ qui ne devait être vidé qu’au moment du retour de window.read
  • Le numéro de version de la release de maintenance est affiché dans la Home Window et la position du bouton d’installation a été déplacée
  • Lors de l’appel à Window.start_timer, il est possible de définir un minuteur sous forme de chaîne "H:M:S"
  • Une fonctionnalité prenant uniquement en charge le défilement horizontal a été ajoutée aux éléments Column défilables
  • Les paramètres border_color et border_width_no_relief ont été ajoutés à l’élément Frame, permettant de définir la couleur de la bordure
    • Si aucune configuration distincte n’est fournie, la couleur de bordure d’une Frame utilise par défaut la couleur de l’élément texte
  • La section de référence des appels de la documentation a été mise à jour pour la version 6.2

Glisser-déposer et projets connexes

  • Le glisser-déposer est décrit comme une fonctionnalité attendue de longue date, et une méthode pour l’implémenter dans l’espace du code utilisateur, sans modifier le code de PySimpleGUI, aurait été trouvée
  • psgdnd est un nouveau package qui ajoute le glisser-déposer à PySimpleGUI
    • Il peut être installé et utilisé via pip
    • Davantage d’informations et d’exemples se trouvent dans le dépôt correspondant
  • psgdnd 6.0.1 a été publié sur PyPI et fonctionne sous Windows
  • La version 6.0.2 sur GitHub inclut les corrections nécessaires pour Linux
  • L’état du support Mac n’est pas encore connu
  • Le dépôt PSGMicroPython ajoute du code pour s’interfacer avec des microcontrôleurs basés sur MicroPython
    • Il fonctionne avec Raspberry Pi Pico et ESP32
    • Il pourrait fonctionner avec d’autres cartes
    • Il n’est pas conçu comme un projet robuste ou de grande ampleur, mais comme du code qui peut être utile

Prototype PSGWeb

  • PSGWeb est un prototype qui exécute PySimpleGUI dans une fenêtre de navigateur
  • Il fonctionne avec la plupart des programmes de démonstration
  • En ajoutant psgweb.us devant l’URL d’une application PySimpleGUI sur GitHub, il est possible d’essayer de l’exécuter
  • PSGWeb a été créé dans le cadre du travail plus large sur PSG 5, mais n’a pas été publié
  • Il n’est pas prévu de publier ni d’étendre ce prototype

Position sur l’usage de l’IA

  • L’auteur utilise les LLM pour rechercher et résumer de la documentation, rechercher des erreurs, enquêter et acquérir des connaissances
  • Il n’écrit pas de code avec des LLM
  • La raison donnée est simplement qu’il aime écrire du code
  • Il explique aussi que s’il n’a pas ouvert le projet aux pull requests, c’est parce qu’il voulait écrire le code lui-même plutôt que de laisser d’autres personnes le faire
  • Quant à la pertinence de PySimpleGUI à l’ère de l’IA, il estime qu’il suffit que des personnes découvrent, installent et utilisent PySimpleGUI chaque jour, ne serait-ce qu’une seule
  • L’auteur dit qu’il lui est difficile d’imaginer créer des applications Windows sans PySimpleGUI
    • Il explique avoir récemment construit un analyseur de bus pour un ordinateur 6502 sur breadboard, avec deux Raspberry Pi Pico et une application PySimpleGUI
    • Il dit avoir pu créer facilement avec PySimpleGUI une application frontend sous Windows pour contrôler l’outil

Histoire du projet et problèmes de financement

  • PySimpleGUI a commencé en 2018 comme du code ponctuel créé parce qu’une GUI était nécessaire pour un prototype de lecteur multimédia
  • L’objectif était d’envelopper Tkinter d’une manière plus linéaire et intuitive, afin d’obtenir rapidement quelque chose de fonctionnel sans expérience des frameworks GUI orientés objet
  • L’auteur l’a publié sur GitHub sans expérience de Python ni de l’open source, et a abordé le projet davantage comme une startup que comme un projet open source traditionnel
  • Chronologie :
    • Juillet 2018 : Version 1
    • Juin 2019 : Version 4
    • Janvier 2020 : le financement devient une préoccupation majeure et la commercialisation est évoquée
    • Novembre 2020 : annonce du cours Udemy et ajout d’une demande d’aide publique
    • Décembre 2021 : lancement du cours
    • Février 2024 : lancement commercial de la Version 5
    • Avril 2026 : Version 6
  • L’Announcements Issue sur GitHub a été utilisé comme un blog conservant l’historique du projet, et a dépassé les 1 700 entrées
  • Pour faciliter la lecture, un instantané a été publié dans l’onglet Announcements 2018-2024 de la documentation
  • Le travail open source à temps plein a créé une pression financière immédiate et continue
  • Les parrainages et dons via GitHub Sponsors et Buy Me a Coffee ont atteint, même au plus haut, environ 150 dollars par mois
  • Le cours Udemy de 61 leçons et 11,5 heures est brièvement monté à environ 2 000 dollars par mois au début, avant de tomber sous les 100 dollars
  • Aucune des deux approches n’a été suffisante pour maintenir le projet sur le long terme

Résultats de la commercialisation et expérience de licence

  • Le lancement payant de la Version 5 n’a pas été une décision soudaine : il avait été discuté publiquement pendant des années dans le README et les annonces
  • Début 2024, après avoir épuisé les autres options, la version commerciale a été lancée
  • L’objectif était de maintenir l’accessibilité plutôt que d’ériger des barrières
  • Du point de vue de la viabilité financière, cela n’a pas bien fonctionné, mais en termes d’expérience, d’apprentissage et de relations, l’auteur estime que cela en valait la peine
  • Après la commercialisation, PySimpleGUI n’a pas perdu la plupart de ses utilisateurs, et de nombreuses entreprises ont continué à l’utiliser
  • Le problème était de convaincre les entreprises d’acheter des licences
  • Le choix s’est porté sur une Hobbyist License, dans laquelle les utilisateurs amateurs et les étudiants pouvaient l’utiliser gratuitement, tandis que les entreprises devaient payer
  • En pratique, la grande majorité des utilisateurs se sont identifiés comme amateurs
  • Des dizaines de milliers d’utilisateurs en entreprise se sont inscrits au niveau gratuit, et il n’était pas rare que de grandes entreprises comptent des centaines d’utilisateurs mais seulement quelques licences payantes
  • L’auteur indique ne pas regretter la décision d’avoir proposé une option gratuite
  • Sa conclusion personnelle est qu’il existe une forte attente culturelle selon laquelle les outils et bibliothèques Python devraient être gratuits
  • Le prix ou les plaintes ne semblaient pas être le cœur du problème ; les gens continuaient à utiliser PySimpleGUI, mais ne ressentaient pas l’obligation de payer
  • Même des conditions de licence claires n’ont pas toujours modifié les comportements

Licence actuelle

  • La mention de copyright est Copyright 2018-2026 PySimpleGUI. All rights reserved.
  • La licence actuelle est LGPL3

À lire aussi

1 commentaires

 
GN⁺ 2023-12-11
Avis sur Hacker News

  • Au travail, je devais enregistrer mon temps de travail dans Jira, mais je n’aimais pas devoir garder le site web ouvert en permanence, et le processus consistant à trouver le ticket sur lequel je travaillais, trouver le lien d’enregistrement du temps et ajouter un commentaire était lent.
    Je voulais une application desktop avec la liste des tickets qui m’étaient assignés et des boutons pour ajouter un commentaire/du temps de travail. Avec Tkinter, j’ai longtemps galéré à obtenir quelque chose de joli, mais après avoir découvert PySimpleGUI, j’ai pu y raccorder les hooks de l’API Jira et créer ce que je voulais ; c’était un bon projet pour apprendre le développement d’UI.

    • Jira semble si universellement lent que beaucoup de gens cherchent à le contourner avec des outils sur mesure.
      Un ami m’a aussi dit qu’à l’un de ses postes il avait créé un client Qt interne pour les opérations Jira de base, et quand j’ai dû suivre mon travail avec Jira, j’ai utilisé https://github.com/go-jira/jira pour gérer les changements via plusieurs scripts console.
    • Quand on m’a dit qu’on allait commencer à enregistrer le temps dans Jira au travail, j’ai commencé à chercher un nouveau poste.
    • Je me demande si le source de cette appli est publié quelque part. Je pensais justement créer quelque chose de similaire cette semaine ; ce serait vraiment bien de pouvoir simplement pointer une appli existante vers notre instance Jira.
    • Je me demande si c’est vraiment de l’apprentissage du développement d’UI. Je ne sais pas trop si cela peut mener à des projets plus exigeants, ou s’étendre dans cette direction.

  • Ces frameworks GUI me semblent vraiment prometteurs. Une expérience desktop native est bien meilleure qu’un assemblage de webviews, et la boucle d’événements simplifiée de PySimpleGUI ainsi que son approche multi-backends me semblent réellement nouvelles.
    Cela dit, je me demande pourquoi il n’existe pas davantage de « GUI automatiques » auxquelles on fournirait simplement des structures de données et des fonctions, et qui généreraient automatiquement une interface adaptée pour les manipuler. En choisissant par heuristique si les panneaux doivent être verticaux/horizontaux, sous forme d’onglets ou de pop-ups, on pourrait ouvrir beaucoup de fonctionnalités trop imbriquées pour une CLI et trop natives pour en faire une appli web.

    • Un projet qui pourrait vous intéresser : Gooey dit « transformer presque n’importe quel programme console Python 3 en application GUI avec une seule ligne ».
      https://github.com/chriskiehl/Gooey
    • En 2011, j’ai créé un générateur automatique de formulaires pour le web à partir des arguments de fonctions, et plus récemment j’ai aussi fait un peu quelque chose de similaire dans une boîte à outils GUI basée sur le langage D.
      On peut définir une structure et la passer à la fonction dialog, qui génère automatiquement une boîte de dialogue adaptée aux champs de la structure et appelle un callback lorsque l’utilisateur clique sur OK. Des attributs personnalisés permettent aussi de spécifier quel widget utiliser : par exemple, si l’on ajoute @ControlledBy!VerticalSlider(0, 100) à un int, on obtient un curseur de 0 à 100 au lieu d’un champ de saisie numérique. On peut aussi annoter des fonctions de menu avec quelque chose comme @menu("Search") Find(string text) { ... } pour générer automatiquement le menu et la boîte de dialogue, et il existe aussi un DataControllerWidget qui appelle un callback à chaque événement de changement. J’ai écrit un article à ce sujet il y a quelques années, mais ça avance très lentement : http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...
      C’est assez intéressant pour que j’aie envie d’y consacrer plus de temps, mais comme je n’en ai pas l’usage dans mon travail principal, je n’y touche que par petites sessions le week-end quand j’ai envie de coder.
    • Il y avait il y a plusieurs décennies quelque chose qui correspond à cette description, appelé Naked Objects. Je ne l’ai pas utilisé parce que Java ne m’intéressait pas trop, mais ça avait l’air utile.
    • En Python, TraitsUI était une bonne « UI automatique », et joue encore ce rôle aujourd’hui.

  • L’esthétique des exemples semble tout droit sortie des années 90, comme [0]. C’est parfait pour du prototypage ou des outils internes destinés à des gens qui ne peuvent pas utiliser une CLI, mais je me demande quoi faire quand on a besoin d’une UI agréable à regarder.
    Côté performances, une UI native est toujours préférable, mais j’ai toujours trouvé qu’elle était plus difficile à styliser qu’une page web. Je me demande quel est, dans les GUI Python, l’équivalent de bibliothèques de composants stylisés qui paraissent modernes sans gros effort, comme Flutter ou SwiftUI.
    [0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...

    • C’est certes une question de savoir-faire, mais d’après mon expérience, les UI « stylisées » sont l’une des raisons pour lesquelles beaucoup de logiciels et leurs utilisateurs se retrouvent avec un logiciel moins bon.
      Au minimum, le style d’UI par défaut fourni par le système d’exploitation permet aux gens de transférer ce qu’ils ont appris d’une appli à une autre. Comme je ne suis pas un excellent designer d’UI, il y a de fortes chances que les valeurs par défaut du système soient meilleures que ce que je pourrais imaginer. Ajoutez à cela la phrase que le marketing redoute d’entendre — « notre logiciel a l’air vieux » — et les coûts de développement augmentent jusqu’à un niveau déjà difficile à supporter.
    • Le look années 90 en soi ne me dérange pas, mais ceci ne correspond même pas au style des systèmes d’exploitation des années 90. L’arrière-plan des cases à cocher est incorrect, le libellé de titre en haut est désaligné, et l’emplacement du bouton Exit est étrange ; dans l’ensemble, ça ressemble à une UI mal conçue.
      Il existait bien ce genre de logiciels dans les années 90, mais ce n’est pas l’esthétique des années 90 dont les gens parlent généralement. Beaucoup d’efforts ont été consacrés au design de l’UI de Windows 95.
    • Je ne vois pas quel est le problème avec le look années 90. Beaucoup de gens l’aiment.
      Je déteste davantage les UI modernes avec leurs grands espaces vides, leurs boutons qui ne ressemblent pas à des boutons, leurs barres de défilement qui disparaissent et leurs menus hamburger.
    • Si l’apparence est la priorité absolue, il semble assez difficile de battre une page web.
      La séparation frontend/backend est également acquise par défaut, et un accès distant est possible plus tard si nécessaire. Si l’on veut une expérience proche d’une appli native, il suffit de mettre un bouton « Open browser UI » dans une petite GUI de type Tkinter. Si le bouton de lancement place un jeton dans l’URL, on peut même se protéger d’un démon lancé par un autre utilisateur sur la même machine, même si je n’ai jamais vu personne faire réellement cela.
    • Le problème, c’est que Tkinter repose vraiment, au moins sous Windows, sur des widgets des années 90. Même en changeant le thème PySimpleGUI pour SystemDefaultForReal, les widgets Windows natifs ont une apparence moderne, mais Tkinter n’a pas du tout été mis à jour et paraît décalé.

  • Ça a l’air correct. Cela dit, même si cette bibliothèque est déjà mature et que de gros changements peuvent être difficiles, ce serait bien d’utiliser des dictionnaires plutôt que des listes. Les dictionnaires Python récents conservent l’ordre d’insertion
    Dans un ancien poste, j’avais créé quelque chose de similaire par-dessus PyQt, avec un wrapper beaucoup plus fin, et le code était étonnamment réduit. La différence essentielle était qu’il gérait à la fois la configuration des propriétés/signaux et l’imbrication des widgets. Par rapport à une approche où l’on définit les propriétés dans le constructeur, l’avantage était de pouvoir les définir dans le corps de la définition de la vue, même si l’on avait besoin du nom du widget plus tard pour changer le texte. Une seule fonction setup_view constituait toute l’API, et c’était assez pratique pour créer rapidement de petites interfaces graphiques. Cette bibliothèque semble aussi être une bonne alternative, merci de l’avoir partagée

    • Ce changement est arrivé avec Python 3.7, et c’est maintenant une fonctionnalité qui a plus de cinq ans
      https://docs.python.org/3/whatsnew/3.7.html#summary-release-...
    • Si l’on regarde les tendances récentes des frameworks GUI, la séparation de la mise en page et des données produit un code nettement plus propre
      Il vaut mieux laisser le framework gérer le data binding. Le Web comme le desktop vont de plus en plus dans cette direction. Plutôt que de modifier directement les widgets, il faut lier leurs propriétés à un magasin de données et déclencher un nouveau rendu automatique en cas de changement. Les exemples d’entrée/sortie de la page montrent quelque chose de similaire. Plus personne n’utilise getElementById() désormais
    • D’après la page GitHub, la « définition des fenêtres a été simplifiée en utilisant les types de données Python de base que les débutants comprennent, à savoir les listes et les dictionnaires »

  • On dirait que cela se rapproche de la facilité d’utilisation de VB6 ou de Delphi/Lazarus. Il y a clairement des progrès, et il ne manque plus qu’un constructeur de GUI interactif permettant de #import les formulaires créés et de les utiliser directement
    Il y a quelques années, j’ai perdu énormément de temps sur un projet en essayant d’utiliser WxPython avec WxFormBuilder. Le moindre petit changement dans un formulaire cassait tout le backend, et même après avoir écrit moi-même une fine couche de liaison intermédiaire, tout a de nouveau cassé quand j’ai changé le type d’un champ. Je suis content de voir qu’ici ce genre de chose ne devrait pas arriver

  • En tant que personne qui développe une application GUI Python [1], je pense que le plus gros problème quand on utilise Python pour des applications desktop est le packaging
    Les outils existants pour produire des binaires distribuables cessent de fonctionner dès qu’il y a plus que quelques dépendances, ou nécessitent des bidouilles non négligeables. Même avec des paquets populaires, on se retrouve avec des problèmes obscurs comme des imports cachés manquants ou des fichiers de données oubliés dont on ignorait l’existence. Le chargement dynamique de modules peut aussi casser lorsqu’on sort de l’environnement Python classique, avec PyInstaller ou cx_freeze par exemple. Je ne sais pas vraiment ce qu’on pourrait faire, mais Python aurait peut-être besoin d’un standard de packaging pour programmes autonomes qui ne dépendent que de l’interpréteur, à la manière des JAR en Java

    1. https://github.com/FreeLanguageTools/vocabsieve
    • Python dispose de zipapp, standardisé et assez comparable aux JAR : https://peps.python.org/pep-0441/
      On peut créer des zipapps incluant les dépendances de l’application avec des outils comme shiv ou PEX, mais s’il y a des extensions binaires, l’artefact reste spécifique à une plateforme : https://github.com/linkedin/shiv#gotchas
      Pour mes programmes Python, je recommande aux utilisateurs de les installer avec pipx : https://github.com/pypa/pipx
      Si le public visé est un minimum technique, je pense que c’est le meilleur choix. Cela évite les conflits de versions de pip install --user et la corvée de créer manuellement un environnement virtuel par application, tout en offrant une expérience utilisateur globalement correcte. On peut recommander pipx comme méthode d’installation par défaut et s’attendre à ce que les gens réussissent l’installation. Mon programme a des dépendances binaires, mais pas de GUI

  • Personnellement, je préfère CustomTKinter. C’est beaucoup plus élégant, avec une apparence proche des thèmes Material, et cela prend en charge les thèmes clair/sombre selon les paramètres système sous Windows/Linux/macOS

  • Il est étonnant que rien n’ait encore vraiment comblé le vide laissé par VB6 dans le domaine du développement rapide d’applications. Le langage lui-même n’était pas excellent, mais la force de VB6, c’était son constructeur de GUI en glisser-déposer

    • Comme quelqu’un d’autre l’a dit, Lazarus mérite d’être envisagé, et si l’on veut une expérience plus proche de VB, Gambas peut aussi être intéressant
      https://www.lazarus-ide.org/
      https://gambas.sourceforge.net/en/main.html
    • Le même paradigme consistant à stocker l’interface dans des fichiers modifiables à la main
      https://qb64.com/inform.html
    • https://www.lazarus-ide.org/
    • J’ai utilisé qtcreator bien plus longtemps que prévu à cause de la conception d’UI en glisser-déposer
      Pratique : il suffit de placer le fichier de mise en page à côté du script Python pour pouvoir l’utiliser avec pyqt. Le support Python de l’IDE n’est pas très bon, mais c’est peut-être mon installation qui est cassée
    • Xojo est en fait le successeur spirituel de VB6
      https://xojo.com/

  • J’envisage de greffer une GUI sur un outil qui dispose déjà d’une interface CLI assez bien conçue, afin que des personnes qui n’utilisent pas Linux sur desktop puissent aussi s’en servir. PySimpleGUI pourrait parfaitement répondre à mon besoin
    https://github.com/hiAndrewQuinn/finstem
    Mon outil a des flags CSV, TSV et JSON bien définis. Je me demande si certains ont déjà créé une GUI au-dessus d’un outil CLI complet existant sans le modifier, et quelles difficultés il faut anticiper

    • Les moteurs d’échecs sont un bon cas de référence. La partie décisionnelle est en CLI et se branche sur des GUI comme WinBoard[0] ou Arena[1]
      Le moteur et la GUI suivent un protocole comme WinBoard ou UCI[2], et échangent des commandes textuelles via STDIN/STDOUT. La principale difficulté est la même qu’en multithreading : des blocages peuvent apparaître si la GUI et la CLI s’attendent mutuellement. Il faut donc, des deux côtés, traiter les entrées/sorties dans des threads séparés de la « logique métier » afin de conserver la réactivité. Un autre problème courant est que la gestion des pipes varie selon les systèmes d’exploitation : il faut faire attention au flush des buffers et aux différences d’API entre Linux, Mac et Windows
      [0] http://hgm.nubati.net/
      [1] http://www.playwitharena.de/
      [2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
    • Par exemple, on peut regarder HandBrake. C’est assez proche d’une UI sophistiquée pour ffmpeg

  • J’espère ne pas paraître impoli, mais il y a trop de texte. Partout où il est possible de mettre du texte, il y a de longues phrases, et même si l’ensemble est plutôt cohérent, il n’y a pas une seule capture d’écran pertinente dans les mille premiers mots
    Quelque chose semble décalé. On a l’impression que c’est soit un jeune développeur enthousiaste, soit quelqu’un qui a ajouté beaucoup de texte pour convaincre d’essayer l’outil. Le README contient même une section « about me » où l’auteur se présente. Un exemple serait de descendre à n’importe quel endroit du README, de lire quelques paragraphes, puis d’essayer de reformuler ce qu’on vient de lire

    • Chaque section a un titre clair. Si une section ne vous intéresse pas, il suffit de scroller un peu. Personne ne vous oblige à lire la section « about me »
      Certaines personnes aiment lire au sujet d’un outil, plutôt que d’avoir pour seule attitude « comment exécuter ça le plus vite possible en lisant le minimum de mots ». Comme vous utilisez gratuitement un outil créé par quelqu’un d’autre, mieux vaut arrêter de se plaindre et le laisser s’exprimer comme il le souhaite
    • L’hypothèse du « jeune développeur enthousiaste » est fausse. Dans « About Me » [1], il est écrit qu’il écrit des logiciels depuis les années 70 et qu’il a passé l’essentiel de sa carrière à créer des produits dans la Silicon Valley
      [1] https://github.com/PySimpleGUI/PySimpleGUI#about-me-
    • J’ai simplement parcouru le tout. Ce n’est pas le MVP d’un produit destiné à attirer des investisseurs, c’est un outil dont la personne qui l’a créé a rédigé elle-même la documentation
      J’espère ne pas paraître impoli, mais je me demande si, à moins qu’on ne vous serve un résumé étape par étape à la cuillère, vous n’avez pas tout simplement peur de devoir lire
    • Je trouve la formulation assez impolie. Surtout parce que vous réduisez les raisons possibles de la quantité de texte à deux options seulement, et qu’aucune des deux ne sonne très favorablement. En plus, ces raisons ne semblent même pas justes
      La même idée aurait pu être formulée ainsi : « pour un projet visuel, je pense qu’il devrait y avoir davantage de captures d’écran dans la description principale », sans ajouter de suppositions insultantes
    • Le problème vient peut-être du fait d’avoir appelé le projet Simple. Cela installe dans l’esprit du lecteur un préjugé sur ce à quoi il doit s’attendre
      Si l’on met des mots comme Smart, Open, Trusted ou Secure dans le nom d’un projet, les gens auront facilement tendance à relever qu’il n’atteint pas l’idéal porté par son nom. À l’inverse, des noms comme C ou BSD n’ont pas de contraire ni d’implication particulière, ce qui rend difficile de dire que « le langage C ne mérite pas son nom »