GUI

No meu texto de referência, Darktable: batendo no muro em câmera lenta, apresentei o desastre que era o novo “Grande turducken MIDI”. O propósito desse turducken¹ era reescrever o sistema de atalhos de teclado para estendê-lo a dispositivos MIDI.

Até hoje, ainda estou irritado com essa empreitada de destruição em massa; aqui vai um resumo dos motivos:

1. em 2021, substituiu um sistema de atalhos de teclado que era muito bom, completo em recursos, bem testado, estável e escrito em menos de 1500 linhas (comentários incluídos),
2. …para adicionar suporte a dispositivos MIDI e gamepads de PlayStation (!?!)…
3. …mas na minha pesquisa sobre o Darktable de 2022, um ano após esse novo recurso, dentre os mais de 1251 usuários que participaram:
   • 81% dos usuários não tinham um dispositivo MIDI e não planejavam adquirir um,
   • 2% nem sabiam o que era um dispositivo MIDI.
   • 8% dos usuários tinham um dispositivo MIDI mas não o usavam com o Darktable,
   • 6% estavam considerando talvez adquirir um dispositivo MIDI no futuro,
   • 2% dos usuários tinham um dispositivo MIDI que realmente usavam no Darktable,
4. o código era absolutamente terrível, em termos de:
   • qualidade de código: instruções if/switch-case ilegíveis aninhadas em 4 níveis, no meio de funções de 1000 linhas (postei trechos de exemplo no meu artigo),
   • volume de código:
     • 3546 linhas de código para o Darktable 4.0,
     • 4397 linhas de código para o Darktable 5.0,
     • o aumento de volume é uma consequência direta de tentar corrigir bugs em uma arquitetura que não pode ser consertada porque sua complexidade promove mais complexidade. Tudo isso decorre do design, mas resolver problemas criados pela complexidade adicionando mais complexidade não é solução.
   • complexidade de código:
     • complexidade ciclomática :
       • 1088 para o Darktable 4.0,
       • 1245 para o Darktable 5.0 (detalhes ),
     • complexidade cognitiva :
       • 1885 para o Darktable 4.0,
       • 2098 para o Darktable 5.0 (detalhes ).
     • é de longe o recurso mais complexo do software, mesmo não operando sobre imagens. Para comparação, o segundo recurso mais complexo é a decodificação de metadados EXIF, que tem uma complexidade cognitiva de 1348.
5. ele não decodifica modificadores de tecla por design, mas lida apenas com as teclas pressionadas no hardware, o que significa:
   • a entrada “1” do teclado numérico é decodificada como Keypad End,
   • a entrada “1” de um teclado francês AZERTY é decodificada como Shift+&, ou Shift+" no BÉPO,
   • portanto, você precisa duplicar todos os seus atalhos baseados em números para cada forma de inserir um número, e se preparar para que a janela de configuração de atalhos não contenha nenhum número real nas combinações de teclas.
6. o design voltado ao usuário é absolutamente terrível, com ações e emulações demais para configurar (“efeitos”), que nem sequer estão totalmente documentadas 4 anos depois (o que é “ctrl-toggle”? “right-activate”?), e a configuração de atalhos usa uma estranha janela dividida que não faz o menor sentido,
7. a implementação também é terrível: o recurso conhece toda a GUI do software, e a GUI do software conhece o código dos atalhos. Não há modularidade alguma aqui, e mudar qualquer coisa no código dos atalhos pode ter efeitos inesperados e indesejados em qualquer parte do software.² Basta ver o grafo de dependências abaixo,
8. vários “atalhos” (ou vinculações MIDI) podem estar associados à mesma ação, o que significa que cada interação do usuário precisa consultar a lista inteira de ações disponíveis, induzindo um tratamento de atalhos muito ineficiente, travamentos da GUI em alguns casos e falsos positivos de “combinação de teclas desconhecida” em casos peculiares.