[fpc-pascal] D-Bus. Non blocking listening for signals

Matthias Klumpp matthias at nlinux.org
Thu Jan 13 14:41:35 CET 2011


On Thu, 13 Jan 2011 13:32:29 +0100 (CET), michael.vancanneyt at wisa.be
wrote:
> On Thu, 13 Jan 2011, dibo20 at wp.pl wrote:
> 
>> W dniu 10.01.2011 20:41, Michael Van Canneyt pisze:
>>> 
>>> 
>>> On Mon, 10 Jan 2011, dibo20 at wp.pl wrote:
>>> 
>>>> Sorry for refreshing, but the problem is still present :( . It works 
>>>> perfect on my mashine (ubuntu 10.10 64 bit) but doesn't work on my
>>>> friends
>>>> computer. For example, one of my friend have this same laptop as me
>>>> and
>>>> exactly this same version of ubuntu (64 bit too). My application find

>>>> signals only when he moving mouse cursor over main form (on idle
event
>>>> is
>>>> fired in which I check for signals too). It looks like method 
>>>> dbus_connection_set_wakeup_main_function doesn't register wake up
>>>> function
>>>> properly. This is procedure, not function so I don't even know if
>>>> there
>>>> was error.
>>> 
>>> That can of course be, but this is not under our control.
>>> 
>>>> I copy source of my program to ubuntu 10.10 32bit on my virtual
>>>> mashine
>>>> and compile on latest SVN version of lazarus (like on 64 bit ubuntu).
>>>> This
>>>> same problem. I debug this and wake up function is never called in
>>>> client
>>>> when dbus host send signals. I have no idea why on 64 bit (and only
on
>>>> my)
>>>> it works ok. Some external library is responsible for this? All
>>>> computers
>>>> are upgraded to latest version, so we have this same dbus library.
>>> 
>>> Do they run the same desktop ?
>>> 
>>> Can you please provide testprograms (client and server) so I can run
>>> some
>>> tests ?
>>> 
>>> Michael.
>>> 
>>> _______________________________________________
>>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>> 
>> Did you receive my mailwith demo?
> 
> Yes, I even debugged some things, but found no solution yet.
> 
>> I think I found temporary solution. In 
>> glib2 is procedure:
g_main_context_set_poll_func(g_main_context_default, 
>> @CheckForSignalProc);
>>
>> It seems that application main loop call registered CheckForSignalProc
>> on
>> each loop cycle without blocking user interface and it works. But I do
>> not
>> know if I understand the documentation:
> 
> I'm not sure I understand what you did ?
> 
>>
>> "Sets the function to use to handle polling of file descriptors. It
will
>> be
>> used instead of the |poll()| system call (or GLib's replacement
>> function,
>> which is used where |poll()| isn't available).
>>
>> This function could possibly be used to integrate the GLib event loop
>> with an
>> external event loop."
>>
>> "integrate the GLib event loop with an external event loop" - I think
>> this is
>> what I want.
>>
>> My concerns:
>> 1. How does it affect to performance? Is it too often calledfor dbus?
>> 2. Glib is most used by GTK. Will this work when I compile project with
>> QT
>> interface for KDE? (my future plans). I do not want to force users to
>> install
>> whole GTK librarys when they areusing only QT
> 
> g_main_context_set_poll_func is only used for the GTK widget set. 
> You'll have to test separately with Qt.
Hi!
I developed the Listaller Project, a cross-distro Linux software manager,
which uses techniques like D-BUS and PolicyKit and had very similar
problems. You can run Qt4 applications which use GLib (but only GLib!), but
you need to call g_type_init() in the Qt application somewhere to make
GObject work. (But only _once_, otherwise you get very strange behavior)
This makes the application depend on GLib, but not on GTK+. I won't need my
Listaller D-BUS daemon anymore next time, cause the required parts will get
merged with the PackageKit project. (D-BUS in Pascal is a PAIN! I wrote a
small set of simplifications, but it's far away from a state like C/GLib,
where DBus is very easy to use) Projects like PackageKit, PolicyKit or
Canberra are the reason why KDE has GLib installed in most times, so
depending on GLib and Qt is not really a problem considering the
dependencies.
Cheers
  Matthias Klumpp





More information about the fpc-pascal mailing list