Following up on my question here, I would like to ask about best-practices for debugging additions to the unity components.

Integrating apps into unity requires many components: service files, desktop files, dbus clients, dbus servers, etc. With so many independent components involved, I have a bit trouble finding a good way to look for the problem when something is not working. But since many developers seem to be able to develop in this environment, there are probably tools / workflows that I'm missing.

As an example: quickly debug, which opens a python debugger does not help at all for lens development, unless the problem is directly in the code of the lens (which is easier found with simple unit tests). If the problem is in a service file, this does not help at all. I have had problems for example with whitespace in an application name in the .desktop file, which lead to a program not being listed in the sound menu (I think, maybe it was another menu...).

So: how are you debugging lenses, launchers, indicators, HUD methods... ?

Is there a tool to check the integrity of a .service file?

Is there a tool to check the integrity of a .desktop file?

Is there a tool to see if there are collision in .desktop/.service files? (e.g. several .service files supplying the same dbus service)

Is there a way to watch the communication between a specific lens in the dash and the supporting lens-service?

Can I test lenses without installing them?


You can't test a lens without installing it. If you don't want to do that on your system you can always use a VM.

You can use DFeet to watch what's going on over DBus, but it does require a fairly good understanding of what should be going on over DBus to make sense of it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.