Theory of good signal/event API design?
Hello, I am building an application in which pretty much all functionality is abstracted away in various modules. All these modules can be loaded and configured at will and everything communicates by passing messages/events around. Modules can listen for specific messages and respond to it, or send out messages of their own, etcetera. Pretty similar to how GTK works (in fact, it uses the GObject/GstObject system. All messages are passed over a GStreamer bus). My question: How do I determine what signals/events I should send out so that together they make for a nice module API? For now, I am simply building modules and adding signals to the application as I need them, but I bet there is a better way to figure out which signals I should add and where I should add them. Is there some theory, guidelines, tutorials, whatever about designing an event/message system, especially about what events/messages/signals to add at which locations? My application doesn't use GTK, just GObject and GStreamer, but I am asking here since GTK works in a similar way. Kind regards, -- Sander Marechal http://www.jejik.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Theory of good signal/event API design?
Robert Schwebel wrote: On Sun, Sep 16, 2007 at 06:28:56PM +0200, Sander Marechal wrote: Is there some theory, guidelines, tutorials, whatever about designing an event/message system, especially about what events/messages/signals to add at which locations? Wouldn't that be an application for dbus? 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. But dbus or not, it still leaves me with the question: Is there any theory/guidelines to determine when my application should send out signals (instead of adding them ad-hoc on an as-needed basis as I do now). Kind regards, -- Sander Marechal ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.14.1 released
GLib 2.14.1 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.14/ http://download.gnome.org/sources/glib/2.14/ glib-2.14.1.tar.bz2 md5sum: 196d7944a8ddc1f7c3d1e9c7146dd560 glib-2.14.1.tar.gzmd5sum: dd436aceda2b0fac690d11129b157dc9 This is a bug fix release in the 2.14 series. GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.14.0 to GLib 2.14.1 === * Bugs fixed: 476840 Invocation of the interface g_utf8_strreverse crashes f... 444765 Fix FIXME in gregex.c when new pcre is out 464145 g_markup_escape_text Produces Invalid XML 465625 g_type_default_interface_ref() does not ensure working g_... 466768 Clearify that comments can be put anywhere in a Key-file. 474229 The GError documentation should give convention for the G... 474899 G_BREAKPOINT() docs inaccurate 475854 Overuse of -lpcre when using system pcre 473879 Incorrect includes in gregex.c 468694 Typoes in documentation 469051 g_snprintf () talks about characters where it probably me... 457601 Missing arch specific atomic implementation 475923 Missing pcre flags when static-linking against glib 475619 glibthread-2.0.la does not list -lpthread * Updated translations: Bulgarian (bg) Catalan (ca) Danish (da) German (de) Canadian English (en_CA) British English (en_GB) Spanish (es) Estonian (et) Finnish (fi) French (fr) Gujarati (gu) Hungarian (hu) Italian (it) Georgian (ka) Kannada (kn) Lithuanian (lt) Makedonian (mk) Norwegian (nb) Dutch (nl) Polish (pl) Portugese (pt) Brazilian Portugese (pt_BR) Romanian (ro) Russian (ru) Albanian (sq) Serbian (sr, [EMAIL PROTECTED]) Swedish (sv) Tamil (ta) Thai (th) Ukrainian (uk) Vietnamese (vi) A list of all the fixed bugs can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=476840,444765,464145,465625,466768,474229,474899,475854,473879,468694,469051,457601,475923,475619 Thanks to all contributors: Andreas Monitzer Tim Janik Cody Russell Behdad Esfahbod Michael Natterer Peter Kjellerstedt Marco Barisione Yevgen Muntyan Jussi Laako Mikael Hallendal Rob Bradford Roy Marples September 16, 2007 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Theory of good signal/event API design?
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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Behaviour of getters wrt dup/ref
On Sat, Sep 15, 2007 at 11:08:38PM -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 10:35 -0400, Alexander Larsson wrote: char * g_data_input_stream_get_line (GDataInputStream *data_stream, gsize *length, GCancellable *cancellable, GError **error); This actually reads new data from the stream, so it has to dup. One could imagine a similar call that returns some form of object instead of a string. I think it's pretty common in glib and pango at least to return g_strdup'ed strings. The no-ref-count rule is mostly for objects that have a literal ref/unref pair. Other than that, for functions that return read data from the stream, some people may have reasons to want to avoid malloc/free'ing on each line. One way to work around that is to have the function take a GString, so you can reuse the buffer from the previous line. I know most people are not a big fan of that idea though. The right interface for this type of functions have been already invented: that of glibc's getline. It can allocate new buffers, it can reuse existing buffers resizing them if necessary -- and it can be even used with GStrings [if they use the same memory allocator] although that's a bit dirty. Yeti -- http://gwyddion.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Website Review - draft 2
Hi, I finally got round to finishing these pages for a second review. You can test the latest version here: http://imendio.com/~martyn/gtk/draft2b/about.html I have changed a few things compared to draft 1 which I initially did: - Fixed the pages so they work on devices like the N800. - Fixed all the typos/comments that I received from the first review. - Keep the menu on the left all times for quick navigation. - Add a sub-menu for each page for quick jump-to links. I have tested these pages with: - Windows Internet Explorer 7 - Safari (Windows beta) - Firefox (Windows/Linux) - Epiphany - N800. It has to be said, that the pages do vary slightly from browser to browser. Initially I went for a much smaller text but Tim convinced me it was a bad idea and that we should use content text at 100% size not 60% which I had tried. This does mean that in Firefox (especially on Windows) the text does look a bit bloated. Of the pages the current issues left outstanding are: - We should have a better way of sharing future ideas (dev page) - Is linking to a directory for old irc logs good enough? - Should we change the logo (I don't mind either way)? - Rework the FAQ (I will do this after so ignore that for now). - Redirections for links like http://www.gtk.org/api/xxx/ are needed. - Update the news page (will do this before committing). What are peoples thoughts on those? Have I missed anything? Does anyone have any other general comments? -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
On Sun, 2007-09-16 at 03:03 -0400, David Nečas (Yeti) wrote: On Sat, Sep 15, 2007 at 11:08:38PM -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 10:35 -0400, Alexander Larsson wrote: char * g_data_input_stream_get_line (GDataInputStream *data_stream, gsize *length, GCancellable *cancellable, GError **error); This actually reads new data from the stream, so it has to dup. One could imagine a similar call that returns some form of object instead of a string. I think it's pretty common in glib and pango at least to return g_strdup'ed strings. The no-ref-count rule is mostly for objects that have a literal ref/unref pair. Other than that, for functions that return read data from the stream, some people may have reasons to want to avoid malloc/free'ing on each line. One way to work around that is to have the function take a GString, so you can reuse the buffer from the previous line. I know most people are not a big fan of that idea though. The right interface for this type of functions have been already invented: that of glibc's getline. It can allocate new buffers, it can reuse existing buffers resizing them if necessary -- and it can be even used with GStrings [if they use the same memory allocator] although that's a bit dirty. Well, that's exactly what happens if you make the API take GString. Yeti -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Theory of good signal/event API design?
Hello, I am building an application in which pretty much all functionality is abstracted away in various modules. All these modules can be loaded and configured at will and everything communicates by passing messages/events around. Modules can listen for specific messages and respond to it, or send out messages of their own, etcetera. Pretty similar to how GTK works (in fact, it uses the GObject/GstObject system. All messages are passed over a GStreamer bus). My question: How do I determine what signals/events I should send out so that together they make for a nice module API? For now, I am simply building modules and adding signals to the application as I need them, but I bet there is a better way to figure out which signals I should add and where I should add them. Is there some theory, guidelines, tutorials, whatever about designing an event/message system, especially about what events/messages/signals to add at which locations? My application doesn't use GTK, just GObject and GStreamer, but I am asking here since GTK works in a similar way. Kind regards, -- Sander Marechal http://www.jejik.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
On Sun, Sep 16, 2007 at 12:12:11PM -0400, Behdad Esfahbod wrote: The right interface for this type of functions have been already invented: that of glibc's getline. It can allocate new buffers, it can reuse existing buffers resizing them if necessary -- and it can be even used with GStrings [if they use the same memory allocator] although that's a bit dirty. Well, that's exactly what happens if you make the API take GString. I reacted to the remark that many people do not like having to pass a GString (perhaps understandably). The `decomposed GString' interface of getline() is then the next reasonable candidate. Yeti -- http://gwyddion.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theory of good signal/event API design?
On Sun, Sep 16, 2007 at 06:28:56PM +0200, Sander Marechal wrote: I am building an application in which pretty much all functionality is abstracted away in various modules. All these modules can be loaded and configured at will and everything communicates by passing messages/events around. Modules can listen for specific messages and respond to it, or send out messages of their own, etcetera. Pretty similar to how GTK works (in fact, it uses the GObject/GstObject system. All messages are passed over a GStreamer bus). My question: How do I determine what signals/events I should send out so that together they make for a nice module API? For now, I am simply building modules and adding signals to the application as I need them, but I bet there is a better way to figure out which signals I should add and where I should add them. Is there some theory, guidelines, tutorials, whatever about designing an event/message system, especially about what events/messages/signals to add at which locations? My application doesn't use GTK, just GObject and GStreamer, but I am asking here since GTK works in a similar way. Wouldn't that be an application for dbus? Robert -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
Am Sonntag, den 16.09.2007, 12:12 -0400 schrieb Behdad Esfahbod:
On Sun, 2007-09-16 at 03:03 -0400, David Nečas (Yeti) wrote:
On Sat, Sep 15, 2007 at 11:08:38PM -0400, Behdad Esfahbod wrote:
On Fri, 2007-09-14 at 10:35 -0400, Alexander Larsson wrote:
char * g_data_input_stream_get_line (GDataInputStream *data_stream,
gsize *length,
GCancellable *cancellable,
GError **error);
This actually reads new data from the stream, so it has to dup. One
could imagine a similar call that returns some form of object instead
of a string.
I think it's pretty common in glib and pango at least to return
g_strdup'ed strings. The no-ref-count rule is mostly for objects that
have a literal ref/unref pair.
Other than that, for functions that return read data from the stream,
some people may have reasons to want to avoid malloc/free'ing on each
line. One way to work around that is to have the function take a
GString, so you can reuse the buffer from the previous line. I know
most people are not a big fan of that idea though.
The right interface for this type of functions have been
already invented: that of glibc's getline. It can allocate
new buffers, it can reuse existing buffers resizing them if
necessary -- and it can be even used with GStrings [if they
use the same memory allocator] although that's a bit dirty.
Well, that's exactly what happens if you make the API take GString.
Don't know if you try to support GString APIs, but I do not understand
any GString bashing (expect maybe for the missing reference counting).
In my opinion GString is a very useful member of the GLib API - so it
also should be used in the public API of other libraries when it makes
sense. Reading lines is such a place. A pattern I found useful for
read_line like stuff is this:
const gchar*
maman_bar_read_line (MamanBar *self, GString *buffer)
{
g_size offset;
g_return_val_if_fail (MAMAN_IS_BAR (self), NULL);
if (NULL == buffer)
{
g_string_truncate (self-priv-buffer, 0);
buffer = self-priv-buffer;
}
offset = buffer-len;
manan_bar_real_read_line (self, buffer);
return buffer-str + offset;
}
Sidenote to Alex: g_data_input_stream_get_line and its friend really
should use read as verb, not get. The verb get usually indicates
you do not change the state of an object - expect maybe for buffering
expensive data.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theory of good signal/event API design?
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
