Re: Theory of good signal/event API design?
On Sun, 2007-09-16 at 18:28 +0200, Sander Marechal wrote: 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. You can think of signals in different ways: * Something happened - an informational message. Oh, the Loader object said 'finished', so it's done. You'd then process the loaded data or something. * I need something from somewhere - an actual request that must be handled. Oh, the HTMLWidget said 'load-image' and gave me a URI, so I guess I should download that image and feed it to the widget. * Something bad happened - an error in an object that handles a long-running process. Oh, the ImageDecoder emitted 'error' with a CORRUPTED_DATA argument, so that image file must be broken. * etc. So you can have signals that are hooks for expansion, actual requests for information, simple notifications, etc. One big thing to think about when you have signals is whether your object should be reentrant. What happens if someone calls a method on your object from a signal handler for that object? Should the object support it or not? Does it need to support at least minimal reentrancy (e.g. to let you call foo_delete_item() when you are inside a foo::item_inserted signal handler)? Federico ___ 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?
On Tue, 2007-09-25 at 09:07 +0200, Sander Marechal wrote: Andy Wingo wrote: You probably won't get terribly useful answers here, GStreamer's bus is not present in other GObject-based libraries like GTK+. Even if it were, this is probably more appropriate to gtk-app-devel. Consider writing to gstreamer-devel. I wrote there too, but got no comments. The reason I posted to the GTK lists as well is because GTK is also event/signal driven. I'm not looking for anything GStreamer (or other technology) specific, but for general information about event driven programming. Well, it's event driven, but its all done in the main event loop. It's not really like a message bus system of the kind that I think you are interested in. If you want to add additional events to the main loop you can use g_idle_add() (which also happens to be thread safe, so you can use it to pass events from worker threads to the main GUI thread). GSignal objects are in effect just lists of closures/callbacks, and are a C wrapper to provide a relatively type safe way of executing arbitrary callbacks with arbitrary data, and not dissimilar to C++ libraries such as libsigc++ and boost::signal. I suspect they are used in GTK+ whenever it is thought a library user might want to do something, were the particular event (such as an X event or user interaction with a GUI element) to occur. GSignal objects do not have anything particular to do with message busses. If you want a message bus, these days most people would I think use a session (as opposed to system) message bus using dbus. Chris ___ 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?
Chris Vine wrote: On Tue, 2007-09-25 at 09:07 +0200, Sander Marechal wrote: Andy Wingo wrote: Consider writing to gstreamer-devel. I wrote there too, but got no comments. The reason I posted to the GTK lists as well is because GTK is also event/signal driven. I'm not looking for anything GStreamer (or other technology) specific, but for general information about event driven programming. Well, it's event driven, but its all done in the main event loop. It's not really like a message bus system of the kind that I think you are interested in. Actually, I am not interested in the underlying technology at all. What I am interested in is: When you write a signal/event driven program or a widget or whatever, how do you figure out what signals to send out, so other people can actually do something useful with it? It's a purely theoretical software engineering question. So far I have been adding events to my application whenever I needed them myself, but I would like to have a nice, complete set of events so other people can do useful things with them too. I had hoped that the GTK community, having built so many widget and event driven applications, would have some kind of guidelines, theory, policy or just general good advice on that. -- Sander Marechal ___ 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?
On Tue, 2007-09-25 at 22:16 +0200, Sander Marechal wrote: [snip] Actually, I am not interested in the underlying technology at all. What I am interested in is: When you write a signal/event driven program or a widget or whatever, how do you figure out what signals to send out, so other people can actually do something useful with it? It's a purely theoretical software engineering question. So far I have been adding events to my application whenever I needed them myself, but I would like to have a nice, complete set of events so other people can do useful things with them too. I had hoped that the GTK community, having built so many widget and event driven applications, would have some kind of guidelines, theory, policy or just general good advice on that. As far as I could tell, the GTK + GLib design (and other similar libraries) seems to be based on expected use-cases of the API, so asking what potential users of the library code might want to do with its objects and API. So I guess for your code, you need to think about the objects you're exporting, and what people might think to do with them. Then write API which facilitates that. The tricky thing is getting this right - especially if your ABI / API has to be set in stone (like that for released versions of GTK + GLib). I'm sure there are many things which would be changed in GTK if they were written again now without the requirement to keep ABI / API frozen. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ 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?
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-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?
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. If your application is single threaded, why not just call functions? Calling functions and sending a message is almost the same then. Robert -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-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-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
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
