[06:24] <latino> good evening
[06:24] <latino> can any1 help with installing video drivers
[14:01] <zubin71> jcastro, hello, is there any way that there`d be a class on doing unittesting using python?
[14:06] <Pendulum> zubin71: that's something you'd be interested in seeing in a class?
[14:07] <zubin71> Pendulum, yes, im new to python programming.... And i came across this topic pretty recently...
[14:07] <zubin71> we have a small OS community here...
[14:07] <zubin71> we`d love to have classes on unit testing...
[14:08] <zubin71> OSS*
[14:08] <zubin71> typo
[14:10] <zubin71> Pendulum, are you an ubuntu developer? python? If holding classes if difficult , it`d be great if there were at least some ubuntu community documentation...
[14:11] <Pendulum> zubin71: I'm not, but I'm a member of the Ubuntu Classroom team :)
[14:11] <Pendulum> so I'm bringing your suggestion back so we can look for an instructor :)
[14:13] <zubin71> awesome! also, it`d be great if I could help by taking sessions on a subject in a couple of months... maybe on unittesting itself, if im comfortable with it in the near future... :)
[14:25] <zubin71> Pendulum, well, c ya later! have a nice day!
[19:01] <qense> Hello everyone!
[19:01] <qense> This session I will be talking about GTK+ signals.
[19:03] <qense> Signals aren't specific to GTK+, but opportunistic programmers will deal mostly with GTK+ signals.
[19:03] <qense> What are signals?
[19:03] <qense> Signals are a nifty way of allowing an application or library to respond to certain events.
[19:04] <qense> Signals are emitted at all sorts of events, so you can listen to almost anything if you know where to look.
[19:04] <qense> I assume that most of you are using Python, so I'll be mainly using Python examples.
[19:05] <qense> However, since the PyGTK library is generated from the C GTK+ library it is not that different.
[19:05] <qense> Object.connect("signal-name", callback_function) is equal to g_signal_connect(signal_owner, "signal-name", G_CALLBACK (callback_function))
[19:06] <qense> A really good source of information is http://www.pygtk.org/docs/pygtk/
[19:06] <qense> This is the online documentation of PyGTK and you can find, amongst other things, all signals documented here.
[19:07] <qense> It is important to keep in mind that most types in the GTK+ and GObject libraries are derived from other GTK+ and/or GObject types.
[19:07] <qense> All types are derived from gobject.GObject
[19:08] <qense> A type has got all signals it's derived from.
[19:08] <qense> gobject.GObject has got only one signal 'notify'
[19:08] <qense> However, that means that all GTK+ objects have got that signal as well.
[19:09] <qense> The 'notify' signal is emitted whenever an property of the object is changed.
[19:10] <qense> However, this doesn't have to mean the value of those properties has changed, it could have been that someone or something assigned the an identical value to a property
[19:11] <qense> All GTK+ types are derived from gtk.Object (gtk.Object itself is derived from gobject.GObject)
[19:11] <qense> gtk.Object has one signal as well: 'destroy'
[19:11] <qense> This is emitted when the object is destroyed
[19:11] <qense> You use this e.g. when constructing a window.
[19:11] <qense> window = gtk.Window();
[19:11] <qense> window.show();
[19:12] <qense> window.connect("destroy", gtk.main_quit());
[19:12] <qense> gtk_main();
[19:12] <qense> Now, what did I write above?
[19:12] <qense> First I created a new window, then I showed it and then I connected a callback function.
[19:12] <qense> Whoops
[19:12] <qense> I see I connected it wrongly.
[19:13] <qense> This sure would have generated a bug.
[19:13] <qense> It should have been
[19:13] <qense>  window.connect("destroy", gtk.main_quit);
[19:13] <qense> Without the parentheses.
[19:14] <qense> What you do when connecting is first specifying the signal name, then you give the reference to the callback function.
[19:14] <qense> However, if you add the parentheses you invoke the method.
[19:14] <qense> As you can see I connected a method from a library: gtk.main_quit()
[19:14] <qense> That method ends the GTK+ loop.
[19:15] <qense> If you wouldn't connect this to a destroy signal you would have to forcefully quit the application in order for the GTK+ main loop to end.
[19:16] <qense> You can also specify locally defined methods as callback functions.
[19:16] <qense> Any questions about the working of GTK+ signals, or about what I've told so far?
[19:19] <ClassBot> ryzrecreel asked: So the callback function can be the method of another object?
[19:20] <qense> ryzrecreel: Yes, the callback can be any valid method. When connecting signals from inside a class you could e.g. also specify "self.my_wonderful_callback" method as the callback function.
[19:20] <qense> However, you can't assign MyClass.my_callback as the callback function, you need to pass the method of an instance.
[19:21] <qense> OK, lets talk a bit more about the callback function.
[19:22] <qense> Because when a signal is emitted and your well-crafted callback function is called you want to know something more about what happened.
[19:22] <qense> For that a series of arguments are sent to the callback function.
[19:22] <qense> You need to make sure that it can accept those arguments.
[19:23] <qense> Most of those callback functions look the same.
[19:23] <qense> This is what the PyGTK documentation says the callback function for the 'notify' signal should look like:
[19:23] <qense> def callback(gobject, property_spec, user_param1, ...)
[19:24] <qense> If you're defining the callback as a member of a class make sure you add an extra 'self' argument to the beginning
[19:24] <qense> the first argument of the callback function is 'gobject', but of course you can change the names in your own code.
[19:24] <qense> 'gobject' is the GObject that changed and therefore emitted the notify signal
[19:25] <qense> Most of the times you know what object you're getting since you specifically connected your callback to it, but this can be useful when you're connected to multiple objects.
[19:25] <qense> But mostly it's very useful to have a reference to the object by hand
[19:25] <qense> the second argument is 'property_spec'
[19:26] <qense> It provides information about the property that changed so you can access it if you would want  to.
[19:26] <qense> The last is user data; when connecting to a signal you can provide extra userdata as extra arguments at the end of the function.
[19:26] <qense> You'd do this:
[19:27] <qense> window.connect("destroy", gtk.main_quit, "test-window", 123);
[19:27] <qense> and the last two arguments would be the last two arguments for the callback function
[19:29] <ClassBot> lsteeger asked: What happens if the object used for the callback function in 'connect' call is destroyed before the event occurs?
[19:30] <qense> lsteeger: If you didn't disconnect the callback function first you will get an error.
[19:31] <qense> When you connect to a signal using the .connect() function the connect() function returns a handler id.
[19:31] <qense> You can pass that handler id as the sole argument for .disconnect() for disconnecting from the signal.
[19:32] <qense> Naturally, when you remove the object you connected to the callbacks are disconnected automatically.
[19:32] <qense> There are a few very interesting signals.
[19:32] <qense> gtk.Widget has the most, which means all GtkWidgets have got them.
[19:33] <qense> To give you an idea of what you can do with GTK+: all you see happening on screen is mostly done with publicly accessible signals and methods.
[19:34] <qense> There is a 'show' signal that is emitted when the show() method is called.
[19:35] <qense> There is a 'show-help' signal that is emitted when the user presses Ctrl+F1 on his or her keyboard.
[19:37] <qense> An interesting signal is "enter-notify-event", which is emitted whenever a mousebutton enters the widget.
[19:38] <qense> It is used by many widgets like buttons.
[19:38] <ClassBot> lsteeger asked: If I extend a widget, can I define 'new' signals of my own?
[19:38] <qense> lsteeger: Excellent question!
[19:39] <qense> Yes you can, it is exactly what all widgets are doing.
[19:40] <qense> You do that with the "gobject.signal_new()" function since actually signals are provided by GObject.
[19:41] <qense> Lets paste the function from the documentation:
[19:41] <qense> def gobject.signal_new(signal_name, type, flags, return_type, param_types)
[19:41] <qense> The first argument is the name you give to the signal.
[19:41] <qense> This has to be a unique name.
[19:41] <qense> The second is the object (type) you're adding the signal to.
[19:42] <qense> If you want to add a signal to myproject.MyWidget you write myproject.MyWidget there, without quotation marks.
[19:42] <qense> The third argument is an interesting one: there you provide flags.
[19:43] <qense> it goes a bit too far to explain them all, but you can make the signals do more than what I showed with the 'destroyed' signal.
[19:43] <qense> most of the times you provide something like gobject.SIGNAL_RUN_LAST as the flag.
[19:43] <qense> It has got something to do with when you emit the signal.
[19:44] <qense> If you want to provide multiple flags you use |  to separate them
[19:45] <qense> The next argument is the return type of your callback function, which could be something like gobject.TYPE_STRING or gobject.TYPE_NONE if your callback doesn't return anything at all.
[19:45] <qense> The last argument is a tuple of types of the arguments passed to the callback.
[19:46] <qense> e.g. (myproject.MyWidget, gobject.TYPE_BOOL)
[19:46] <qense> You're not finished with just defining a signal, you'll also want to emit it something.
[19:46] <qense> somehwere
[19:47] <qense> You do that with gobject.emit() method.
[19:47] <qense> The first argument is the signal name
[19:47] <qense> The others are the arguments that are sent to the callback
[19:48] <qense> If you want to emit a signal inside your MyWidget class you call self.emit()
[19:49] <ClassBot> lsteeger asked: With multiple subscribers to an object's events, does the emit() infrastructure apply a hierarchy to their invocation?
[19:50] <qense> lsteeger: Yes it does, the first callback that is connected to a signal is the first to be called.
[19:51] <qense> you can use the . stop_emission(signal_name) method to stop the emission, if you wanted to.
[19:51] <qense> lsteeger: yes, First In, First Out indeed
[19:52] <qense> However, the default signal handler is always at the end of the list.
[19:52] <qense> You'll have to use the .connect_after() method to be added after that callback.
[19:53] <qense> Default signal handlere? What is that?
[19:53] <qense> It is the default signal handler, and it's always called.
[19:53] <qense> If it's specified, of course.
[19:54] <qense> You can do that by creating a function in a class with the name "do_signal_name"
[19:55] <qense> If you want to override default signal handlers, make sure you add __gtype_name__ = "MyWidget" as a class property
[19:55] <qense> class MyWidget (gtk.Widget):
[19:55] <qense>     __gtype_name__ = "MyWidget"
[19:56] <qense> Any questions about what I've told this session?
[19:56] <qense> Or other questions?
[19:58] <qense> Remember, if you want to learn what signals there are, go to http://www.pygtk.org/docs/pygtk/ and take a look at the page of the widget you want to know more about.
[19:59] <ClassBot> ryzrecreel asked: when using quickly with glade the connects are made for you. Is there any way to over ride that?
[19:59] <qense> ryzrecreel: In the generated code you can see that the signals are connected using .connect_object()
[20:00] <qense> That means it searches for the callback functions in the object you provide.
[20:00] <qense> The callback functions are provided in Galde
[20:00] <qense> Glade
[20:00] <qense> you can change those there.
 QUESTION: In a multi-core/processor environment, do multiple event handlers get invoked asynchrounously?
[20:01] <qense> lsteeger: That doesn't depend on multi-threading, signal handlers don't get handled asynchronously, but one by one.
[20:01] <qense> OK, thank you for listening, this was all!
[20:01] <qense> This also was the last session of the Ubuntu Opportunistic Developer Week
[20:01] <qense> I hope you enjoyed it.