page21
Mundo Libre
artigo
Com cerca de 70 mil linhas de código novo fornecendo uma interface alternativa, eu queria focar primeiro na já existente. Tenho utilizado esta base de código por quase 10 anos mesmo sem perceber. O código também foi escrito por alguém da IBM, e por isso eu não poderia achar que qualquer um no LibreOffice seria capaz de me ajudar.
Também esperava que a equipe Apache notaria os relatórios de bugs e resolveria os da barra lateral. O LibreOffice pega as correções do Apache diariamente. Contudo, apenas cerca de metade das alterações são úteis pois, em muitos casos, o LibreOffice já fez o trabalho. Entretanto, todos os pedaços de valor são portados, e apenas uma pequena porção das milhares de melhorias do LibreOffice ficam para as melhorias de pré-lançamento.
Eu considerei enviar um e-mal para o Apache OpenOffice, perguntando se eles estavam cientes do problema e estavam planejando trabalhar nele. É mais eficiente coordenar esforços e
não ter várias pessoas reaprendendo o trabalho do outro. Levei horas para corrigir problemas que poderiam ter sido corrigidos durante o almoço, exatamente pela pessoa que escreveu o código. No entanto, enquanto o LibreOffice está usando patches do Apache OpenOffice, os grupos geralmente não estão ativamente planejando trabalho. Por isso, pedir apoio para o HiDPI para a barra lateral teria sido uma quebra de protocolo.
Além disso, as bases de código são divergentes entre si, de modo que as correções podem não ser úteis. O Apache OpenOffice não tem a API OutputDevice::DPIScaleFactor. Por isso, os patches não teriam sido diretamente úteis. Eu não testei o Apache OpenOffice no Linux, mas sim no Windows 8.1 e os bitmaps da barra lateral pareciam ter o dobro de tamanho. No entanto, o Windows 8.1 pode ter colocado artificialmente em escala toda a interface gráfica do Apache OpenOffice, já que o texto era uma bagunça embaçada, se comparado com o LibreOffice: