=== _LibertyZero is now known as LibertyZero === croppa is now known as croppa_ === croppa_ is now known as croppa === yofel_ is now known as yfoel === yfoel is now known as yofel [13:04] hello peeple...! [13:16] anyone use Twitter ?? === SquishyNotHere is now known as squishy === bregma_ is now known as bregma [14:35] when this stuff starts? [14:38] 3.5 hours to go. [14:38] err 2.5 [14:44] der r still 4 hrs to start [14:47] can anyone tell me wht tools will b reuired during dis session === hggdh_ is now known as hggdh [15:35] hi, this is the place where class will go on right ? [15:36] yep, in approx 20 minutes the first one starts [15:36] how long to go yet ? [15:36] crazedpsyc1: cool thanks :) === CodeBlock_ is now known as CodeBlock [15:50] hello world [15:50] howdy [15:50] hey everybody [15:58] hello guys, what is going on? [15:59] has the class started yet? [15:59] Upirate: Nope, still one hour left [16:06] thanks, c2tarun: === anonymous is now known as Guest1225 [16:14] class started ? [16:14] still waiting 4 it guest [16:14] shadowking: ok :) [16:14] its gonna start in abt 45 min [16:15] 45 min ? or 4 to 5 min ? [16:15] shadowking: [16:15] "45" mins [16:16] shadowking: ok :) [16:17] you can all follow "ubuntuclassroom" on identi.ca for the announcements :) [16:17] n twitter too [16:19] i guess m gonaa go n take a nap till it starts [16:19] :P === davidcalle_ is now known as davidcalle [16:37] just half n hr more === rmrf is now known as rmrf|NA === rmrf|NA is now known as rmrf === serial is now known as Guest5786 [16:44] I thought it was starting 44 min ago [16:44] *no daylight saving time [16:44] that means it will start in 15 minutes [16:45] 15 mins to go people! [16:45] cool [16:45] i must have calculated the absense of DST the wrong way... [16:46] I did it, too [16:48] will the actual class be mirrored on twitter and identica, or just announcements [16:49] Just the announcements [16:49] ok [16:49] hey everyone [16:49] hi [16:50] hey there [16:50] hello [16:50] I'm sure there'll be logs later [16:50] are you all waiting for a class?? [16:50] yep [16:50] 10 minutes to go [16:50] crazedpsyc: the session logs will be at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html [16:50] yes [16:50] so the class is gonna be here?!! [16:50] duh [16:51] #ubuntu-classroom-chat [16:51] lol [16:51] Bannaz: eveyone thinks so ;) [16:51] alright [16:51] sorry ;) [16:51] hmm [16:51] then we'll never know [16:51] ok, guys, please take chatter to #ubuntu-classroom-chat [16:54] its a web chat ...how am I supposed to take a class here ? [16:54] the speaker of the session talks here [16:54] Bannaz: you follow in #ubuntu-classroom, and you may ask questions in here [16:54] you ask your questions in ubuntu-classroom-chat [16:55] hi [16:55] hi [16:55] hi [16:55] how can I search for chanel that in their names have freelance? [16:57] Hi! I'm Chase Douglas, and I've been working on bringing multitouch input to X.org, moving the uTouch st [16:57] ugh [16:57] oh google calendar [16:57] always in the way with your pop ups [16:59] haha [17:00] I am here from twitter after hearing about uTouch :) [17:01] WELCOME EVERYBODY TO UBUNTU APP DEVELOPER WEEK! [17:01] I'll just do a very quick intro and then quickly pass on the mic [17:01] all the info you need should be on https://wiki.ubuntu.com/UbuntuAppDeveloperWeek - which session is next, what it is about, etc [17:01] also will we put logs of the sessions that happened on there, so if you couldn't make it, you can still read up on the session afterwards [17:01] if you want to chat about what's going on or ask questions, please head to #ubuntu-classroom-chat [17:01] if you have questions, please prefix them with QUESTION: === 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: Enabling Multitouch and Gestures Using uTouch - Instructors: cnd, bregma [17:02] for example: QUESTION: What is a great device to try out multitouch with? [17:02] etc [17:02] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html following the conclusion of the session. [17:02] without further ado, I'll clear the stage for Chase Douglas and Stephen Webb [17:02] they'll talk about Enabling Multitouch and Gestures Using uTouch [17:02] Hi! I'm Chase Douglas, and I've been working on bringing multitouch input to X.org, making the uTouch stack use the new X MT work, and making improvements throughout the stack from the kernel to the toolkits [17:03] I'm Stephen Webb, I designed the geis API used in utouch [17:03] we're dividing the session into two parts [17:03] forst, I'll discuss gestures and utouch overall [17:04] then Chase will chime with multi-touch [17:04] first off, I'd like to clarify what we mean when we say "gestures" [17:04] there are fancy complex gestures like spirals and zorros made with the mouse [17:04] we refer to those as 'stroke gestures' [17:05] Those are not the gestures we are handling in uTouch. [17:05] They lack the discoverability and generality for general-purpose gestures. [17:05] The uTouch stack currently recognizes what we call 'gesture primitives'. [17:05] These are "drag", "pinch/expand", "rotate", "tap", and "touch". [17:05] The first three correspond to the linear transformations of "translate", "scale", "rotate". [17:05] The last is similar to mouse-down and mouse-up events, and a "tap" is like a single mouse click. [17:06] It is possible to build stroke gestures from these primitives if that's what you want. [17:06] we have also been discussing the use of a 'gesture langue' to do just that [17:06] The current focus in uTouch is on multi-touch gestures. [17:06] A gesture appears to an application as a stream of events. [17:06] Each event is a snapshot in time of the current status of the gesture, [17:07] including properties such as velocity, change in radius, and finger positions if available [17:07] There is a lot of hardware with a wide range of capabilities, including the number of touches supported. [17:07] Not all multi-touch devices provide all the information required for all gestures. [17:07] For example, some common notebook touchpads provide only the bounding box of the multiple touches, which is inadquate to determine rotation angles. [17:08] So, the uTouch stack consists of three basic layers [17:08] (1) the input layer (evdev in the kernel, through the /dev/input interface, and the mtdev userspace library to homogenize input) [17:08] (2) the gesture recognition engine, utouch-grail [17:08] (3) the application programming interface, utouch-geis [17:09] it's a little more complex than that in implementation, but that's the basic structure. [17:09] a very rough diagram: [17:10] In maverick and natty, grail runs in the X server so it has easy access to [17:10] window geometry. [17:10] the latest versions of grail are using XInput 2.1 to get full multi-touch support [17:11] the geis API currently connects to grail over a private X connection [17:11] applications and libraries using geis do not need to know this [17:12] in oneiric, grail will probably move into the compiz process as the X server gets replaced by "something else" [17:12] included as part of the uTouch stack are a set of diagnostic tools [17:13] gesturetest (which talks to the X server directly) [17:13] grail-gesture (which runs grail directly) [17:13] geistest (built on the API) [17:13] and others are already available, like xinput and lsinput, for examining hardware traits [17:14] the single programmable access to uTouch is through the GEIS API [17:14] API docs are available online at or in the linutouch-geis-doc package [17:15] the simplified interface was developed first and is sufficient for very basic gesture operations [17:15] te advanced interface was developed in response to initial feedback from developers and [17:15] ives finer control ofver the types of gestures reported and how the data are reported [17:15] the simplified interface requires a connection to grail (an "instance") for each window, and a list of gestures of interest [17:16] all feedback is through callbacks [17:16] en example of using the simplified interface is here: [17:17] the advanced interface requires only a single connection to grail and set of subscriptions [17:17] each filtering on window, gestures, and input device attributes [17:18] feedback is through event delivery or, optionally, callbacks [17:18] example code using the advanced interface can be found at [17:18] the advanced API is required for handling upcoming work on "gesture languages" [17:19] I believe these examples should be fairly self-explanatory, I'm going to gloss over them because we have a lot of ground to cover [17:21] there are some easier ways to take advantage of uTouch without programming to geis [17:21] first, there is libgrip, an add-on for GTK-based applications === JasonO_ is now known as JasonO [17:22] it features a singleton GestureManager that a widget registers with and receives callbacks from [17:22] examples of libgrip use include the eog and evince packages found in the utouch PPA at https://launchpad.net/~utouch-team/+archive/utouch [17:22] future work also includes Qt and native python bindings [17:23] Qt has agreed to integrate utouch-geis into their gesture infrastructure [17:23] Python bindings for utouch-geis will be available in the utouch PPA soo and should be available with oneiric [17:24] we also have ginn, which can be used to retrofit utouch gestures into applications that were not programmed to accept them [17:24] ginn ses utouch-geis to subscribe to gestures and converts them into keystrokes or mouse movements and reinjects them into the application's input stream [17:24] it uses an XML file, /etc/ginn/wishes.xml, to define the set of conversion rules for each application [17:24] ginn ships with natty today [17:25] pecisk asked: what do you mean with uTouch going included in compiz? Shouldn't it left seperated? [17:26] utouch-grail, the recognition engine, needs to know about window geometry and ordering [17:26] the easiest way to do that is to stick it some place that already has the information, like the X server [17:27] except the X server isn't really where it belongs [17:27] so, compiz for those desktops that use compiz (like Unity), and we'll try to come up with alternate solutions for others === qwebirc67471 is now known as Merhoc [17:28] tomeu asked: what are the native python bindings for? isn't enough to access that functionality through pyqt, pygobject, etc? [17:28] the utouch-geis library is not gobject-based [17:28] it's as lightweight as possible so it can be included anywhere, like games === rmrf is now known as rmrf|NA [17:29] there are already pygobject bindings for libgrip === beni is now known as Guest10897 [17:30] ok, so we're out of questions on the gestures for now [17:30] so I'm going to start talking about raw multitouch events [17:31] over this past cycle for natty, we've been working hard to bring real multitouch input through the X server [17:31] in 11.04 we'll be the first linux distro with multitouch support! [17:31] but it's just the ground work for now [17:31] and it's not quite finalized yet [17:32] so it's considered a prototype, or pre-release for now [17:32] but we do have some support for developers who want to write applications to take advantage of the new functionality [17:32] there are two layers you can develop at [17:33] you can develop at the XInput level, which we don't recommend for now but does provide some extra functionality [17:33] or you can develop using the Qt touch framework [17:33] first, I'll go over the XInput work just to give some background [17:33] XInput is an extension to the X server [17:33] X is almost 30 years old now [17:34] and no one was trying to integrate multitouch with X way back when it was created :) [17:34] over time, the X Input extension has grown to allow for various input related functionality [17:34] at first it allowed for multiple mice and keyboards to be used at the same time [17:35] this allows you to control the cursor with your trackpad and your usb mouse without having to toggle one or the other [17:35] then, support was added for grouping keyboards and mice, and for creating more than one cursor on the screen [17:35] you can try this out with the xinput command line utility, it's kinda fun to have multiple cursors :) [17:36] now, we're extending XInput to version 2.1 to add multitouch support [17:36] here's the link to the current protocol document that's in development: http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XI2proto.txt?h=inputproto-2.1-devel [17:37] I don't recommend trying to understand it though :) [17:37] so I'll just skip over it for now and hit a few key points [17:37] first, there's a touch "lifetime" [17:37] every touch has an event stream associated with it [17:37] when the touch begins, a TouchBegin event is generated [17:38] when the touch changes in any way, i.e. it moved, or the pressure changed, a TouchUpdate event is sent [17:38] when the touch leaves the touch surface, a TouchEnd event is sent [17:39] the second major point about touch input is that there are two classes of devices that affect how touch events are handled [17:39] direct touch devices are basically touchscreens [17:39] where you touch on the surface is where the touch events are sent [17:39] so if you touch with one finger over the terminal, and you touch another finger over the web browser [17:39] then each application will receive the touch event for their respective touches [17:40] in contrast, there are dependent touch devices [17:40] these comprise trackpads and devices like the Apple Magic Mouse [17:40] when you touch the surface of these devices, the touches are sent to the window that is under the cursor on the screen [17:41] Lastly, there's a layer of mouse event emulation for direct touch devices [17:41] if your application subscribes to mouse events and not touch events, and someone touches your application using a touchscreen [17:41] a mouse event stream is generated [17:41] the primary mouse button is "pressed" when you touch the screen [17:42] and the cursor moves with your finger [17:42] and then the primary mouse button is "released" when the touch ends [17:42] this allows us to add touch capabilities to new applications while not breaking mouse usage for older applications [17:43] That's enough for now about X though [17:43] I want to move on to Qt [17:43] in 11.04, we will also have a pre-release addition to the Qt framework that will support multitouch [17:43] if you have a multitouch device and want to test it out, install qt4-demos [17:44] then try out the applications in /usr/lib/qt4/examples/touch/ [17:44] there's four examples: dials, fingerpaint, knobs, and pinchzoom [17:44] I like fingerpaint the most :) [17:45] note that with the Qt framework, a trackpad device does not emit touch events by default until two or more fingers are touching the surface [17:45] here's a link to the documentation for reference: http://doc.qt.nokia.com/latest/qtouchevent.html [17:46] If you want to take a look at an example source code file for handling multitouch data, see http://doc.qt.nokia.com/latest/touch-fingerpaint-scribblearea-cpp.html [17:46] this is the fingerpaint application source code for the canvas area [17:47] if you scroll down near the bottom you'll see the ScribbleArea::event() function [17:47] this is where the multitouch events are received [17:47] in Qt, touches sent to a widget are grouped together [17:47] so once you get a touch event, you can get a list of all the touch points [17:47] and then you can iterate over them to find which of the touchpoints have changed [17:48] this is what the fingerpaint application does [17:48] with that, I'll move on from qt to get to some more stuff :) [17:48] there's also a niche library called libavg [17:48] this library is often used for games [17:49] and there are a handful of multitouch games available for it [17:49] they are all written in python, so it's a very accessible library [17:49] I won't spend any more time on it today, but you can try one of the games in natty by installing empcommand [17:49] it's a multitouch version of missile command :) [17:49] there are more games to try out in the libavg ppa [17:50] hmm... seems they aren't there yet [17:50] we'll get them uploaded soon though :) [17:50] lastly, I wanted to mention a few advanced things you can do with the XInput 2.1 extension [17:50] the first is that you can do touch "grabs" [17:51] this allows one application to control the event stream of touch events before they reach the destination application [17:51] second, though this won't be available until ubuntu 11.10, an application can "observe" touches [17:52] this may allow for ripple effects in compiz when you touch the screen, for example [17:52] There are 10 minutes remaining in the current session. [17:52] lastly, you can receive "unowned" events, which allow applications to peek at events [17:52] for more details, see the XInput 2.1 spec [17:52] with that, I'll open it up for questions :) [17:52] rydberg asked: what can you do with multitouch that you cannot do with single touch? [17:53] too many things :) [17:53] obviously all the multitouch gestures are available only with multitouch [17:53] but there are other possibilities [17:54] one can envision something like a conference table where the table is a big multitouch screen [17:54] each participant in the conference may interact with the table [17:54] there are also possibilities with object manipulation [17:54] for 3d applications [17:55] we're focusing on enabling all these, so we're hoping others have good ideas too :) [17:55] pecisk asked: what kind of licensing uTouch have? [17:55] uTouch is licensed under GPL v3 [17:55] crazedpsyc asked: do you think multitouch will ever be added to compiz? If compiz did it I'm sure the animations (eg squishing a window) would be amazing [17:56] natty already brings multitouch gestures to unity [17:56] which is based on compiz as the window manager [17:56] for example, if you touch with three fingers over a window, you'll see the resize handles [17:56] let me find a picture [17:56] http://www.omgubuntu.co.uk/2011/03/unity-love-handles-resizing-in-ubuntu-just-got-sexy/ [17:57] There are 5 minutes remaining in the current session. [17:57] we plan on adding more functionality in further releases too [17:57] we do have plans for a compiz plugin to expose multi-touch and gesture data directly [17:58] compiz support will also allow for something microsoft has termed "no touch left behind" [17:58] http://venturebeat.com/2009/05/11/with-surfaces-new-features-microsoft-wants-to-leave-no-touch-behind/ [17:59] where there is feedback to provide the user with context about where a touch occurred [17:59] and what action it performed [17:59] btw, I realized I messed up on the licensing question :) [17:59] it's LGPL v3 [18:00] the parts that are in the X.org server, such as the XInput 2.1 multitouch extension are under the X licensing (MIT/X11/BSD) [18:00] I think we're out of time now [18:00] so I want to thank everyone for participating! [18:01] come find us in #ubuntu-touch! === 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: GObject Introspection: The New Way For Developing GNOME Apps in Python, JavaScript and Others - Instructors: tomeu [18:02] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html following the conclusion of the session. [18:03] Hi, I'm a GNOME developer working at Collabora. [18:03] During the past few years it has been evident that trying to keep the GNOME APIs available to languages other than C required more resources than were available. [18:03] If you were working on a Python app using GNOME stuff, you probably realized about that. [18:03] GObject Introspection's main goal is to radically lower the amount of effort required to do that. [18:04] Feel free to make questions at any point, I will address them as I see them fitting in the plan of the talk. [18:04] == The problem == [18:04] Before introspection was available for GObject-based APIs, bindings maintainers had to produce C code that would bridge between the host language and each C API that would be made accessible. [18:04] There were code generators that saved a lot of time, but still, corner cases had to be handled manually and the generated code had to be maintained. [18:05] The total amount of work required to keep the C APIs callable from other languages was a factor of the size of the APIs, the number of languages that would be able to call into them, and the distros where such bindings had to be packaged. [18:05] As you can see, the amount of work to be done was growing very quickly, far faster than resource availability in a mature project such as GNOME. [18:06] == The solution == [18:06] The reason why bindings weren't able to generate code that wouldn't need manual modifications is that by scanning the C sources there's only so much information available. [18:07] There is critical information that bindings need that was only available in natural-language API documentation or in the code itself. [18:07] Some bindings allowed this information to be manually added and fed to the generator, but it meant that each binding had to write that extra information by themselves, maintain it, etc. [18:07] Based on that experience, it turned out to be clear that the extra information required to call the C API had to be added to the API sources themselves, so all bindings could benefit. This extra information is added in what we call "annotations" and we'll get into a bit of detail later. [18:08] But that's not enough to reduce the workload at the distro level, if each binding had to generate code based on that extra information, distros would still need to package each binding for each API and each language. [18:09] This is the reason why all the introspection information needs to be available at runtime, so a system which has bindings for, say Python, can call some new C API without having to write, package and deploy specific software for it. [18:09] So introspection information is available at runtime with acceptable performance, it is compiled into "typelibs": tightly packed files that can be mmapped and queried with low overhead. [18:10] == Workflow changes == [18:10] ASCII art overview of GI's architecture: http://live.gnome.org/GObjectIntrospection/Architecture [18:11] (I'm going to go through it, so I recommend to give it a look now) [18:11] When building a shared library, g-ir-scanner is called which will scan the source code, query GType for some more bits of info, and produce a XML file with the .gir suffix. [18:12] The .gir file is then compiled into a typelib, with the .typelib suffix. [18:12] The typelib is distributed along with the shared library and the .gir file is distributed with the header files. [18:12] When an application that uses introspection is running, the introspection bindings for its programming language will use the information in the typelib to find out how it should call the C API, being helped by the GType system and by libraries such as libffi. === JasonO_ is now known as JasonO [18:13] Now I'm going to make a pause until someone says in #*-chat that I'm not going too fast :) [18:14] == Annotations == [18:14] The needed information that is missing in the signature of the C API includes mainly: [18:14] * details about the contents of collections (element-type), [18:15] * memory management expectations (transfer xxx), [18:15] * which functions are convenience API for C users and should not be exposed (skip), [18:15] * scope of callbacks (scope), [18:15] * auxiliar arguments (closure) (array length=2), [18:15] * is NULL accepted as an input argument (allow-none), [18:15] * and more. [18:15] For more details: http://live.gnome.org/GObjectIntrospection/Annotations [18:15] Example from GTK: [18:15] --------------------- 8< ----------------- [18:15] /** [18:15] * gtk_tree_model_filter_new: [18:15] * @child_model: A #GtkTreeModel. [18:15] * @root: (allow-none): A #GtkTreePath or %NULL. [18:16] * [18:16] * Creates a new #GtkTreeModel, with @child_model as the child_model [18:16] * and @root as the virtual root. [18:16] * [18:16] * Return value: (transfer full): A new #GtkTreeModel. [18:16] */ [18:16] GtkTreeModel * [18:16] gtk_tree_model_filter_new (GtkTreeModel *child_model, [18:16] GtkTreePath *root) [18:16] --------------------- 8< ----------------- [18:16] == Other benefits == [18:16] Having available all the required information at runtime means that bindings can decide more freely when to allocate resources such as datas structures and function stubs, this allows bindings to address long-time issues such as slow startup and high memory usage. [18:16] Another consequence of bindings calling the C APIs as exposed by upstream means that documentation can be generated directly from the introspectable information, without any per-API work. [18:17] By lowering the barrier to expose APIs to other languages, more applications are being made extensible through the use of plugins. [18:18] Libpeas helps your application to expose some extension points that can be used by plugins written in C, JavaScript and Python. It is already being used by Totem, GEdit, Vinagre, Eye of GNOME, etc [18:18] == Changes for library authors == [18:18] Library authors that wish their API was available to other languages need to mainly do these three things: [18:18] * mark all the API that cannot be called from other languages with (skip) so it doesn't appear in the typelib, [18:19] that API could be considered as a convenience for C users [18:19] * make sure all the functionality is available to bindings (by adding overlapping API), [18:19] * modify their build system to generate and install the .gir and .typelib files (http://live.gnome.org/GObjectIntrospection/AutotoolsIntegration), [18:19] * add annotations as mentioned before. [18:19] In practical terms and for existing libraries, it uses to be better if people trying to use your API are the ones that submit patches adding annotations as they have a more readily available way to check for their correctness. [18:20] But for the author of the API it should be generally obvious which annotations are needed provided some exposure to how bindings use the introspected information. [18:20] == Changes for application authors == [18:20] Application authors need to be aware that, until the whole callable API becomes used through introspection by applications, they cannot expect for the annotations to be perfect. [18:20] So instead of waiting for introspection to "mature", consider starting right now and get involved upstream by pointing out issues and proposing annotations and alternative API when needed. [18:21] For now, may be best to look at the .gir to figure out how to call something, if the C docs aren't enough. [18:21] In the future there will be documentation generated for each language from the .gir files, but nobody has got anything usable yet. [18:22] so I don't have any more text to copy&paste, I will gladly answer any questions [18:23] crazedpsyc asked: is this available for languages other than C? [18:24] no, it would be really hard depending on the particular language [18:24] and the turnout would be smaller because platform code tends to be written in C in the GObject world [18:25] patrickd asked: Are there examples any where of getting started using these bindings in say, something like python? [18:25] we have some material at http://live.gnome.org/PyGObject/IntrospectionPorting [18:26] but tomorrow you will get a session here by pitti just about python and introspection [18:26] this was intended to present the basic concepts, tomorrow will be more about practical stuff [18:28] abhinav81 asked: so a language binding (say python) for a library ultimately calls the C API ? [18:28] yes, there will be some glue code in python that will be calling the same API that C programs use === jhernandez is now known as jhernandez_afk [18:29] PyGObject uses libffi directly, there's another alternative implementation that uses python's ctypes (which in turn also uses libffi) [18:29] we also have an experimental branch of pygobject by jdahlin that uses LLVM to generate wrappers [18:30] I know python best, but I guess other languages will have other mechanisms to call into C code at runtime [18:30] chadadavis asked: is the plan to currently move everything to PyGI then? What types of applications would be better off staying with PyGTK? [18:31] at this moment, pygtk won't be updated to support gtk3 === dpm_ is now known as dpm [18:31] also, pygobject+introspection doesn't support gtk2 [18:32] so my recommendation is to do what most GNOME apps do: branch and keep a maintenance branch which still uses pygtk/gtk2, and move master to introspection and gtk3 [18:32] geojorg asked: What is the current status of PyGI in Python 3 ? [18:33] haven't been personally involved on that, but I think someone at the last hackfest rebased the python3 branch [18:33] I think fedora is aiming for gtk3+python3 for their next release [18:35] I will hang around for a while in case there's some more questions before the next talk starts [18:35] JanC asked: how similar are code for PyGtk & PyGI (and thus how much work is it to port an application and keep parallel branches)? [18:36] IMO is not that dissimilar, you have some tips about porting here:http://live.gnome.org/PyGObject/IntrospectionPorting [18:37] and you can get an idea of the kind of transformations needed by reading this script: http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh [18:37] you may find that the changes between gtk2 and gtk3 are more worrying, depending on how much of the API your app uses [18:37] pecisk asked: is the any deadlines when all base apps should be correctly supported by g-i? [18:38] you say you meant base libs, so the deadline was GNOME 3 for all libraries in GNOME [18:39] no doubt some libraries will have better annotations than others [18:40] as I said before, the quality of their introspection support depends greatly on the contributions from application authors, which went on submitting annotations for the API that their app uses [18:40] crazedpsyc asked: can I get PyGI in maverick? how? [18:40] I have heard you can, but I'm not sure how (I don't use ubuntu) [18:41] but even then, maverick has gtk2 afaik, so I would recommend to try to move to natty for development [18:41] gtk2 lacks a lot of annotations because the focus has been on gtk3 [18:44] there may exist a PPA, not sure [18:49] == Where to go from here? == [18:49] http://live.gnome.org/GObjectIntrospection [18:49] In GIMPNet: #introspection, #python, #javascript, ... [18:50] Thanks for the attention and the questions, I also have to thank Martin Pitt for passing me his notes on GI [18:51] as said, he will be giving tomorrow a session focused on python and introspection [18:52] laszlok: QUESTION: is there a bug report or a wiki page about the status of generating documentation for the new API? [18:52] let me get some links for you [18:52] http://blog.tomeuvizoso.net/2011/02/generating-api-docs-from-gir-files.html [18:52] https://bugzilla.gnome.org/show_bug.cgi?id=625494 [18:53] There are 10 minutes remaining in the current session. [18:53] laszlok asked: is there a bug report or a wiki page about the status of generating documentation for the new API? [18:53] http://live.gnome.org/Hackfests/Introspection2011#line-19 [18:57] There are 5 minutes remaining in the current session. [19:00] hey, hello everyone! [19:01] thanks for joining in this session on how to internationalize your applications === 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: From English to any language: internationalizing your apps - Instructors: dpm [19:02] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html following the conclusion of the session. [19:02] ok, now that classbot is done... [19:03] first of all, thanks to tomeu for a great session [19:03] And now let's get started with translations [19:03] First the introductions [19:03]