Kivy, Pong e .kv: protótipo touch versus expectativa de HMI industrial

Kivy, Pong e .kv: protótipo touch versus expectativa de HMI industrial

Kivy brilha em demonstrações multi-toque, canvas imediato e o mesmo código tentando viver em desktop e dispositivo touch. HMI industrial brilha em outra coisa: legibilidade a um metro de distância, estados inequívocos, botão de emergência fora da UI, comportamento determinístico sob luva e sujeira. O repositório kivy_Framework — aprendizado a partir da documentação oficial, pasta kivy_pong_game com main.py + pong.kv, e notas de PyInstaller — é um ótimo laboratório para sentir essa tensão na pele.

Este texto não vende Kivy como substituto de painel de linha. Discute o que o Pong ensina de eventos e layout, como empacotar .kv no .exe, e onde a metáfora de jogo quebra quando o cliente espera HMI de fábrica. Sem métrica inventada de fps em planta, sem pitch de produto web: só o contrato do protótipo versus o contrato do chão.

O que o repositório documenta

README em inglês curto:

• propósito: learning from kivy documentation;
• foco prático: kivy_pong_game;
• bloco PyInstaller: clonar o PyInstaller, compilar bootloader com waf, pip install ., e o exemplo de comando:

pyinstaller .\main.py --onefile --add-data="TheLab.kv;."

O jogo em si usa pong.kv (não TheLab.kv): o comando do README é padrão de empacotamento — lembrar que arquivo .kv é dado, não código Python automaticamente encontrado. Essa distinção é o núcleo da dor de deploy.

Arquivos do jogo:

• main.py — widgets PongPaddle, PongBall, PongGame, app PongApp;
• pong.kv — declaração visual (elipse da bola, retângulos das raquetes, placar, linha central).

O README curto é feature, não bug: o repo não fingir ser framework de automação. Quem precisa de tags, alarme e receita está no domínio errado se parar aqui. Quem precisa calibrar expectativa de touch e de empacotamento está no domínio certo.

O que o Pong ensina (e por que isso importa para UI técnica)

Propriedades e binding

NumericProperty, ReferenceListProperty, ObjectProperty ligam estado Python ao .kv. Quando player1.score muda, o Label no KV atualiza. Em HMI, o mesmo padrão mental existe (tag → indicador), mas com outra disciplina de engenharia: qualidade do sinal, timeout, modo falha.

No Pong, se o placar “mentir”, o jogo fica estranho. No chão, se o indicador mentir, o operador comanda errado. O mecanismo de binding é parecido; a severidade não é.

Clock a 60 Hz

Clock.schedule_interval(game.update, 1.0/60.0)

O loop de jogo atualiza física da bola. Em protótipo de painel touch, um Clock semelhante pode animar ou polir status. Em HMI de processo, atualizar “o mais rápido possível” sem modelo de prioridade é antipadrão: você quer taxa definida, debounce e separação entre varredura de I/O e desenho.

Traduza o 60 Hz do Pong para uma pergunta de projeto: qual a taxa útil de redesenho do meu indicador? Muitas telas de status de oficina vivem bem com atualização bem mais lenta e previsível. Animação fluida não é requisito de legibilidade; às vezes atrapalha.

Toque dividido por terço da tela

def on_touch_move(self, touch):
    if touch.x < self.width / 3:
        self.player1.center_y = touch.y
    if touch.x > self.width - self.width / 3:
        self.player2.center_y = touch.y

É uma aula excelente de hit zone. Em painel industrial touch barato, hit zone generosa é requisito: o operador usa luva, a tela tem parallax, há vibração. O Pong mostra a ideia; um HMI sério adiciona confirmação, estados disabled claros e anti-duplo-toque.

Exercício honesto de laboratório: reduza os terços para faixas estreitas e jogue com o dedo indicador cansado. A frustração que aparece é a mesma do botão pequeno demais no mock de “partida/parada” desenhado no Figma sem teste de polegar.

Separação main.py / pong.kv

O KV descreve aparência e estrutura; o Python descreve comportamento. Isso se parece com QML/Qt Quick ou com layouts declarativos. Vantagem: designer e lógica podem evoluir em ritmos diferentes. Risco no chão: mais um arquivo para esquecer no empacotamento — e o app abre “sem UI” ou com layout default quebrado.

Em ferramenta de oficina, trate .kv como artefato de build de primeira classe, igual a ícone e DLL. O README do repo já grita isso com --add-data; o nome errado no exemplo (TheLab.kv) é o lembrete cruel de ler antes de colar.

PyInstaller + .kv: a lição que dói

O README insiste em recompilar o bootloader do PyInstaller (mesmo espírito do pyqt6_book) e mostra --add-data com separador Windows ;. Pontos práticos:

1. .kv não viaja de graça no onefile. Sem --add-data (ou lista no .spec), o jogo que funciona no interpretador falha no cliente.
2. O nome no exemplo (TheLab.kv) vs pong.kv no código reforça: o comando é checklist, não copy-paste cego — ajuste o nome do arquivo real.
3. No Linux o separador de --add-data é : — outro pé de coelho quando o mesmo time gera build nos dois SOs.
4. Kivy ainda puxa binários gráficos (SDL, GLEW, etc.): o .exe “simples” fica grande e sensível a driver de vídeo. PC industrial com GPU compartilhada ou remoto RDP pode se comportar diferente do notebook de desenvolvimento.

Comparado a GTK linkado no sistema ou a um MessageBox Win32, Kivy+PyInstaller é mais móvel e mais frágil. Ideal para demonstração e quiosque controlado; exigente para imagem congelada de fábrica sem teste de aceitação.

Ritual de aceite alinhado ao repo:

1. Rodar no interpretador com pong.kv presente.
2. Empacotar incluindo pong.kv (nome correto).
3. Mover só o artefato para outra pasta/PC.
4. Abrir e confirmar que raquetes, bola e placar aparecem.
5. Repetir após remover propositalmente o --add-data numa branch de teste — ver a falha, para o time nunca mais “otimizar” o comando.

O mesmo cuidado de bootloader/waf visto no pyqt6_book reaparece aqui. Não é coincidência: é o mesmo autor enfrentando o mesmo Windows corporativo. A lição transversal da família de estudos é empacotar é parte do produto, não apêndice.

Protótipo touch versus expectativa de HMI industrial

O Pong é honesto sobre o primeiro lado da tabela. O erro comum é apresentar um protótipo Kivy fluido ao cliente industrial e ouvir: “então substitui o painel da linha?”. Não. Substitui, no máximo, um mock de interação para validar fluxo (qual tela vem depois do login? o botão está ao alcance do polegar?). A conversão para HMI de produção passa por outra stack ou por runtime comercial — e por normas da célula.

Na conversa comercial/técnica, use o protótipo para responder perguntas de UX:

• a sequência de telas está compreensível?
• o operador encontra o comando crítico sem caçar menu?
• o feedback de “comando aceito” é óbvio?

Não use o protótipo para responder:

• atende requisito de safety?
• substitui a IHM do fabricante?
• está pronto para imagem congelada sem teste de driver gráfico?

Quando Kivy ainda é a escolha certa

• quiosque educativo ou demonstrador de produto com toque;
• protótipo rápido de fluxo multi-tela antes de contratar desenvolvimento do painel;
• experimento multiplataforma (Windows/Linux/Android) no mesmo repositório de estudo;
• UI altamente customizada em canvas onde widgets desktop tradicionais atrapalham;
• laboratório interno para ensinar binding, hit zone e empacotamento de asset.

Quando não é:

• comando de máquina com requisito de segurança;
• substituição de IHM do fabricante sem análise;
• formulários densos de engenharia com PDF/OF (aí o pyqt6_book é bem mais natural);
• painel Linux mínimo com dependência de sistema (c_gui_linux);
• diálogo nativo mínimo no Windows de manutenção (c_gui_win).

A escolha errada mais cara não é “Kivy é ruim”. É Kivy no papel de HMI de linha sem dizer ao cliente que o papel é outro. Expectativa desalinhada gera retrabalho maior que qualquer discussão de widget.

Como aproveitar o repo como laboratório (sem overclaim)

1. Rode o Pong e force falhas: remova o .kv, mude o Clock, reduza hit zones — observe a UX quebrar.
2. Empacote com PyInstaller incluindo o pong.kv e teste em outro PC.
3. Reimplemente mentalmente o placar como “indicador de estado de processo”: o que acontece se o valor não chega? O Pong não trata isso — seu HMI precisa tratar.
4. Documente a lista de DLLs/dados do build; isso vira o embrião de um checklist de comissionamento.
5. Escreva um parágrafo de escopo (“isto é demonstrador / protótipo de interação”) e cole no README da pasta antes de mostrar a alguém de planta.

Do Pong a um mock de fluxo (sem fingir integração)

Se quiser estender o laboratório sem inventar CLP:

• troque placar por rótulos “Estado A / Estado B”;
• troque movimento contínuo por botões grandes de transição;
• imponha confirmação antes de mudar estado;
• grave um log texto local de cada transição.

Isso continua sendo Kivy de estudo — mas já treina o músculo que o chão cobra: estado explícito e ação confirmada. Continua sem ser HMI certificado. Continua útil.

Relação com PyQt6, GTK e Win32

A família de estudos desenha uma matriz simples:

Levar Pong para a reunião errada é como levar MessageBox para substituir SCADA: categoria confundida. O valor do kivy_Framework no portfólio é mostrar que o autor conhece o limite do touch fluido — não que ignore o chão.

Ambiente gráfico e o PC industrial “quase desktop”

Kivy depende de pilha gráfica (OpenGL/SDL e amigos). No notebook de desenvolvimento com GPU discreta, o Pong abre e parece óbvio. No PC de painel com GPU compartilhada, driver antigo, ou sessão remota, o mesmo binário pode falhar ao iniciar, cair para software rendering lento, ou exibir artefatos.

Isso não é argumento para abandonar Kivy em demonstrador. É argumento para testar no hardware alvo antes da demo com cliente. O checklist curto:

• mesma resolução/orientação que o quiosque ou tablet de chão;
• toque real (não só mouse), se o alvo for touch;
• cold start após reboot — captura falha de path do onefile e de driver;
• anotar versão de driver gráfico na imagem, como se anota versão de libgtk no estudo Linux.

Quem vem de embutidos já respeita “funciona na minha bancada ≠ funciona no produto”. Aqui a bancada é o desktop; o produto é o PC industrial. A disciplina é a mesma. O repo kivy_Framework não documenta cada GPU possível — documenta o ponto em que você descobre que asset e runtime gráfico importam tanto quanto a física da bola.

Conclusão

kivy_Framework cumpre o que promete: aprender Kivy pela documentação, materializar um Pong com KV e encarar PyInstaller com arquivo de layout externo. O valor industrial do estudo não é “fazer HMI em Kivy”; é calibrar expectativa. Touch fluido e canvas livre são ótimos para protótipo. Chão de fábrica cobra outro contrato — e quem já empacotou .kv no .exe pelo menos não chega nessa conversa inocente sobre deploy. Use o repo para treinar hit zone, binding e checklist de dados no build; use outra stack (ou runtime comercial) quando o requisito for painel de linha de verdade.