[Develop] Signal ideas
Ben Dean-Kawamura
ben at pculture.org
Thu Oct 25 14:17:09 EDT 2007
So the first part of my frontend-backend stuff is to add a signal/event system
to Miro. The main point is to make it so the frontend doesn't have to call
into the backend, it just signals an event that the backend can catch if it
wants. However, I think we should use it for slightly more than that. Here's
my initial plan, what do people think?
(This is a long email, but I don't think anything here is going to be hard to
implement. It should be easy to do in a day or two)
The signal system is will pretty much follow the gobject model, but simpler.
Objects can derive from a SignalEmitter class, then they get a connect()
method and a disconnect() method. If you want to receive notifications for a
signal you call:
object.connect("signal-name", callback_function, *extra_args)
When the object emits the signal, callback_function will be called. The first
argument will be the object emitting the signal, then there will be some
signal-specific data, finally any extra arguments you passed into connect().
To disconnect a callback, call:
object.disconnect("signal-name", callback_function)
On the other side of things, objects will get a create_signal() method that
they should call in their constructor for any signals they will use. Also
they will get an emit() method to send signals. Objects can pass additional
arguments to emit(), those arguments will be passed to signal listeners.
In a couple places we will want some kind of global signals that aren't tied
to a particular object -- for example the "error" signal below. We can handle
this by creating a singleton object that emits system-wide signals.
Here's places I think can use this system:
1) Error dialog box. Instead of the backend call notifyUnknownException(), it
can send an "error" signal"
2) Startup. When we startup there are lots of errors that can happen. This
gets especially complicated because some will happen in the backend thread, so
they are tricky to catch in the backend A clean way to handle this would be to
create 2 signals "startup-success" and "startup-failure". The frontend would
the connect to those 2 signals. If it gets the success signal it would open
the main window and go. The failure signal would also have a message attached
to it. If the frontend caught that it would pop up a dialog with the message,
then quit.
3) The database code. Right now we already have a signal system, but a lot of
code is duplicated, we have addRemoveCallback, addChangeCallback,
addAddCallback, etc. Seems like we could easily change those to signals using
the new system.
I'd also like to add a "change" signal to DDBObjects. When we build the new
widget frontend, it could connect to that signal. In the current system when
we want to do this we create a view with only a single object in it and add a
change callback to that, which seems clunky to me.
4) Possibly httpclient. We are basically using signals there too -- the
readyCallback, openConnectionCallback, etc. However, I'm not sure I want to
touch this code because it's gotten so complicated.
More information about the Develop
mailing list