Continuando com minha pergunta aqui , eu gostaria de perguntar sobre práticas para depurar adições aos componentes da unidade.
A integração de aplicativos à unidade requer muitos componentes: arquivos de serviço, arquivos da área de trabalho, clientes dbus, servidores dbus etc. Com tantos componentes independentes envolvidos, tenho um pouco de dificuldade em encontrar uma boa maneira de procurar o problema quando algo não está trabalhando. Mas como muitos desenvolvedores parecem ser capazes de se desenvolver nesse ambiente, provavelmente existem ferramentas / fluxos de trabalho que estão faltando.
Como exemplo: quickly debug , que abre um depurador python, não ajuda em nada no desenvolvimento de lentes, a menos que o problema esteja diretamente no código da lente (que é mais fácil de ser encontrado com testes unitários simples). Se o problema estiver em um arquivo de serviço, isso não ajuda em nada. Eu tive problemas, por exemplo, com espaço em branco em um nome de aplicativo no arquivo .desktop , o que levou a um programa não ser listado no menu de som (eu acho que talvez fosse outro menu ...).
Então: como você está depurando lentes, lançadores, indicadores, métodos de HUD ...?
Existe uma ferramenta para verificar a integridade de um arquivo .service ?
Existe uma ferramenta para verificar a integridade de um arquivo .desktop ?
Existe uma ferramenta para ver se há colisão nos arquivos .desktop / .service ? (por exemplo, vários arquivos .service fornecendo o mesmo serviço dbus)
Existe uma maneira de assistir a comunicação entre uma lente específica no painel e o serviço de suporte da lente?
Posso testar lentes sem instalá-las?
Você não pode testar uma lente sem instalá-la. Se você não quiser fazer isso no seu sistema, você sempre pode usar uma VM.
Você pode usar DFeet para observar o que está acontecendo no DBus, mas isso requer um bom entendimento do que deveria estar acontecendo sobre a DBus para entender isso.