Novidades técnicas sobre o PySimpleGUI
(github.com/PySimpleGUI)- Após encerrar a tentativa de comercialização, o PySimpleGUI removeu os componentes de licença e segurança do código do PySimpleGUI 5 e foi republicado no GitHub e no PyPI como PySimpleGUI 6 sob licença LGPL3
- A versão mais recente pode ser instalada com
python -m pip install PySimpleGUI, e também é possível instalar diretamente via pip a versão anterior4.60.5.1, omasterdo GitHub ou um release específico como6.1 - O PySimpleGUI é apresentado como um wrapper de bibliotecas GUI como tkinter, que torna o SDK de GUI mais simples e compacto, mantendo opções de personalização detalhada, sem exigir experiência prévia com programação GUI
- A versão 6.2 inclui correção do bug em
Window.settings_save, saída inline de imagens em Multiline,psgupgrade, seleção programática de nós em Tree, temporizador em string"H:M:S"paraWindow.start_timere configuração de cor de borda em Frame - O projeto continua sendo mantido sem aceitar pull requests, e embora o futuro de longo prazo seja incerto, o autor afirma que pretende continuar escrevendo código e organizando o ecossistema
Reabertura em open source do PySimpleGUI 6
- O PySimpleGUI tentou se comercializar, mas não conseguiu gerar os recursos necessários para sustentar o projeto no nível esperado
- Em fevereiro de 2025 foi anunciado o encerramento da PySimpleSoft e a continuidade do suporte até o fim de 2025, e depois disso restava decidir o que fazer com o código, a documentação e os repositórios
- O código do PySimpleGUI 5 foi publicado no GitHub e no PyPI após a remoção dos componentes de licença e segurança
- A nova versão pública usa a licença LGPL3
- O curso na Udemy ficará gratuito por algum tempo, e o código do cupom é
033334A16163C571B739
Como instalar
- Instalar a versão mais recente v6 pelo PyPI:
python -m pip install PySimpleGUI
- Instalar a versão anterior
4.60.5.1:python -m pip install PySimpleGUI==4.60.5.1
- O código mais recente do repositório no GitHub pode ser instalado diretamente:
python -m pip install --upgrade https://github.com/PySimpleGUI/PySimpleGUI/zipball/master
- Para instalar um release específico do GitHub, troque
masterpelo número do release:python -m pip install --upgrade https://github.com/PySimpleGUI/PySimpleGUI/zipball/6.1
- Também é possível clonar ou baixar o repositório e instalar localmente:
python -m pip install .
O papel do PySimpleGUI
- O PySimpleGUI é um wrapper para tkinter e outras bibliotecas GUI
- Ele torna o SDK de GUI mais simples e compacto, ao mesmo tempo em que oferece personalização detalhada
- É apresentado como algo que não exige experiência prévia com programação GUI
- O exemplo no README monta um app de janela interativa usando apenas
Text,Input,Button,Window, loop de eventos,window.read()ewindow.close() - A documentação está disponível em Docs.PySimpleGUI.com
Forma de desenvolvimento e perspectiva de longo prazo
- O PySimpleGUI é descrito como tendo sido desenvolvido de uma forma mais próxima de um produto proprietário do que de um projeto open source tradicional
- Não aceita pull requests
- O futuro de longo prazo não é certo, mas no momento o autor diz que gosta de escrever código e ajudar
- A experiência com o PySimpleGUI é descrita como algo “once-in-a-lifetime”, por permitir ver o que as pessoas criaram com ele
Recursos e correções da versão 6.2
- A 6.2 inclui correção do bug em
Window.settings_save - Foi adicionada a função de “printar” imagens inline em elementos Multiline
- A função de atualizar para o release de manutenção mais recente voltou a ser integrada ao PySimpleGUI
- É possível usar a Home Window ou o comando
psgupgrade - Dá para ver as notas de release e instalar a nova versão
- É possível usar a Home Window ou o comando
- Foi corrigido o bug #5750, em que um evento
Graphentrava em loop infinito ao receber um eventowrite_event_value- A correção foi feita limpando a flag de botão em tempo real
- Foi registrado que o alcance da mudança se limita à condição do elemento Graph, então o risco de regressão é pequeno
Tree.updaterecebeu o parâmetroselect_node_keys, permitindo selecionar nós da árvore programaticamente como se fosse uma seleção do usuário- A funcionalidade e os parâmetros de
echo_stdout_stderrdo Multiline foram corrigidos- Só faz echo quando stdout ou stderr tiverem sido redirecionados para o elemento correspondente
- Esse recurso não realiza o redirecionamento diretamente
- A correção #6686 resolveu um problema em que o botão do seletor de calendário limpava campos que só deveriam ser limpos no momento do retorno de
window.read - A Home Window agora mostra o número da versão do release de manutenção, e a posição do botão de instalação foi alterada
- Ao chamar
Window.start_timer, agora é possível definir o temporizador com uma string"H:M:S" - Foi adicionada a uma Column rolável a opção de suportar apenas rolagem horizontal
- O elemento Frame recebeu os parâmetros
border_coloreborder_width_no_relief, permitindo configurar a cor da borda- A cor da borda do Frame usa por padrão a cor do elemento de texto se não houver configuração separada
- A seção call reference da documentação foi atualizada para o release 6.2
Drag and drop e projetos ao redor
- Drag and drop é descrito como um recurso desejado há muito tempo, e foi descoberta uma forma de implementá-lo no espaço do código do usuário sem alterar o código do PySimpleGUI
psgdndé um novo pacote que adiciona drag and drop ao PySimpleGUI- Pode ser instalado e usado via pip
- Há mais informações e exemplos no repositório correspondente
psgdnd6.0.1 foi lançado no PyPI e funciona no Windows- A versão 6.0.2 no GitHub inclui a correção necessária para Linux
- O estado do suporte a Mac ainda é desconhecido
- O repositório
PSGMicroPythonrecebeu código para interface com microcontroladores baseados em MicroPython- Funciona no Raspberry Pi Pico e no ESP32
- Pode funcionar também em outras placas
- Não foi pensado como algo robusto ou para projetos grandes, mas como código que pode ser útil
Protótipo do PSGWeb
- O PSGWeb é um protótipo que executa o PySimpleGUI em uma janela de navegador
- Funciona com a maioria dos programas de demonstração
- É possível tentar executá-lo adicionando
psgweb.usantes da URL de uma aplicação PySimpleGUI no GitHub- Exemplo:
https://github.com/PySimpleGUI/PySimpleGUI/… - Exemplo convertido:
https://psgweb.us/github.com/PySimpleGUI/…
- Exemplo:
- O PSGWeb foi criado como parte de um trabalho maior do PSG 5, mas não foi publicado
- Não há planos de lançar ou expandir esse protótipo
Posição sobre o uso de IA
- O autor usa LLMs para busca e resumo de documentação, consulta de erros, pesquisa e aquisição de conhecimento
- Não usa LLMs para escrever código
- O motivo, segundo ele, é simplesmente que gosta de escrever código
- Ele também explica que o projeto não foi aberto a pull requests porque prefere escrever o código diretamente em vez de deixar que outras pessoas o façam
- Sobre a relevância do PySimpleGUI na era da IA, ele entende que basta que pessoas continuem descobrindo, instalando e usando o PySimpleGUI, mesmo que seja apenas mais de uma por dia
- O autor diz que é difícil imaginar criar apps Windows sem o PySimpleGUI
- Explica que, recentemente, em um trabalho com um computador 6502 em breadboard, criou um analisador de barramento com dois Raspberry Pi Pico e um app em PySimpleGUI
- Diz que conseguiu criar facilmente em PySimpleGUI um app frontend no Windows para controlar as ferramentas
História do projeto e problema de financiamento
- O PySimpleGUI começou em 2018 como um código de uso único criado por causa da necessidade de uma GUI para um protótipo de media player
- O objetivo era encapsular o Tkinter de uma forma mais linear e intuitiva, para fazê-lo funcionar rapidamente, mesmo sem experiência com frameworks GUI orientados a objetos
- O autor publicou no GitHub sem experiência prévia com Python nem com open source, e abordou o projeto mais como uma startup do que como um projeto open source tradicional
- Linha do tempo:
- Julho de 2018: Version 1
- Junho de 2019: Version 4
- Janeiro de 2020: o problema de financiamento se tornou a principal preocupação, e a comercialização passou a ser mencionada
- Novembro de 2020: anúncio do curso na Udemy e inclusão de pedido público de ajuda
- Dezembro de 2021: lançamento do curso
- Fevereiro de 2024: lançamento comercial da Version 5
- Abril de 2026: Version 6
- A Announcements Issue no GitHub foi usada como um blog para registrar a história do projeto, crescendo para mais de 1.700 entradas
- Para facilitar a leitura, um snapshot foi publicado na aba Announcements 2018-2024 da documentação
- Trabalhar em open source em tempo integral gerou pressão financeira imediata e contínua
- Patrocínios e doações via GitHub Sponsors e Buy Me a Coffee chegaram, no pico, a cerca de US$ 150 por mês
- O curso da Udemy, com 61 aulas e 11,5 horas, chegou no início por um curto período a cerca de US$ 2.000 por mês, mas depois caiu para menos de US$ 100
- Nenhuma das duas formas foi suficiente para sustentar o projeto no longo prazo
Resultado da comercialização e experiência com licenciamento
- O lançamento do produto pago da Version 5 não foi uma decisão repentina; ele vinha sendo discutido publicamente por anos no README e nos anúncios
- No início de 2024, depois de esgotar outras alternativas, a versão comercial foi lançada
- O objetivo era manter a acessibilidade, não criar barreiras
- Em termos de sustentabilidade financeira, não funcionou bem, mas em termos de experiência, aprendizado e relacionamentos, foi considerado valioso
- Após a comercialização, a maioria dos usuários não foi perdida, e muitas empresas continuaram usando o PySimpleGUI
- O problema era fazer com que as empresas comprassem licenças
- Foi adotada a Hobbyist License, em que usuários hobbyistas e estudantes usam de graça, enquanto empresas pagam
- Na prática, a maioria dos usuários se identificava como hobbyista
- Dezenas de milhares de usuários corporativos se registraram na camada gratuita, e não era raro haver grandes empresas com centenas de usuários e apenas poucas licenças pagas
- O autor afirma não se arrepender da decisão de oferecer uma opção gratuita
- Sua conclusão pessoal é que existe uma forte expectativa cultural de que ferramentas e bibliotecas Python sejam gratuitas
- Preço ou insatisfação não pareciam ser o problema central; na interpretação dele, as pessoas continuaram usando o PySimpleGUI, mas não sentiam obrigação de pagar
- Mesmo termos claros de licenciamento nem sempre mudavam esse comportamento
Licença atual
- O aviso de copyright é
Copyright 2018-2026 PySimpleGUI. All rights reserved. - A licença atual é LGPL3
1 comentários
Opiniões no Hacker News
No trabalho, eu precisava registrar o tempo de trabalho no Jira, mas não gostava de ficar com o site aberto o tempo todo, e também era lento encontrar a issue em que eu estava trabalhando, achar o link de registro de tempo e adicionar um comentário.
Eu queria um app de desktop com a lista de issues atribuídas a mim e botões para adicionar comentário/tempo de trabalho. Com Tkinter, fiquei um bom tempo apanhando para deixar a interface bonita, mas depois que descobri o PySimpleGUI, consegui conectar hooks da API do Jira e criar o que eu queria; foi um bom projeto para aprender desenvolvimento de UI.
Um amigo disse que, em um emprego, criou um cliente Qt interno para tarefas básicas do Jira, e quando eu também precisei rastrear trabalho pelo Jira usei https://github.com/go-jira/jira para lidar com alterações por meio de vários scripts de console.
Estou bem animado com frameworks de GUI assim. A experiência nativa de desktop é muito melhor do que uma combinação de webviews, e o loop de eventos simplificado do PySimpleGUI e sua abordagem com múltiplos backends me parecem realmente novos.
Ainda assim, fico me perguntando por que não existem mais “GUIs automáticas”, em que você passa apenas estruturas de dados e funções e elas geram automaticamente uma interface adequada para manipulá-las. Se heurísticas escolhessem entre colocar painéis na vertical/horizontal, usar uma interface com abas ou pop-ups, isso poderia abrir muita coisa que fica aninhada demais para uma CLI e é nativa demais para virar webapp.
https://github.com/chriskiehl/Gooey
Você pode definir uma struct e passá-la para a função
dialog, que ela gera automaticamente uma caixa de diálogo de acordo com os campos da struct e chama um callback quando o usuário pressiona OK. Também dá para especificar, com atributos definidos pelo usuário, qual widget usar; por exemplo, se você colocar@ControlledBy!VerticalSlider(0, 100)em umint, ele vira um slider de 0 a 100 em vez de um campo de entrada numérica. Também é possível anexar coisas a funções de menu, como@menu("Search") Find(string text) { ... }, para gerar automaticamente menus e caixas de diálogo, e há também umDataControllerWidgetque chama um callback a cada evento de alteração. Escrevi um artigo relacionado alguns anos atrás, mas o avanço é muito lento: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...É interessante o bastante para eu querer dedicar mais tempo, mas como não tenho uso disso no meu trabalho principal, acabo mexendo só um pouco nos fins de semana quando dá vontade de programar.
A estética dos exemplos parece ter sido trazida diretamente dos anos 90, como em [0]. É perfeita para protótipos ou ferramentas internas para pessoas que não conseguem usar CLI, mas fico me perguntando o que fazer quando é preciso uma UI bonita.
Em termos de desempenho, UI nativa é sempre boa, mas sempre achei mais difícil de estilizar do que páginas web. Fico curioso sobre qual seria, em GUIs Python, o equivalente a um conjunto de componentes estilizados que pareçam sofisticados sem grande esforço, como Flutter ou SwiftUI.
[0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...
No mínimo, o estilo de UI padrão fornecido pelo sistema operacional permite que as pessoas aprendam em um app e transfiram esse conhecimento para outro. Como eu não sou um designer de UI excepcional, é bem provável que os padrões do sistema operacional sejam melhores do que qualquer coisa que eu consiga imaginar. Se você ainda soma a isso a frase que o marketing teme ouvir — “nosso software parece velho” —, o custo de desenvolvimento sobe a um nível já difícil de sustentar.
Esse tipo de software existia nos anos 90, mas não é a estética dos anos 90 de que as pessoas costumam falar. Houve muito cuidado no design da UI do Windows 95.
Gosto menos dos grandes espaços em branco das UIs de hoje, dos botões que não parecem botões, das barras de rolagem que desaparecem e dos menus hambúrguer.
A separação entre frontend e backend também já vem de fábrica, e se você precisar mais tarde, acesso remoto também é possível. Se quiser usar como app nativo, basta colocar um botão “Open browser UI” em uma GUI pequena do tipo Tkinter. Se o botão de execução colocar um token na URL, isso também protege contra um daemon em execução por outro usuário na mesma máquina, embora eu nunca tenha visto alguém fazer isso na prática.
SystemDefaultForReal, os widgets nativos do Windows têm aparência moderna, mas o Tkinter não foi atualizado de forma alguma e acaba parecendo deslocado.Parece bom. Mas, embora esta biblioteca já seja madura e talvez seja difícil fazer grandes mudanças, seria bom usar dicionários em vez de listas. Dicionários nas versões recentes do Python lembram a ordem de inserção
Em um emprego anterior, fiz algo parecido como um wrapper muito mais fino sobre PyQt, e a quantidade de código era surpreendentemente pequena. A diferença principal era que ele tratava a configuração de propriedades/sinais e o aninhamento de widgets juntos. Em vez de definir propriedades no construtor, havia a vantagem de poder defini-las no corpo da definição da view, mesmo que depois fosse necessário o nome do widget para alterar o texto. Uma única função
setup_viewera toda a API, e era bem prática para criar GUIs simples rapidamente. Esta biblioteca também parece uma boa alternativa, então obrigado por compartilharhttps://docs.python.org/3/whatsnew/3.7.html#summary-release-...
É melhor deixar o data binding a cargo do framework. Tanto na web quanto no desktop, tudo está caminhando cada vez mais nessa direção. Em vez de alterar widgets diretamente, deve-se vincular as propriedades dos widgets a um armazenamento de dados e fazer com que sejam renderizados novamente automaticamente quando houver mudanças. Os exemplos de entrada/saída da página mostram algo parecido. Hoje ninguém mais usa
getElementById()Parece estar chegando perto da facilidade de uso do VB6 ou do Delphi/Lazarus. Definitivamente houve progresso, e agora, se houver apenas um construtor de GUI interativo, bastaria
#importar os forms criados e usar diretoAlguns anos atrás, perdi uma quantidade enorme de tempo em um projeto tentando usar WxPython junto com WxFormBuilder. Qualquer pequena alteração no form quebrava todo o backend, e escrevi manualmente um código fino de ligação intermediária, mas quando mudei o tipo de um campo, tudo quebrou de novo. Fico feliz que aqui isso não pareça acontecer
Como alguém que desenvolve uma aplicação GUI em Python [1], acho que o maior problema ao usar Python para apps desktop é o empacotamento
As ferramentas existentes para criar binários distribuíveis param de funcionar ou exigem hacks nada triviais assim que há mais do que algumas dependências. Mesmo pacotes populares geram problemas difíceis, como imports ocultos ausentes ou arquivos de dados que você nem sabia que faltavam. O carregamento dinâmico de módulos também pode quebrar quando levado para fora do ambiente Python normal, como no PyInstaller ou no cx_freeze. Não sei o que poderia ser feito, mas talvez o Python também precise de um padrão de empacotamento de programas executáveis independentes, que dependam apenas do interpretador, como os JARs do Java
Com ferramentas como shiv ou PEX, é possível criar um zipapp incluindo as dependências da aplicação, mas, se houver extensões binárias, o artefato ainda será específico de plataforma: https://github.com/linkedin/shiv#gotchas
Para meus programas em Python, recomendo que os usuários instalem com pipx: https://github.com/pypa/pipx
Se o público-alvo for minimamente técnico, acho que é a melhor escolha. Ele evita conflitos de versão do
pip install --usere o sofrimento de criar manualmente ambientes virtuais por app, além de oferecer uma experiência de usuário geralmente boa. Dá para recomendar pipx como método de instalação padrão e esperar que as pessoas consigam instalar. Meu programa tem dependências binárias, mas não tem GUIPessoalmente, gosto mais do CustomTKinter. É muito mais elegante, tem uma aparência no estilo Material Theme e oferece suporte a temas claro/escuro conforme as configurações do sistema no Windows/Linux/macOS
É surpreendente que, no campo de desenvolvimento rápido de aplicações, ainda nada tenha preenchido direito o vazio deixado pelo VB6. A linguagem em si não era excelente, mas o ponto forte do VB6 era o construtor de GUI drag-and-drop
https://www.lazarus-ide.org/
https://gambas.sourceforge.net/en/main.html
https://qb64.com/inform.html
O útil é que, no pyqt, basta colocar o arquivo de layout ao lado do script Python para usá-lo. O suporte a Python da IDE não é bom, mas talvez seja porque minha instalação esteja quebrada
https://xojo.com/
Estou pensando em colocar uma GUI em cima de uma ferramenta que tem uma interface CLI bastante bem-feita, para que pessoas que não usam Linux desktop também consigam usá-la. O PySimpleGUI parece que pode atender exatamente ao que eu preciso
https://github.com/hiAndrewQuinn/finstem
Minha ferramenta tem flags bem definidas para CSV, TSV e JSON. Gostaria de saber se alguém tem experiência em criar uma GUI por cima de uma ferramenta CLI completa já existente, sem alterá-la, e que dificuldades devo esperar
O motor e a GUI seguem protocolos como WinBoard ou UCI[2], trocando comandos de texto via STDIN/STDOUT. A principal dificuldade é a mesma encontrada em multithreading: pode surgir um deadlock em que a GUI e a CLI ficam paradas esperando uma pela outra. Por isso, ambos os lados precisam tratar entrada e saída em threads separadas da “lógica de negócio” para manter a responsividade. Outro problema comum é que o tratamento de pipes varia conforme o sistema operacional, então é preciso se preocupar com flush de buffers e diferenças de API entre Linux/Mac/Windows
[0] http://hgm.nubati.net/
[1] http://www.playwitharena.de/
[2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
Espero não soar rude, mas há texto demais. Há frases longas em todo lugar onde dá para colocar texto e, embora a maior parte seja coerente, não há uma única captura de tela relevante nos primeiros mil termos
Algo parece fora do lugar. Dá a impressão de ser talvez um desenvolvedor jovem e entusiasmado, ou alguém colocando muito texto para tentar convencer você a experimentar. O README tem até uma seção “about me”, na qual o autor se apresenta. Um exemplo seria descer até qualquer ponto do README, ler alguns parágrafos e depois tentar repetir o que acabou de ler
Algumas pessoas gostam de ler sobre uma ferramenta em si, em vez de ter a atitude de “como faço para rodar o mais rápido possível lendo o mínimo de palavras”. Como você está usando de graça uma ferramenta feita por outra pessoa, é melhor parar de reclamar e deixar que ela se expresse como quiser
[1] https://github.com/PySimpleGUI/PySimpleGUI#about-me-
Espero não parecer rude, mas me pergunto se você talvez tenha medo do simples fato de ter que ler um texto quando ele não vem mastigado em um resumo passo a passo
A mesma ideia poderia ter sido transmitida como “para um projeto visual, sinto que a descrição principal deveria ter mais capturas de tela”, sem incluir suposições ofensivas
Quando você coloca palavras como Smart, Open, Trusted ou Secure no nome de um projeto, fica fácil as pessoas apontarem que ele não alcança o ideal sugerido pelo nome. Por outro lado, nomes como C ou BSD não têm antônimo nem implicações, então é difícil dizer que “a linguagem C não faz jus ao nome”