W dniu 13.01.2011 16:02, Henry Vermaak pisze:
On 13/01/11 15:00, Henry Vermaak wrote:
On 13/01/11 12:24, dib...@wp.pl wrote:
"integrate the GLib event loop with an external event loop" - I think
this is what I want.
What you want to do is to integrate the dbus connection into your main
loop (in this case glib). Let me quote from the documentation:
"If you're using GLib or Qt add-on libraries for D-Bus, there are
special convenience APIs in those libraries that hide all the details of
dispatch and watch/timeout monitoring. For example,
dbus_connection_setup_with_g_main().
"If you aren't using these add-on libraries, but want to process
messages asynchronously, you must manually call
dbus_connection_set_dispatch_status_function(),
dbus_connection_set_watch_functions(),
dbus_connection_set_timeout_functions() providing appropriate functions
to integrate the connection with your application's main loop. This can
be tricky to get right; main loops are not simple."
If you look at the dbus_connection_set_watch_functions documentation:
http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#gaebf031eb444b4f847606aa27daa3d8e6
You'll see that this will provide you will file descriptors that you can
add to your main loop to watch for the dbus events.
This is all _much_ simpler if you use the dbus-glib functions:
http://www.ibm.com/developerworks/linux/library/l-dbus.html
It doesn't look like that header has been translated to pascal, yet.
That doesn't matter, since it's now considered obsolete, since glib has
dbus support now:
http://www.freedesktop.org/wiki/Software/DBusBindings
fpc doesn't seem to have bindings for that, either...
Having said all of this, you can get around this by calling blocking
dbus calls in a thread and notifying the user interface by virtue of
Synchronize, PostMessage and QueueAsycCall.
Henry
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
I'm trying with "dbus_connection_set_watch_functions" but this is not
easy like it look. I thought that I must only register my event
procedures by calling this functions but there is much more work. I have
a headache. Now I understand why dbus documentation begins with the
words "If you use this low-level API directly, you're signing up for
some pain" ;) . Tomorrow I look for some "live example" of using this
functions in C.
I tried with thread. It doesn't catch all signals even if I call
sleep(1) in loop. I don't know what is reason of this loss. Thread and
AddEventHandler have this same problem - they don't catch all signals.
Only one way which works is "g_main_context_set_poll_func" but now I see
that the application consumes 30% CPU. So now I understand why it catch
all signals. @**Matthias how you solved problem with CPU and this function?
This all problems started after this upgrade (probably):
http://bugs.freepascal.org/view.php?id=14086
Because before I listened for signals in thread with sleep(100) without
problems.
P.S. People who have demo from me, please comment line:
dbus_connection_close(conn);
in my_client_app -> busexample.pas
This should not be there.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
