Enquanto fazia um binding para Python (Usando PyGTK) de uma das bibliotecas usadas no N800, tudo corria bem até que me deparei com um problema ao usar funções que por “debaixo dos panos” usavam DBus. A função chamada registrava internamente um callback da própria biblioteca para um sinal DBus que, mesmo sem erro no momento do registro, não chamava o callback quando era lançado.
Alguns dos vários testes:
- Usando bus.add_signal_receiver() o sinal era capturado no Python mas o callback ainda assim não era chamado.
- Deixando de lado PyGTK e fazendo o binding “na mão” também dava o mesmo erro
- Embutindo python numa aplicação C e apenas chamando as funções de registro funcionava. Nesse caso o MainLoop estava em C.
- Embutindo python numa aplicação C e declarando e executando o MainLoop em Python funcionava (A inicialização do DBus ainda estava em C).
Nesse último teste e com a ajuda de um email de um dos desenvolvedores do dbus-python, descobri que o problema era justamente a conexão DBus não estar sendo “acoplada” ao MainLoop do programa.
Toda vez que alguém chama dbus_bus_get (em C…), é retornada uma conexão compartilhada, própria da aplicação (incluindo a biblioteca que estava escrevendo os bindings) e mantida “viva” pela libdbus (C). Para poder capturar os sinais, é necessário que essa conexão fosse configurada para o MainLoop atual, usando dbus_connection_setup_with_g_main.
O “problema” era que os bindings Python do DBus não usam essa conexão compartilhada e sim uma conexão privada, própria do binding. Ao configurar com o MainLoop em Python usando import glib ou DBusGMainLoop(set_as_default=True), a conexão privada era a configurada e não a conexão compartilhada, usada pela biblioteca. Para resolver, bastou usar dbus_connection_setup_with_g_main no código de inicialização e tudo acabou funcionando.
PS: Esse rolo todo me custou quase 2 semanas…
PS2: Funcionou no desktop, falta testar no dispositivo, que usa versões mais antigas do DBus…
Lauro Moura 