Re: Theory of good signal/event API design?
- From: Sander Marechal <s marechal jejik com>
- To: Robert Schwebel <r schwebel pengutronix de>
- Cc: gtk-devel-list gnome org, gtk-app-devel-list gnome org
- Subject: Re: Theory of good signal/event API design?
- Date: Mon, 17 Sep 2007 07:28:05 +0200
Robert Schwebel wrote:
> On Sun, Sep 16, 2007 at 08:51:26PM +0200, Sander Marechal wrote:
>> Maybe. I did a bit of reading and it looks like bdus was created for
>> communication between applications and for os->application
>> communication, not for passing messages around within a single
application.
>
> Yes, sure. I assumed that, if you talked about modules, they may be
> realized in a way that may need inter thread or inter process
> communication.
My application is multi-threaded, but since it's written in Python, most
of that complexity is hidden away.
> If your application is single threaded, why not just call functions?
> Calling functions and sending a message is almost the same then.
That's what happens in the end. A module can connect a callback function
to certain signals in my application. In the end, the module manager
does simply call that function. Pretty much like you connect callbacks
to signals in GTK.
Let me give an example how my app works inside. I have a music player
written in GStreamer. It needs a song to play so it sends out a
MESSAGE_REQUEST_SONG on it's bus. The module manager is listening on
that bus so it catches the message. It sees that the Playlist module
wants to know about MESSAGE_REQUEST_SONG so it calls the Playlist
modules' callback function.
If there is a song in the playlist, the Playlist module sends a
MESSAGE_NEW_SONG on the bus that contains the song uri. The player will
catch that and load the song. If there is no song in the playlist, the
the callback returns FALSE and the module manager checks for other
modules that have callbacks for MESSAGE_REQUEST_SONG.
The Module Manager finds another callback, the Random module, and calls
that callback next. The random module picks a random song from the
library, posts a MESSAGE_NEW_SONG and returns TRUE, which tells the
module manager that the signal has been dealt with and should not be
past to other callbacks.
I hope that makes sense. If you want to see it in action, check out
http://svn.jejik.com/viewvc.cgi/jukebox/trunk/ which is the message
driven jukebox daemon I'm working on.
What I'm hoping for is that the GTK people have some good documentation
or guidelines for determining when a message-driven application should
send out messages, seeing that they write a lot of GTK widgets that all
send and receive events and signals of their own. I'm hoping there is a
better way than the ad-hoc way I'm adding new messages now.
--
Sander Marechal
http://www.jejik.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]