6ear

O 6ear nasceu durante um curso de mecânica, em maio de 2025. O problema vinha de duas máquinas reais: as fresadoras Sanches Blanes e Victória, cada uma com seu próprio conjunto físico de engrenagens.

Para alcançar uma relação de transmissão, era preciso escolher uma montagem suficientemente próxima do valor desejado e dentro de uma tolerância. O software surgiu para pesquisar essas possibilidades antes da montagem na máquina.

Às 09:08 de 6 de maio, a dúvida ainda era de análise combinatória: com doze tipos de engrenagens e repetição, quantas possibilidades surgiriam ao combinar pares? Esse registro preserva praticamente o nascimento do projeto.

A pergunta rapidamente ganhou entradas concretas: escolher a fresadora, informar uma relação alvo e uma tolerância, testar arranjos e ordenar os resultados por abs(r - target).

A primeira implementação usava Python, Tkinter e itertools.product(). Começou com a Sanches Blanes e pesquisava configurações de um, dois ou três pares, exibindo primeiro as relações mais próximas do alvo.

A tela desktop preservada abaixo já pertence a uma etapa posterior: ela permite alternar entre Sanches Blanes e Victória. Não é a primeira interface, mas registra a evolução da versão Tkinter.

A primeira aproximação permitia repetição matemática. Na oficina, porém, cada número de dentes tinha uma quantidade disponível. Havia duas engrenagens de 24 dentes, enquanto vários outros tamanhos tinham apenas uma unidade.

A posição também importa: 24 → 36 não produz a mesma relação que 36 → 24. Ao mesmo tempo, trocar duas peças fisicamente idênticas de 24 dentes não deve criar um resultado artificialmente diferente.

A evolução passou a representar o estoque como pares (dentes, quantidade), gerar ordens com itertools.permutations() e validar ocorrências com collections.Counter. Assim, nenhuma resposta utiliza mais unidades do que a máquina realmente possui.

Em 7 de maio, cerca de um dia após as primeiras experiências, já se discutia levar o programa ao celular. Tkinter atendia ao desktop, mas não ao Android; a interface foi então reimplementada em Kivy.

O primeiro estágio mobile era funcional e ainda bruto: widgets quase padrão, grandes áreas vazias e pouca hierarquia. A direção já estava definida — relação e tolerância entravam no topo; os resultados apareciam abaixo.

O aumento do espaço de busca tornou o processamento perceptível. Executar tudo na thread da interface podia congelar o Kivy; mover toda a rotina para outra thread também não funcionava, porque widgets e instruções gráficas não devem ser criados fora da thread principal.

A seleção migrou de CheckBox para ToggleButton; medidas passaram a usar dp() e tipografia em sp; campos e botão ganharam áreas maiores; ScrollView, GridLayout e BoxLayout organizaram uma tela portrait rolável e resultados tabulares.

O programa não substituía a compreensão da máquina. Ele transformava uma etapa de pesquisa em ferramenta, enquanto as aulas continuavam lidando com divisão, fresamento, montagem e fabricação de engrenagens reais.

Em poucos dias, um problema de oficina exigiu análise combinatória, modelagem de estoque, interfaces desktop e mobile, responsividade, processamento concorrente e distribuição em dois ambientes.

Python deixou de ser apenas linguagem de exercício: product, permutations e Counter passaram a representar decisões físicas; Tkinter e Kivy mostraram abordagens diferentes de interface; threads e Kivy Clock ensinaram a respeitar a fronteira entre processamento e UI; PyInstaller, Buildozer, python-for-android e a toolchain Android mostraram que distribuir software também faz parte do trabalho.

Ferramentas de IA participaram como apoio e aprendizado, inclusive com sugestões de conceitos visuais. A marca final, porém, foi desenhada por mim no sK1; o arquivo vetorial original .sk2 foi preservado junto às versões históricas do projeto.

O código foi reencontrado em arquivos antigos e em um backup do celular. Quatro variantes — desktop v1.0, desktop v2.0, Android v1.0 e Android v2.0 — foram organizadas em um repositório moderno.

Esse repositório preserva o material, mas não finge possuir um histórico Git que não existe. Seu primeiro commit representa uma importação histórica; o desenvolvimento original aconteceu em maio de 2025.

O 6ear quase permaneceu perdido em pastas antigas. Recuperá-lo materializa uma das ideias centrais da Galeria -2048: construir para entender e documentar para não deixar o aprendizado desaparecer.