=== mRy is now known as Guest92858 === mRy is now known as Guest78285 === mRy is now known as Guest18185 === mRy is now known as Guest74526 === mRy is now known as Guest28633 === rmrf|NA is now known as rmrf === _LibertyZero is now known as LibertyZero === mRy is now known as Guest90119 === Atlan is now known as bulldog98_konv === mRy is now known as Guest83516 === mRy is now known as Guest69628 === jhernandez_afk is now known as jhernandez === mRy is now known as Guest7849 === mRy is now known as Guest56374 === mRy is now known as Guest91948 === yofel_ is now known as yofel === bregma_ is now known as bregma === mRy is now known as Guest38306 === boulabiar is now known as boulabiar| === CodeBlock is now known as CodeBlock_ [14:52] hi [15:10] time === teckfatt_ is now known as teckfatt [16:51] Ubuntu App Developer Week - Day 2 starting in ~10 minutes! :-) [16:54] ClassBot: good day to you! [16:55] hi pitti [16:55] * cdbs was waiting for this session for a really really long time [17:00] Welcome everyone to a new and exciting day of the Ubuntu App Developer Week! [17:00] Lots of interesting sessions lined up for today [17:01] Bringing you the best content from the best speakers === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: PyGTK is dead, long live PyGI! Using gobject-introspection in Python - Instructors: pitti [17:01] Check out http://ubuntu-news.org/2011/04/12/off-to-a-great-start-ubuntu-app-developer-week-day-1/ if you missed any of the sessions yesterday [17:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/12/%23ubuntu-classroom.html following the conclusion of the session. [17:02] Next up is Martin Pitt, one of the persons who know Ubuntu and its technologies inside out [17:02] He's going to be talking about porting your old PyGTK applications to the new PyGI framework, [17:02] so that they can make use of all the awesomeness of introspection. [17:02] Let's hand him the mike... [17:03] * pitti clears throat [17:03] Hello everyone! I am Martin Pitt from the Canonical Ubuntu Desktop Team. [17:03] Python is a very important and popular language in Ubuntu, we have a lot of applications written in Python for GTK and Qt/KDE. Most prominent examples are our installer Ubiquity, Software Center, our driver installer "Jockey", and our bug/crash reporting system "Apport" (shameless plug!). [17:03] By way of Quickly we also encourage application developers to use Python and GTK, as these allow you to write GUI applications both conveniently, fast, and still rather robust. [17:03] So far the package of choice for that has been PyGTK, a manually maintained Python binding for GTK, ATK, Pango, Glade, and a few other things. However, a few months ago, with the advent of GTK3, PyGTK was declared dead, so it's time to bring the banner of the great new world of its successor -- gobject-introspection -- to the world! [17:04] Tomeu Vizoso already explained what gobject-introspection (commonly abbreviated "GI") is, why we need it, and how library developers can use it to provide a machine readable and complete API/ABI description. So I'll just do a very brief summary here. [17:04] I'll concentrate on the app developer side, i. e. how to use GI typelibs in Python. [17:04] Porting existing PyGTK2 code is a topic that will keep many of us busy in the next months, so I'll explain the process and common pitfalls with that. [17:04] Finally I'll give some pointers to documentation, and will be available for some Q&A. [17:05] Everyone ready to dive in? Please let me know (here or in #-chat) when I become too fast. If I am being totally unclear, please yell and I'll handle that immediately. If you just have a followup question, let's handle these at the end. [17:05] == Quick recap: What is GI? == [17:05] So far a lot of energy was spent to write so-called "bindings", i. e. glue code which exposes an existing API such as GTK for a target language: PyGTK, libnotify-cil, or Vala's .vapi files. [17:05] This both leads to a combinatorial explosion (libraries times languages), as well as many bindings which don't exist at all, or being of low quality. In addition it is also an almost insurmountable barrier for introducing new languages, as they would need a lot of bindings before they become useful. [17:05] GI is a set of tools to generate a machine parseable and complete API/ABI description of a library, and a library (libgirepository) which can then be used by a language compiler/interpreter to automatically provide a binding for this library. [17:06] With GI you can then use every library which ships a typelib in every language which has GI support. [17:06] GI ABI/API descriptions come in two forms: [17:06] * An XML file, called the "GIR" (GI repository). These are mainly interesting for developers if they need to look up a particular detail of e. g. a method argument or an enum value. These are not actually used at runtime (as XML would be too costly to interpret every time), and thus they are shipped in the library's -dev package in Ubuntu and Debian. For example, libgtk2.0-dev ships [17:06] /usr/share/gir-1.0/Gdk-2.0.gir. [17:07] * A compiled binary form for efficient access, called the "typelib". These are the files that language bindings actually use. Ubuntu/Debian ship them in separate packages named gir--, for example, gir1.2-gtk-2.0 ships /usr/lib/girepository-1.0/Gdk-2.0.typelib. [17:07] (Yes, it's confusing that the gir1.2-* package does _not_ actually ship the .gir file; don't ask me why they were named "gir-", not "typelib-"). [17:07] == How does it work in Python? == [17:07] pygobject is the piece of software which provides Python access to GI (amongst other things, like providing the glib and GObject bindings). [17:08] The package name in Ubuntu/Debian is "python-gobject", and it should already be installed on all but the most manually trimmed down installations. [17:08] Initial GI support was added to pygobject in version 2.19.0 (August 2009), but the entire GI/pygobject/annotations stack really only stabilized in the last couple of months, so that in practice you will need at least pygobject 2.28 and the corresponding latest upstream releases of GTK and other libraries you want to use. [17:08] This means that you can only really use this with distros which are less than about three months old. For Debian/Ubuntu this means you'll need to use the current development versions, i. e. Ubuntu Natty (beta-1) or Debian experimental (most of this wasn't uploaded to unstable yet after the squeeze release). [17:09] pygobject provides a "gi.repository" module namespace which generates virtual Python modules from installed typelibs on the fly. [17:09] For example, if you install gir1.2-gtk-2.0 (it's already installed by default in Ubuntu Natty), you can do: [17:09] $ python -c 'from gi.repository import Gtk; print Gtk' [17:09] [17:10] and use it just like any other Python module. [17:10] I bet that this first example comes as an absolutely unexpected surprise to you: [17:10] $ python -c 'from gi.repository import Gtk; Gtk.MessageDialog(None, 0, Gtk.MessageType.INFO, Gtk.ButtonsType.CLOSE, "Hello World").run()' [17:10] * pitti gives everyone a minute to try this [17:11] Let's look at the corresponding C declaration: [17:11] GtkWidget* gtk_message_dialog_new (GtkWindow *parent, GtkDialogFlags flags, GtkMessageType type, GtkButtonsType buttons, const gchar *message_format, ...); [17:12] and the C call: [17:12] GtkMessageDialog* msg = gtk_message_dialog_new (NULL, 0, GTK_MESSAGE_INFO, GTK_BUTTONS_CLOSE, "Hello World"); [17:12] msg.run() [17:12] So what do we see here? [17:12] (1) The C API by and large remains valid in Python (and other languages using the GI bindings), in particular the structure, order, and data types of arguments. [17:13] There are a few exceptions which are mostly due to the different way Python works, and in some cases to make it easier to write code in Python. I'll speak about details below. But this means that you can (and should) use the normal API documentation for the C API of the library. devhelp is your friend! [17:13] (2) As Python is a proper object oriented language, pygobject (and in fact the GI typelib already) expose a GObject API as proper classes, objects, methods, and attributes. [17:13] I. e. in Python you write [17:13] b = Gtk.Button(...) [17:13] b.set_label("foo") [17:13] instead of the C gobject syntax [17:13] GtkWidget* b = gtk_button_new(...); [17:13] gtk_button_set_label(b, "foo"); [17:14] The class names in the typelib (and thus in Python) are derived from the actual class names stated in the C library (like "GtkButton"), except that the common namespace prefix ("Gtk" here) is stripped, as it becomes the name of the module. [17:14] (3) Global constants would be a heavy namespace clutter in Python, and thus pygobject exposes them in a namespaced fashion as well. [17:14] I. e. if the MessageDialog constructor expects a constant of type "GtkMessageType", then by above namespace split this becomes a Python class "Gtk.MessageType" with the individual constants as attributes, e. g. Gtk.MessageType.INFO. [17:15] (This is actually something that pygtk gets quite wrong, the constant names are quite arbitrary there) [17:15] (4) Data types are converted in a rather obvious fashion. E. g. when the C API expects an int* array pointer, you can supply a normal Python array [0, 1, 2]. A Python string "foo" will match a gchar*, Pythons None matches NULL, etc. [17:16] So the GObject API actually translates quite naturally into a real OO language like Python, and after some time of getting used to above transformation rules, you should have no trouble translating the C API documentation into their Python equivalents. [17:16] When in doubt, you can always look for the precise names, data types, etc. in the .gir instead, which shows the API broken by class, method, enum, etc, with the exact names and namespaces as they are exposed in Python. [17:16] s I mentioned above, this is in no way restricted to GTK, GNOME, or UI. For example, if you handle any kind of hardware and hotplugging, you almost certainly want to query udev, which provides a nice glib integration (with signals) through the gudev library. [17:17] This example lists all block devices (i. e. hard drives, USB sticks, etc.): [17:17] (You need to install the gir1.2-gudev-1.0 package for this) [17:17] $ python [17:17] >>> from gi.repository import GUdev [17:17] >>> c = GUdev.Client() [17:18] >>> for dev in c.query_by_subsystem("block"): [17:18] ... print dev.get_device_file() [17:18] ... [17:18] /dev/sda [17:18] /dev/sda1 [17:18] /dev/sda2 [17:18] [...] [17:18] See http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevClient.html#g-udev-client-query-by-subsystem for the corresponding C API. [17:19] GI is not even restricted to GObject, you can annotate any non-OO function based API with it. E. g. there is already a /usr/share/gir-1.0/xlib-2.0.gir (although it's horribly incomplete). These will behave as normal functions in Python (or other languages) as well. [17:20] == Other API differences == [17:20] I said above in (1) that the structure of method arguments is by and large the same in C and in GI/Python. There are some notable exceptions which you must be aware of. [17:20] === Constructors === [17:20] The biggest one is constructors. There is actually two ways of calling one: [17:20] * Use the real constructor implementation from the library. Unlike in normal Python you need to explicitly specify the constructor name: [17:21] Gtk.Button.new() [17:21] Gtk.Button.new_with_label("foo") [17:21] * Use the standard GObject constructor and pass in the initial property values as named arguments: [17:21] Gtk.Button(label="foo", use_underline=True) [17:22] The second is actually the recommended one, as it makes the meaning of the arguments more explicit, and also underlines the GObject best practice that a constructor should do nothing more than to initialize properties. But otherwise it's pretty much a matter of taste which one you use. [17:23] === Passing arrays === [17:23] Unlike C, higher level languages know how long an array is, while in the C API you need to specify that explicitly, either by terminating them with NULL or explicitly giving the length of the array in a separate argument. [17:23] Which one is used is already specified in the annotations and thus in the typelib, so Python can automatically provide the right format without the developer needing to append an extra "None" or a separate len(my_array) argument. [17:23] For example, in C you have [17:23] gtk_icon_theme_set_search_path (GtkIconTheme *icon_theme, const gchar *path[], gint n_elements) [17:24] In Python you can just call this as [17:24] my_icon_theme.set_search_path(['/foo', '/bar']) [17:24] and don't need to worry about the array size. [17:24] === Output arguments === [17:24] C functions can't return more than one argument, so they often use pointers which the function then fills out. Conversely, Python doesn't know about pointers, but can easily return more than one value as a tuple. [17:25] The annotations already describe which arguments are "out" arguments, so in Python they become part of the return tuple: first one is the "real" return value, and then all out arguments in the same order as they appear in the declaration. For example: [17:25] GdkWindow* gdk_window_get_pointer (GdkWindow *window, gint *x, gint *y, GdkModifierType *mask) [17:25] In Python you would call this like [17:25] (ptr_window, x, y, mask) = mywindow.get_pointer() [17:26] === GDestroyNotify === [17:26] Some GLib/GTK functions take a callback method and an extra "user_data" argument that is passed to the callback. [17:26] In C they often also take a "GDestroyNotify" function which is run once all callbacks are done, in order to free the memory of user_data. [17:26] As Python has automatic memory management, pygobject will take care of all this by itself, so you simply don't specify the GDestroyNotify argument. [17:26] For example: [17:27] void gtk_enumerate_printers (GtkPrinterFunc func, gpointer user_data, GDestroyNotify destroy, gboolean wait) [17:27] In Python you call this as [17:27] Gtk.enumerate_printers(my_callback, my_user_data, True) [17:27] === Non-introspectable functions/methods === [17:28] When you work with PyGI for a longer time, you'll inevitably stumble over a method that simply doesn't exist in the bindings. These usually are marked with introspectable="0" in the GIR. [17:28] In the best case this is because there are some missing annotations in the library which don't have a safe default, so GI disables these to prevent crashes. They usually come along with a corresponding warning message from g-ir-scanner, and it's usually quite easy to fix these. [17:28] So please do file upstream bugs against the relevant library when you find these [17:28] Another common case are functions which take a variable number of arguments, such as gtk_cell_area_add_with_properties(). [17:29] Varargs cannot be handled safely by libgirepository. In these cases there are often alternatives available (such as gtk_cell_area_cell_set_property()). For other cases libraries now often have a ..._v() counterpart which takes a list instead of variable arguments. [17:29] == Overrides == [17:29] A specialty of pygobject is the possibility of replacing functions, methods, or classes of the introspected library with custom code, called "overrides". [17:30] As the goal is to stay very close to the original API, they should be used and written sparsely, though. [17:30] One major use case is to provide replacements for unintrospectable methods. For example, Gtk.Menu.popup() is not introspectable in GTK, but the GTK override implements this method in terms of Gtk.Menu.popup_for_device(), so in this case the override actually helps to get closer to the original API again. [17:30] Another important case is automatic data type conversion, most prominently to allow passing unicode objects to methods which expect an UTF-8 encoded gchar*. This also actually helps to prevent workarounds in application code and maintain a clean API. [17:31] Thirdly, overrides are useful if they help to massively ease development. For example it is quite laborious to do GDBus calls or GVariant constructions with the native Gio/GLib API. [17:31] pygobject offers convenience overrides to make these a lot simpler and more Pythonic, but of course without actually breaking the original API. [17:32] Overrides are shipped in /usr/share/pyshared/gi/overrides/, and should be quite easy to understand. [17:32] e. g. in /usr/share/pyshared/gi/overrides/Gtk.py you see the "def popup()" method for Menu that I mentioned above [17:32] In general you should not even be required to know about it, as most of them really just fix stuff to work as expected. [17:33] But for the GDBus/GVariant cases it is useful to know them, as you can safe yourself a ton of extra work [17:33] == Migrating pygtk2 code == [17:33] A big task that we in Ubuntu already started in the Natty cycle, and which will continue to keep us and all other PyGTK app developers busy for a while is to port PyGTK2 applications to GTK3 and PyGI. [17:33] Note that this is really two migrations in one step, but is recommended as GTK2 still has a lot of breakage with PyGI, although I did a fair amount of work to backport fixes from GTK3 (the six applications that we ported in Natty run with PyGI and GTK2, after all). [17:34] The GTK2 → GTK3 specifics are documented at http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html and I don't want to cover them here. [17:34] If we compare the PyGTK vs. PyGI code for a "Hello" message box, we see that it's actually very similar in structure: [17:34] $ python -c 'from gi.repository import Gtk; Gtk.MessageDialog(None, 0, Gtk.MessageType.INFO, Gtk.ButtonsType.CLOSE, "Hello World").run()' [17:34] (^ pygi) [17:34] $ python -c 'import gtk; gtk.MessageDialog(None, 0, gtk.MESSAGE_INFO, gtk.BUTTONS_CLOSE, "Hello World").run()' [17:34] (^ pygtk) [17:35] So PyGTK also already did the representation of the C functions as proper classes and methods, thus if you port from PyGTK instead of from C, it'll be a lot easier. [17:35] === Step 1: The Great Renaming === [17:35] The biggest part in terms of volume of code changed is basically just a renaming exercise. [17:35] E. g. "gtk.*" now becomes "Gtk.*", and "gtk.MESSAGE_INFO" becomes "Gtk.MessageType.INFO". [17:35] Likewise, the imports need to be updated: "import gtk" becomes "from gi.repository import Gtk". [17:35] Fortunately this is is a mechanical task which can be automated. The pygobject git tree has a script "pygi-conver.sh" which is a long list of perl -pe 's/old/new/' string replacements. You can get it from http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh. [17:36] It's really blunt, but surprisingly effective, and for small applications chances are that it will already produce something which actually runs. [17:36] Note that this script is in no way finished, and should be considered a collaborative effort amongst porters. So if you have something which should be added there, please don't hesitate to open a bug or ping me or someone else on IRC (see below). We pygobject devs will be happy to improve the script. [17:36] When you just run pygi-convert.sh in your project tree, it will work on all *.py files. [17:36] If you have other Python code there which is named differently (such as bin/myprogram), you should run it once more with all these file names as argument. [17:37] === Step 2: Wash, rinse, repeat === [17:37] Once the mechanical renamings are out of the way, the tedious and laborious part starts. As Python does not have a concept of "compile-time check" and can't even check that called methods exist or that you pass the right number of parameters, you now have to enter a loop of "start your program", "click around until it breaks", "fix it", "goto 1". [17:37] The necessary changes here are really hard to generalize, as they highly depend on what your program actually does, and this will also involve the GTK 2 → 3 parts. [17:37] One thing that comes up a lot are pack_start()/pack_end() calls. [17:38] In PyGTK they have default values for "expand", "start", and "padding", but as GTK does not have them, you won't have them in PyGI either. [17:38] There even was a patch once for providing an override for them, but it was rejected as it would cement the API incompatibility. [17:38] ted as it would cement the API incompatibility. [17:38] One thing you need to be aware of is that you can't do a migration halfway: If you try to import both "gtk" and "gi.repository.Gtk" hell will break lose and you'll get nothing but program hangs and crashes, as you are trying to work with the same library in two different ways. [17:39] You can mix static and GI bindings of _different_ libraries, such as using dbus-python and GTI-GI. [17:39] erm, Gtk-GI, sorry [17:39] === Step 3: Packaging changes === [17:39] After you have your code running with PyGI and committed it to your branch and released it, you need to update the dependencies of your distro package for PyGI. [17:39] This section will be Debian/Ubuntu specific due to the involved package names, sorry. It is not be fundamentally different on other distros, though. [17:40] You should grep your code for "gi.repository" and collect a list of all imported typelibs, and then translate them into the appropriate package name. [17:40] For example, if you import "Gtk, Notify, Gudev" you need to add package dependencies to gir1.2-gtk-3.0, gir1.2-notify-0.7, and gir1.2-gudev-1.0. [17:40] At the same time you should drop the old static bindings, like python-gtk2, python-notify, etc. [17:40] Finally you should also bump the version of the python-gobject dependency to (>= 2.28) to ensure that you run with a reasonably bug free PyGI. [17:41] == RTFM & Links == [17:41] I'd like to give a list of useful links for this topic here. [17:41] This has a good general overview about GI's architecture, annotations, etc: [17:41] https://live.gnome.org/GObjectIntrospection [17:41] The interview with Jon Palmieri and Tomeu Vizoso is also an interesting read about its state: [17:41] http://www.gnomejournal.org/article/118/pygtk-gobject-and-gnome-3 [17:41] The GI/PyGI developers hang out on IRC here: [17:42] #introspection / #python on irc.gnome.org [17:42] pygobject's git tree has a very comprehensive demo showing off pretty much all available GTK widgets in PyGI: [17:42] http://git.gnome.org/browse/pygobject/tree/demos/gtk-demo [17:42] Description of the Python overrides for much easier GVariant and GDBus support [17:42] http://www.piware.de/2011/01/na-zdravi-pygi/ [17:42] Examples of previously done pygtk → pyGI ports: [17:42] Apport: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/1801 [17:42] Jockey: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/679 [17:42] gtimelog: http://bazaar.launchpad.net/~pitti/gtimelog/pygi/revision/181 [17:42] system-config-printer (work in progress): http://git.fedorahosted.org/git/?p=system-config-printer.git;a=shortlog;h=refs/heads/pygi [17:42] The gtimelog one is interesting because it makes the code work with *both* PyGTK and PyGI, whichever is available. [17:43] finally, I plan to turn this talk into a proper wiki page below https://live.gnome.org/GObjectIntrospection, so that it's more useful for posterity [17:43] == Q & A == [17:43] Thanks everyone for your attention! I'm happy to answer questions now. [17:44] toabctl asked: why is it git1.2 but girepository-1.0? [17:44] 1.0 is the ABI version of libgirepository, i. e. the client side library for gjs, pygojbect, etc. to create bindings [17:45] 1.2 is the binary format version for the .typelibs [17:45] toabctl asked: what about structs like eg GDate/GDateTime? [17:45] these actually do get exported [17:46] have a look at /usr/share/gir-1.0/GLib-2.0.gir [17:46] [17:46] [17:46] [17:46] [17:46] etc. [17:46] so as long as they are relatively simple, they do work [17:47] JanC asked: does GI support named parameters & default values, so that in Python method/function calls we can leave some parameters out? [17:48] not right now [17:48] I hear that there is a plan to support default values which are specified in the C code/annotations themselves [17:48] but otherwise you'll need an override for cases where it makes sens [17:48] e [17:49] rr0hit asked: the hello world example in pygi gives me error: TypeError: __init__() takes at most 5 arguments (6 given) . What am I doing wrong [17:49] rr0hit: I suppose you are using Ubuntu 10.10? [17:49] as I said above, I'm afraid this is all pretty new, and you need 11.04 beta [17:49] crazedpsyc asked: why did pygtk not work out well? wxpython seems just fine, and it is a C wrapper as well. [17:50] well, it did work well for years [17:50] but as I said, someone would need to maintain it, and port it to GTK3, and keep that up to date, etc. [17:50] and provide missing bindings for all other GNOMEish libraries (which were often missing) [17:51] chadadavis asked: If other distros are not using the latest GI yet, is Ubuntu planning to maintain their own GI-ported version of all these apps? [17:51] no, that would be quite crazy [17:51] There are 10 minutes remaining in the current session. [17:51] so far we just ported a lot of our Ubuntu specific stuff [17:51] and I ported gtimelog, but proposed that upstream first [17:52] so likewise, if we port upstream software, we do that upstream [17:52] e. g. GNOME will certainly appreciate these patches, it's a GNOME goal to port their pygtk stack, etc. [17:52] not sure if that answered chadadavis question? [17:52] toabctl asked: how can i create a instance of GDate/GDatetime with python? and how to map these types to the python types(datetime.date/datetime.datetime) ? [17:53] $ python -c 'from gi.repository import GLib; GLib.Date()' [17:53] etc. [17:53] (not really tested much) [17:53] but that's the idea [17:54] note that structs have always been a bit fiddly, as often GI doesn't have enough type information about members [17:54] so this only works for simple structs [17:54] the more complex ones should be turned into proper GObjects (that was necessary and done in GTK3 in some cases) [17:54] the most common case is probably the Events struct, which works good enough [17:55] zinga60 asked: can I use Python introspection like dir() for the dynamically created modules? [17:55] not right now, I'm afraid [17:55] it is possible in principle, the typelib has all necessary information [17:55] but it doesn't work right now [17:55] zinga60 asked: so as a beginner with gtk, etc. (without the need of porting from pygtk to pygi) I should use the official C API docs (to look up function signatures, etc.) and the gir-xml files to see the corresponding Python name spaces? [17:56] usually the C API docs (libgtk-3-doc etc.) should suffice [17:56] with the appropriate transformation rules that I mentioned above [17:56] There are 5 minutes remaining in the current session. [17:56] so usually you should be able to easily derive the according Python call [17:56] if not, you can look in the gir, but I seldomly found that necessary myself [17:56] out of questions :) [17:56] so, thanks everyone! [17:57] I hang out in #ubuntu-desktop, #ubuntu-devel, and also #python/#introspection on the GNOME IRC, so feel free to ask me there later [17:58] dpm: clearing the floor then [17:58] for manish_ [17:59] thanks a lot for a great session pitti! [17:59] excellent participation as well [18:01] Next up are m4n1sh (or m4n1sh_) and seiflotfy from the Zeitgeist project, who are going to talk about integrating Zeitgeist to your application === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Zeitgeist API & Zeigeist Application Integration - Instructors: m4n1sh, seiflofty [18:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/12/%23ubuntu-classroom.html following the conclusion of the session. [18:02] Hello everyone [18:02] My name is Manish Sinha [18:02] and seiflotfy is Seif Lotfy [18:02] we both work in Zeitgeist team [18:02] I am just giving a small introduction [18:03] Seif is the founder of Zeitgeist [18:03] and I work on integration and some engine work [18:03] Let us start seiflotfy :) [18:03] first a basic introduction [18:03] Zeitgeist is an event logger [18:03] which logs the events which happens on your computer [18:03] events can be opening files [18:03] closing files [18:03] creating files [18:04] connecting to internet [18:04] receiving a call [18:04] all the event logging doesnt happen automagically === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Zeitgeist API & Zeigeist Application Integration - Instructors: m4n1sh, seiflofty, manish [18:04] zeitgeist is a daemon running on your computer [18:04] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/12/%23ubuntu-classroom.html following the conclusion of the session. [18:04] whose work is to get events [18:04] means log them [18:05] when some application sends the data to it [18:05] and applications can also query events from the daemon [18:05] it is like a event store [18:05] when we talk about integration, we mean creating small plugins/extensions/addons/addins which sends the relevant events to the daemon [18:06] so basically it is the plugins which push data [18:06] all the plugins which push events are called dataproviders [18:06] their work is to only push data [18:07] like whenever you open a note, a tomboy extension tells zeitgeist that the user opened the note [18:07] this extension is called an Event [18:07] the most important part of Zeitgeist is called an event [18:07] event is a packet of information which tells the daemon of "What happened" [18:07] take the literal meaning of event [18:08] each event instance has metadata contained with it [18:08] like timestamp [18:08] what happened [18:08] how it happened [18:08] any payload [18:08] which application was involved in the event etc [18:08] zeitgeist runs as a daemon and exposes an API via DBus [18:09] DBus is an interprocess communication software [18:09] it helps applications talk to each other [18:09] to inspect the zeitgeist API [18:09] you can install d-feet from the repositories [18:09] and open it [18:09] and search for zeitgeist [18:09] you will get something like this [18:09] http://i.imgur.com/DKx0G.png [18:09] the zeitgeist API looks like this [18:09] http://zeitgeist-project.com/docs/0.5.2/dbus_api.html#org-gnome-zeitgeist-log [18:10] let us start with the basic building block of zeitgeist [18:10] an Event [18:10] how event looks like is given here [18:10] http://zeitgeist-project.com/docs/0.6/dbus_api.html#index-0 [18:10] the first thing is an event Id [18:10] which recognizes it uniquely [18:10] 2nd is Timestamp telling when it happened [18:11] 3rd is interpretation [18:11] which means [18:11] “what happened” [18:11] 4th is Manifestation [18:11] which means [18:11] “how did this happen” [18:11] then we have an actor which looks like application://tomboy.desktop [18:11] which tells which application was involved in the event [18:12] this is the metadata for an event [18:12] each event can then contain something called as Subject [18:12] each event can have more than one subject [18:12] now we should go to what is subject contained of [18:12] URI which is something like file:///tmp/my.txt [18:13] Interpretation - the abstract notion of what the subject [18:13] Manifestation - the abstract notion of how the subject is stored or available [18:13] like the subject is stored as a File [18:13] Origin - the URI where the user accessed the subject from [18:13] Mimetype [18:13] which is something like text/plain [18:13] image/png [18:14] Text - a descriptive explanation [18:14] Storage - how it is stored [18:14] I know all these were a bit boring, but it is important for a developer to understand what an event actually is [18:14] to access Zeitgeist API [18:14] you have Python bindings [18:14] C/Vala bindings [18:14] C# bindings [18:15] so you can choose your language [18:15] if you are working on a application which needs zeitgeist integration and it is coded in Python then you can use the python binding of zeitgeist [18:15] you lets move to the API [18:15] this is the API [18:15] http://zeitgeist-project.com/docs/0.5.2/dbus_api.html#org-gnome-zeitgeist-log [18:16] lets not go so deep in the API [18:16] only a few methods [18:16] like InsertEvents [18:16] which inserts events in the daemon [18:17] GetEvents - which gets events from the daemon when you specify the event ids [18:17] And 3rd [18:17] FindEventIds - you can search for events [18:17] and get back the event Ids [18:17] FindEvents - you can search for events, and get the actual events instead of just the ID [18:18] when searching for an event you use the event template [18:18] it is like a pattern [18:18] the best part is that event template are events themselves [18:18] they are represented the same way [18:18] let me take you people to an example which will clear all the doubts [18:18] we will take a working example [18:19] our example uses python API [18:19] git.gnome.org/browse/rhythmbox/tree/plugins/rbzeitgeist/rbzeitgeist/__init__.py [18:19] please open this file [18:20] now I am teaching how to push events [18:20] not pulling [18:20] check line 36 and 37 of the link I have [18:20] *gave [18:20] from zeitgeist.client import ZeitgeistClient [18:20] from zeitgeist.datamodel import Event, Subject, Interpretation, Manifestation [18:21] we imported Evebt, Subject, Manifestation and Interpretation [18:21] now we have to determine the Interpretation for Event and Subject [18:21] similarly Manifestation for Event and Subject [18:22] Event Interpretation is either LEAVE_EVENT or ACCESS_EVENT [18:22] which means "what happened" [18:23] ACCESS_EVENT means that the track started [18:23] we are at the start of the event [18:23] means we started playing the track [18:23] LEAVE_EVENT means we left the track [18:23] means track finished [18:23] Event Manifestation: USER_ACTIVITY/SCHEDULED_ACTIVITY : 120/122 - "how did this happen" [18:23] How did it happen? [18:23] It happened via User Activity or Scheduled Activity [18:24] UserActivity means that the user himself pressed Next track [18:24] Scheduled means the next track in the queue started itself [18:24] check line 120 and 122 [18:25] the list of interprerations is here http://zeitgeist-project.com/docs/0.6/ontology.html#symbol-interpretation [18:25] and list of Manifestation http://zeitgeist-project.com/docs/0.6/ontology.html#symbol-manifestation [18:25] please choose one from these list [18:25] next is Subject Interpration [18:25] Subject Interpretation: AUDIO : 135 - "what is this" [18:25] check line 135 [18:25] What is this? It is Audio :) [18:26] akshatj asked: Are there guides available on how to write a dataprovider or plugin? [18:26] akshatj: there are definitive guide. This session is meant for that :) [18:26] next is Subject Manifestation [18:26] check line 62 [18:26] Manifestion for subject asks [18:26] "how does this item exist" === jhernandez is now known as jhernandez_afk [18:26] it exists as FILE_DATA_OBJECT [18:27] all these values are from the list of Manifestation [18:27] I will give you people one more example to study yourself [18:27] It is EOG Plugin [18:27] the file is [18:27] http://bazaar.launchpad.net/~zeitgeist-dataproviders/zeitgeist-dataproviders/trunk/view/head:/eog/zeitgeist_plugin.py [18:27]