=== _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
g4ur4vhello peeple...!13:04
Martiinianyone use Twitter ??13:16
=== SquishyNotHere is now known as squishy
=== bregma_ is now known as bregma
bugowhen this stuff starts?14:35
nigelb3.5 hours to go.14:38
nigelberr 2.514:38
shadowkingder r still 4 hrs to start14:44
shadowkingcan anyone tell me wht tools will b reuired during dis session14:47
=== hggdh_ is now known as hggdh
techbreakhi, this is the place where class will go on right ?15:35
crazedpsyc1yep, in approx 20 minutes the first one starts15:36
techbreakhow long to go yet ?15:36
techbreakcrazedpsyc1: cool thanks :)15:36
=== CodeBlock_ is now known as CodeBlock
riskyhello world15:50
akzfowlhey everybody15:50
Upiratehello guys, what is going on?15:58
Upiratehas the class started yet?15:59
c2tarunUpirate: Nope, still one hour left15:59
Upiratethanks, c2tarun:16:06
=== anonymous is now known as Guest1225
Guest1225class started ?16:14
shadowkingstill waiting 4 it guest16:14
Guest1225shadowking: ok :)16:14
shadowkingits gonna start in abt 45 min16:14
Guest122545 min ? or 4 to 5 min ?16:15
shadowking"45" mins16:15
Guest1225shadowking:  ok :)16:16
deuxpiyou can all follow "ubuntuclassroom" on identi.ca for the announcements :)16:17
shadowkingn twitter too16:17
shadowkingi guess m gonaa go n take a nap till it starts16:19
=== davidcalle_ is now known as davidcalle
shadowkingjust half n hr more16:37
=== rmrf is now known as rmrf|NA
=== rmrf|NA is now known as rmrf
=== serial is now known as Guest5786
crazedpsycI thought it was starting 44 min ago16:44
Arcidias*no daylight saving time16:44
Arcidiasthat means it will start in 15 minutes16:44
nigelb15 mins to go people!16:45
crazedpsyci must have calculated the absense of DST the wrong way...16:45
ArcidiasI did it, too16:46
crazedpsycwill the actual class be mirrored on twitter and identica, or just announcements16:48
nigelbJust the announcements16:49
Bannazhey everyone16:49
Bannazhey there16:50
ArcidiasI'm sure there'll be logs later16:50
Bannazare you all waiting for a class??16:50
Arcidias10 minutes to go16:50
deuxpicrazedpsyc: the session logs will be at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html16:50
Bannazso the class is gonna be here?!!16:50
c2tarunBannaz: eveyone thinks so ;)16:51
Andy80sorry ;)16:51
Bannazthen we'll never know16:51
nigelbok, guys, please take chatter to #ubuntu-classroom-chat16:51
Bannazits a web chat ...how am I supposed to take a class here ?16:54
Arcidiasthe speaker of the session talks here16:54
deuxpiBannaz: you follow in #ubuntu-classroom, and you may ask questions in here16:54
Arcidiasyou ask your questions in ubuntu-classroom-chat16:54
goliath_how can I search for chanel that in their names have freelance?16:55
cndHi! I'm Chase Douglas, and I've been working on bringing multitouch input to X.org, moving the uTouch st16:57
cndoh google calendar16:57
cndalways in the way with your pop ups16:57
Error404NotFoundI am here from twitter after hearing about uTouch :)17:00
dholbach I'll just do a very quick intro and then quickly pass on the mic17:01
dholbach all the info you need should be on https://wiki.ubuntu.com/UbuntuAppDeveloperWeek - which session is next, what it is about, etc17:01
dholbach 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 afterwards17:01
dholbachif you want to chat about what's going on or ask questions, please head to #ubuntu-classroom-chat17:01
dholbachif you have questions, please prefix them with QUESTION:17:01
=== 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
dholbachfor example:         QUESTION: What is a great device to try out multitouch with?17:02
ClassBotLogs 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
dholbachwithout further ado, I'll clear the stage for Chase Douglas and Stephen Webb17:02
dholbachthey'll talk about Enabling Multitouch and Gestures Using uTouch17:02
cndHi! 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 toolkits17:02
bregmaI'm Stephen Webb, I designed the geis API used in utouch17:03
bregmawe're dividing the session into two parts17:03
bregmaforst, I'll discuss gestures and utouch overall17:03
bregmathen Chase will chime with multi-touch17:04
bregmafirst off, I'd like to clarify what we mean when we say "gestures"17:04
bregmathere are fancy complex gestures like spirals and zorros made with the mouse17:04
bregmawe refer to those as 'stroke gestures'17:04
bregmaThose are not the gestures we are handling in uTouch.17:05
bregmaThey lack the discoverability and generality for general-purpose gestures.17:05
bregmaThe uTouch stack currently recognizes what we call 'gesture primitives'.17:05
bregmaThese are "drag", "pinch/expand", "rotate", "tap", and "touch".17:05
bregmaThe first three correspond to the linear transformations of "translate", "scale", "rotate".17:05
bregmaThe last is similar to mouse-down and mouse-up events, and a "tap" is like a single mouse click.17:05
bregmaIt is possible to build stroke gestures from these primitives if that's what you want.17:06
bregmawe have also been discussing the use of a 'gesture langue' to do just that17:06
bregmaThe current focus in uTouch is on multi-touch gestures.17:06
bregmaA gesture appears to an application as a stream of events.17:06
bregmaEach event is a snapshot in time of the current status of the gesture,17:06
bregmaincluding properties such as velocity, change in radius, and finger positions if available17:07
bregmaThere is a lot of hardware with a wide range of capabilities, including the number of touches supported.17:07
bregmaNot all multi-touch devices provide all the information required for all gestures.17:07
bregmaFor example, some common notebook touchpads provide only the bounding box of the multiple touches, which is inadquate to determine rotation angles.17:07
bregmaSo, the uTouch stack consists of three basic layers17:08
bregma(1) the input layer (evdev in the kernel, through the /dev/input interface, and the mtdev userspace library to homogenize input)17:08
bregma(2) the gesture recognition engine, utouch-grail17:08
bregma(3) the application programming interface, utouch-geis17:08
bregmait's a little more complex than that in implementation, but that's the basic structure.17:09
bregmaa very rough diagram: <https://docs.google.com/drawings/edit?id=1isTrkSWDH7OWKLi_aialasw9xjb0pziK9yjKUR1yt9c&hl=en&authkey=CLiA9fEG>17:09
bregmaIn maverick and natty, grail runs in the X server so it has easy access to17:10
bregmawindow geometry.17:10
bregmathe latest versions of grail are using XInput 2.1 to get full multi-touch support17:10
bregmathe geis API currently connects to grail over a private X connection17:11
bregmaapplications and libraries using geis do not need to know this17:11
bregmain oneiric, grail will probably move into the compiz process as the X server gets replaced by "something else"17:12
bregmaincluded as part of the uTouch stack are a set of diagnostic tools17:12
bregmagesturetest (which talks to the X server directly)17:13
bregmagrail-gesture (which runs grail directly)17:13
bregmageistest (built on the API)17:13
bregmaand others are already available, like xinput and lsinput, for examining hardware traits17:13
bregmathe single programmable access to uTouch is through the GEIS API17:14
bregmaAPI docs are available online at <http://people.canonical.com/~stephenwebb/geis-v2-api/> or in the linutouch-geis-doc package17:14
bregmathe simplified interface was developed first and is sufficient for very basic gesture operations17:15
bregmate advanced interface was developed in response to initial feedback from developers and17:15
bregmaives finer control ofver the types of gestures reported and how the data are reported17:15
bregmathe simplified interface requires a connection to grail (an "instance") for each window, and a list of gestures of interest17:15
bregmaall feedback is through callbacks17:16
bregmaen example of using the simplified interface is here: <http://pastebin.com/ju1Tgq4N>17:16
bregmathe advanced interface requires only a single connection to grail and set of subscriptions17:17
bregmaeach filtering on window, gestures, and input device attributes17:17
bregmafeedback is through event delivery or, optionally, callbacks17:18
bregmaexample code using the advanced interface can be found at <http://people.canonical.com/~stephenwebb/geis-v2-api/geis2_8c-example.html>17:18
bregmathe advanced API is required for handling upcoming work on "gesture languages"17:18
bregmaI believe these examples should be fairly self-explanatory, I'm going to gloss over them because we have a lot of ground to cover17:19
bregmathere are some easier ways to take advantage of uTouch without programming to geis17:21
bregmafirst, there is libgrip, an add-on for GTK-based applications17:21
=== JasonO_ is now known as JasonO
bregmait features a singleton GestureManager that a widget registers with and receives callbacks from17:22
bregmaexamples of libgrip use include the eog and evince packages found in the utouch PPA at https://launchpad.net/~utouch-team/+archive/utouch17:22
bregmafuture work also includes Qt and native python bindings17:22
bregmaQt has agreed to integrate utouch-geis into their gesture infrastructure17:23
bregmaPython bindings for utouch-geis will be available in the utouch PPA soo and should be available with oneiric17:23
bregmawe also have ginn, which can be used to retrofit utouch gestures into applications that were not programmed to accept them17:24
bregmaginn ses utouch-geis to subscribe to gestures and converts them into keystrokes or mouse movements and reinjects them into the application's input stream17:24
bregmait uses an XML file, /etc/ginn/wishes.xml, to define the set of conversion rules for each application17:24
bregmaginn ships with natty today17:24
ClassBotpecisk asked: what do you mean with uTouch going included in compiz? Shouldn't it left seperated?17:25
bregmautouch-grail, the recognition engine, needs to know about window geometry and ordering17:26
bregmathe easiest way to do that is to stick it some place that already has the information, like the X server17:26
bregmaexcept the X server isn't really where it belongs17:27
bregmaso, compiz for those desktops that use compiz (like Unity), and we'll try to come up with alternate solutions for others17:27
=== qwebirc67471 is now known as Merhoc
ClassBottomeu asked: what are the native python bindings for? isn't enough to access that functionality through pyqt, pygobject, etc?17:28
bregmathe utouch-geis library is not gobject-based17:28
bregmait's as lightweight as possible so it can be included anywhere, like games17:28
=== rmrf is now known as rmrf|NA
bregmathere are already pygobject bindings for libgrip17:29
=== beni is now known as Guest10897
cndok, so we're out of questions on the gestures for now17:30
cndso I'm going to start talking about raw multitouch events17:30
cndover this past cycle for natty, we've been working hard to bring real multitouch input through the X server17:31
cndin 11.04 we'll be the first linux distro with multitouch support!17:31
cndbut it's just the ground work for now17:31
cndand it's not quite finalized yet17:31
cndso it's considered a prototype, or pre-release for now17:32
cndbut we do have some support for developers who want to write applications to take advantage of the new functionality17:32
cndthere are two layers you can develop at17:32
cndyou can develop at the XInput level, which we don't recommend for now but does provide some extra functionality17:33
cndor you can develop using the Qt touch framework17:33
cndfirst, I'll go over the XInput work just to give some background17:33
cndXInput is an extension to the X server17:33
cndX is almost 30 years old now17:33
cndand no one was trying to integrate multitouch with X way back when it was created :)17:34
cndover time, the X Input extension has grown to allow for various input related functionality17:34
cndat first it allowed for multiple mice and keyboards to be used at the same time17:34
cndthis allows you to control the cursor with your trackpad and your usb mouse without having to toggle one or the other17:35
cndthen, support was added for grouping keyboards and mice, and for creating more than one cursor on the screen17:35
cndyou can try this out with the xinput command line utility, it's kinda fun to have multiple cursors :)17:35
cndnow, we're extending XInput to version 2.1 to add multitouch support17:36
cndhere'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-devel17:36
cndI don't recommend trying to understand it though :)17:37
cndso I'll just skip over it for now and hit a few key points17:37
cndfirst, there's a touch "lifetime"17:37
cndevery touch has an event stream associated with it17:37
cndwhen the touch begins, a TouchBegin event is generated17:37
cndwhen the touch changes in any way, i.e. it moved, or the pressure changed, a TouchUpdate event is sent17:38
cndwhen the touch leaves the touch surface, a TouchEnd event is sent17:38
cndthe second major point about touch input is that there are two classes of devices that affect how touch events are handled17:39
cnddirect touch devices are basically touchscreens17:39
cndwhere you touch on the surface is where the touch events are sent17:39
cndso if you touch with one finger over the terminal, and you touch another finger over the web browser17:39
cndthen each application will receive the touch event for their respective touches17:39
cndin contrast, there are dependent touch devices17:40
cndthese comprise trackpads and devices like the Apple Magic Mouse17:40
cndwhen you touch the surface of these devices, the touches are sent to the window that is under the cursor on the screen17:40
cndLastly, there's a layer of mouse event emulation for direct touch devices17:41
cndif your application subscribes to mouse events and not touch events, and someone touches your application using a touchscreen17:41
cnda mouse event stream is generated17:41
cndthe primary mouse button is "pressed" when you touch the screen17:41
cndand the cursor moves with your finger17:42
cndand then the primary mouse button is "released" when the touch ends17:42
cndthis allows us to add touch capabilities to new applications while not breaking mouse usage for older applications17:42
cndThat's enough for now about X though17:43
cndI want to move on to Qt17:43
cndin 11.04, we will also have a pre-release addition to the Qt framework that will support multitouch17:43
cndif you have a multitouch device and want to test it out, install qt4-demos17:43
cndthen try out the applications in /usr/lib/qt4/examples/touch/17:44
cndthere's four examples: dials, fingerpaint, knobs, and pinchzoom17:44
cndI like fingerpaint the most :)17:44
cndnote that with the Qt framework, a trackpad device does not emit touch events by default until two or more fingers are touching the surface17:45
cndhere's a link to the documentation for reference: http://doc.qt.nokia.com/latest/qtouchevent.html17:45
cndIf 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.html17:46
cndthis is the fingerpaint application source code for the canvas area17:46
cndif you scroll down near the bottom you'll see the ScribbleArea::event() function17:47
cndthis is where the multitouch events are received17:47
cndin Qt, touches sent to a widget are grouped together17:47
cndso once you get a touch event, you can get a list of all the touch points17:47
cndand then you can iterate over them to find which of the touchpoints have changed17:47
cndthis is what the fingerpaint application does17:48
cndwith that, I'll move on from qt to get to some more stuff :)17:48
cndthere's also a niche library called libavg17:48
cndthis library is often used for games17:48
cndand there are a handful of multitouch games available for it17:49
cndthey are all written in python, so it's a very accessible library17:49
cndI won't spend any more time on it today, but you can try one of the games in natty by installing empcommand17:49
cndit's a multitouch version of missile command :)17:49
cndthere are more games to try out in the libavg ppa17:49
cndhmm... seems they aren't there yet17:50
cndwe'll get them uploaded soon though :)17:50
cndlastly, I wanted to mention a few advanced things you can do with the XInput 2.1 extension17:50
cndthe first is that you can do touch "grabs"17:50
cndthis allows one application to control the event stream of touch events before they reach the destination application17:51
cndsecond, though this won't be available until ubuntu 11.10, an application can "observe" touches17:51
cndthis may allow for ripple effects in compiz when you touch the screen, for example17:52
ClassBotThere are 10 minutes remaining in the current session.17:52
cndlastly, you can receive "unowned" events, which allow applications to peek at events17:52
cndfor more details, see the XInput 2.1 spec17:52
cndwith that, I'll open it up for questions :)17:52
ClassBotrydberg asked: what can you do with multitouch that you cannot do with single touch?17:52
cndtoo many things :)17:53
cndobviously all the multitouch gestures are available only with multitouch17:53
cndbut there are other possibilities17:53
cndone can envision something like a conference table where the table is a big multitouch screen17:54
cndeach participant in the conference may interact with the table17:54
cndthere are also possibilities with object manipulation17:54
cndfor 3d applications17:54
cndwe're focusing on enabling all these, so we're hoping others have good ideas too :)17:55
ClassBotpecisk asked: what kind of licensing uTouch have?17:55
cnduTouch is licensed under GPL v317:55
ClassBotcrazedpsyc 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 amazing17:55
cndnatty already brings multitouch gestures to unity17:56
cndwhich is based on compiz as the window manager17:56
cndfor example, if you touch with three fingers over a window, you'll see the resize handles17:56
cndlet me find a picture17:56
ClassBotThere are 5 minutes remaining in the current session.17:57
cndwe plan on adding more functionality in further releases too17:57
bregmawe do have plans for a compiz plugin to expose multi-touch and gesture data directly17:57
cndcompiz support will also allow for something microsoft has termed "no touch left behind"17:58
cndwhere there is feedback to provide the user with context about where a touch occurred17:59
cndand what action it performed17:59
cndbtw, I realized I messed up on the licensing question :)17:59
cndit's LGPL v317:59
cndthe 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
cndI think we're out of time now18:00
cndso I want to thank everyone for participating!18:00
cndcome find us in #ubuntu-touch!18:01
=== 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
ClassBotLogs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html following the conclusion of the session.18:02
tomeuHi, I'm a GNOME developer working at Collabora.18:03
tomeuDuring 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
tomeuIf you were working on a Python app using GNOME stuff, you probably realized about that.18:03
tomeuGObject Introspection's main goal is to radically lower the amount of effort required to do that.18:03
tomeuFeel free to make questions at any point, I will address them as I see them fitting in the plan of the talk.18:04
tomeu== The problem ==18:04
tomeuBefore 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
tomeuThere 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:04
tomeuThe 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
tomeuAs 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:05
tomeu== The solution ==18:06
tomeuThe 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:06
tomeuThere is critical information that bindings need that was only available in natural-language API documentation or in the code itself.18:07
tomeuSome 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
tomeuBased 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:07
tomeuBut 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:08
tomeuThis 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
tomeuSo 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:09
tomeu== Workflow changes ==18:10
tomeuASCII art overview of GI's architecture: http://live.gnome.org/GObjectIntrospection/Architecture18:10
tomeu(I'm going to go through it, so I recommend to give it a look now)18:11
tomeuWhen 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:11
tomeuThe .gir file is then compiled into a typelib, with the .typelib suffix.18:12
tomeuThe typelib is distributed along with the shared library and the .gir file is distributed with the header files.18:12
tomeuWhen 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.18:12
=== JasonO_ is now known as JasonO
tomeuNow I'm going to make a pause until someone says in #*-chat that I'm not going too fast :)18:13
tomeu== Annotations ==18:14
tomeuThe needed information that is missing in the signature of the C API includes mainly:18:14
tomeu* details about the contents of collections (element-type),18:14
tomeu* memory management expectations (transfer xxx),18:15
tomeu* which functions are convenience API for C users and should not be exposed (skip),18:15
tomeu* scope of callbacks (scope),18:15
tomeu* auxiliar arguments (closure) (array length=2),18:15
tomeu* is NULL accepted as an input argument (allow-none),18:15
tomeu* and more.18:15
tomeuFor more details: http://live.gnome.org/GObjectIntrospection/Annotations18:15
tomeuExample from GTK:18:15
tomeu--------------------- 8< -----------------18:15
tomeu * gtk_tree_model_filter_new:18:15
tomeu * @child_model: A #GtkTreeModel.18:15
tomeu * @root: (allow-none): A #GtkTreePath or %NULL.18:15
tomeu *18:16
tomeu * Creates a new #GtkTreeModel, with @child_model as the child_model18:16
tomeu * and @root as the virtual root.18:16
tomeu *18:16
tomeu * Return value: (transfer full): A new #GtkTreeModel.18:16
tomeu */18:16
tomeuGtkTreeModel *18:16
tomeugtk_tree_model_filter_new (GtkTreeModel *child_model,18:16
tomeu                           GtkTreePath  *root)18:16
tomeu--------------------- 8< -----------------18:16
tomeu== Other benefits ==18:16
tomeuHaving 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
tomeuAnother 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:16
tomeuBy lowering the barrier to expose APIs to other languages, more applications are being made extensible through the use of plugins.18:17
tomeuLibpeas 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, etc18:18
tomeu== Changes for library authors ==18:18
tomeuLibrary authors that wish their API was available to other languages need to mainly do these three things:18:18
tomeu* mark all the API that cannot be called from other languages with (skip) so it doesn't appear in the typelib,18:18
tomeuthat API could be considered as a convenience for C users18:19
tomeu* make sure all the functionality is available to bindings (by adding overlapping API),18:19
tomeu* modify their build system to generate and install the .gir and .typelib files (http://live.gnome.org/GObjectIntrospection/AutotoolsIntegration),18:19
tomeu* add annotations as mentioned before.18:19
tomeuIn 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:19
tomeuBut 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
tomeu== Changes for application authors ==18:20
tomeuApplication 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
tomeuSo 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:20
tomeuFor 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
tomeuIn the future there will be documentation generated for each language from the .gir files, but nobody has got anything usable yet.18:21
tomeuso I don't have any more text to copy&paste, I will gladly answer any questions18:22
ClassBotcrazedpsyc asked: is this available for languages other than C?18:23
tomeuno, it would be really hard depending on the particular language18:24
tomeuand the turnout would be smaller because platform code tends to be written in C in the GObject world18:24
ClassBotpatrickd asked: Are there examples any where of getting started using these bindings in say, something like python?18:25
tomeuwe have some material at http://live.gnome.org/PyGObject/IntrospectionPorting18:25
tomeubut tomorrow you will get a session here by pitti just about python and introspection18:26
tomeuthis was intended to present the basic concepts, tomorrow will be more about practical stuff18:26
ClassBotabhinav81 asked: so a language binding (say python) for a library ultimately calls the C API ?18:28
tomeuyes, there will be some glue code in python that will be calling the same API that C programs use18:28
=== jhernandez is now known as jhernandez_afk
tomeuPyGObject uses libffi directly, there's another alternative implementation that uses python's ctypes (which in turn also uses libffi)18:29
tomeuwe also have an experimental branch of pygobject by jdahlin that uses LLVM to generate wrappers18:29
tomeuI know python best, but I guess other languages will have other mechanisms to call into C code at runtime18:30
ClassBotchadadavis asked: is the plan to currently move everything to PyGI then? What types of applications would be better off staying with PyGTK?18:30
tomeuat this moment, pygtk won't be updated to support gtk318:31
=== dpm_ is now known as dpm
tomeualso, pygobject+introspection doesn't support gtk218:31
tomeuso 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 gtk318:32
ClassBotgeojorg asked: What is the current status of PyGI in Python 3 ?18:32
tomeuhaven't been personally involved on that, but I think someone at the last hackfest rebased the python3 branch18:33
tomeuI think fedora is aiming for gtk3+python3 for their next release18:33
tomeuI will hang around for a while in case there's some more questions before the next talk starts18:35
ClassBotJanC asked: how similar are code for PyGtk & PyGI (and thus how much work is it to port an application and keep parallel branches)?18:35
tomeuIMO is not that dissimilar, you have some tips about porting here:http://live.gnome.org/PyGObject/IntrospectionPorting18:36
tomeuand you can get an idea of the kind of transformations needed by reading this script: http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh18:37
tomeuyou may find that the changes between gtk2 and gtk3 are more worrying, depending on how much of the API your app uses18:37
ClassBotpecisk asked: is the any deadlines when all base apps should be correctly supported by g-i?18:37
tomeuyou say you meant base libs, so the deadline was GNOME 3 for all libraries in GNOME18:38
tomeuno doubt some libraries will have better annotations than others18:39
tomeuas 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 uses18:40
ClassBotcrazedpsyc asked: can I get PyGI in maverick? how?18:40
tomeuI have heard you can, but I'm not sure how (I don't use ubuntu)18:40
tomeubut even then, maverick has gtk2 afaik, so I would recommend to try to move to natty for development18:41
tomeugtk2 lacks a lot of annotations because the focus has been on gtk318:41
tomeuthere may exist a PPA, not sure18:44
tomeu== Where to go from here? ==18:49
tomeuIn GIMPNet: #introspection, #python, #javascript, ...18:49
tomeuThanks for the attention and the questions, I also have to thank Martin Pitt for passing me his notes on GI18:50
tomeuas said, he will be giving tomorrow a session focused on python and introspection18:51
tomeulaszlok: QUESTION: is there a bug report or a wiki page about the status of generating documentation for the new API?18:52
tomeulet me get some links for you18:52
ClassBotThere are 10 minutes remaining in the current session.18:53
ClassBotlaszlok asked: is there a bug report or a wiki page about the status of generating documentation for the new API?18:53
ClassBotThere are 5 minutes remaining in the current session.18:57
dpmhey, hello everyone!19:00
dpmthanks for joining in this session on how to internationalize your applications19:01
=== 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
ClassBotLogs 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
dpmok, now that classbot is done...19:02
dpmfirst of all, thanks to tomeu for a great session19:03
dpmAnd now let's get started with translations19:03
dpmFirst the introductions19:03
dpmI'm David Planella, and I work in the Community team at Canonical as the Ubuntu Translations Coordinator19:03
dpmUsually I work more on the community side of things, with the always awesome Ubuntu translation teams19:04
dpmBut today I've put my developer hat to show you how easy it is to get your app ready to speak a multitude of languages19:05
dpmand set up so that the community can translate it.19:05
dpmRegardless of the programming language, the process of adding internationalization support to an application is not only fairly easy19:05
dpmbut also, on a high level view, the same for all programming languages.19:06
dpmThis means that after this session you should have a pretty good overview on what it takes to make your application translatable19:06
dpmand you can apply this to any programming language, slightly adapting the syntax, of course.19:06
dpmIn order for you to see how it all fits together, I've based the talk on a common framework that can get you quickstarted in just a few minutes19:07
dpmI've used the Python programming language and Quickly19:07
dpmLet's start with some background concepts to make it easier to understand the steps we'll be doing later on19:08
dpmSo let's have a quick look at the main players involved in the internationalization game:19:09
dpm 19:09
dpmBackground Concepts19:09
dpm 19:09
dpmGNU Gettext19:09
dpmGettext is the underlying and most widely used technology to enable translations of Open Source projects.19:09
dpmIt defines a standard format of translation files translators can do their work with (PO files, more on them in a minute)19:09
dpmand lets applications load those translations compiled in a binary format (MO files) at runtime.19:10
dpmIt has implementations for many programming languages, and amongst them, of course, Python.19:10
dpmYou'll find that the comprehensive gettext manual at http://www.gnu.org/software/gettext/manual/gettext.html can be a very useful reference,19:10
dpmThe Python implementation of the gettext API is what we'll use to internationalize our project with Quickly today.19:10
dpmNeedless to say, it also comes with some nifty documentation at http://docs.python.org/library/gettext.html19:11
dpm* {i} In short, gettext does all the heavy lifting involved in exposing your application for translation and loading the translations for the end user19:11
dpm 19:12
dpmIntltool is a higher level tool that adds functionality to gettext by allowing the extraction of translatable strings from a variety of file formats19:12
dpmIt has also become a standard tool when implementing internationalization for OSS projects.19:13
dpmNearly all (if not all) GNOME projects, for example, use intltool.19:13
dpm* {i} intltool handles the translations of things such as the desktop shortcut of your application19:14
dpm 19:14
dpmPython-distutils-extra is a python package that makes it easy to integrate themable icons, documentation and gettext based translations in your python install and build tools, and it's basically an enhancement to python-distutils.19:14
dpmThe project's page is at http://www.glatzor.de/projects/python-distutils-extra/19:15
dpm* /!\ Note that this tool is Python-specific. I'm mentioning it here because we're going to be talking of a practical example with Python. If your application were a C application you'd probably use autotool rules to achieve the same result19:15
dpm 19:15
dpmThe three above technologies (gettext, intltool, python-distutils-extra) are transparently used by Quickly, so we won't get into much more detail for now.19:15
dpmI just want you to get an idea of what we're talking about19:16
dpmThere are also more aspects involved in internationalizing applications, such as font rendering, input methods, etc., but this should get you started for now.19:16
dpm 19:16
dpmI'll be very brief here and let you figure out more on quickly as we go along19:16
dpmFor now, it will suffice give you a teaser and tell you that it is the tool which brings back the fun in writing applications! ;-)19:16
dpm 19:17
dpmFinally, a tool that is not strictly needed for internationalization (or the shorter form: i18n), but that can help you build an active translation community around your project19:17
dpmwhich will be the next step after your project adds i18n support19:18
dpm 19:18
dpmLaunchpad Translations19:18
dpmLaunchpad Translations (https://translations.launchpad.net/) is the collaborative online tool which allows translation communities to be brought together and translate applications online through its web UI.19:18
dpmApart from the very polished UI to provide translations, it has other nice features such as message sharing across project series (translate one message in a series and it instantly propagates to all other shared series),19:18
dpmglobal suggestions (suggestions of translations across _all_ projects in Launchpad), automatic imports of translations and automatic commits to bzr branches, several levels of permissions, and a huge translator base.19:19
dpmOn the right hand side of the URL I gave you you can see that there are quite a lot of projects using Launchpad to make translations easy both for developers and translators.19:20
dpmBear with me: we're nearly there - let's also quickly trow in and review a couple of concepts related to the gettext technology19:20
dpm 19:20
dpmGettext: MO files19:20
dpmThe message catalog, or MO file (for Machine Object) is the binary file that is actually used to load translations in a running system.19:21
dpmIt is created from a textual PO (more on that in a bit), which is used as the source, generally by a tool called msgfmt.19:21
dpmMessage catalogs are used for performance reasons, as they are implemented as a binary hash table that is much more efficient to look up at runtime than textual PO files19:21
dpm* {i} .mo files are the binary files installed in the system where the application loads the translations from, using gettext19:22
dpm 19:22
dpmGettext: PO files19:22
dpmPO file stands for Portable Object file, and are the textual files translators work with to provide translations. They are plain text files with a special format:19:22
dpm  msgid "English message"19:22
dpm  msgstr "Traducció al català" <- Translated string19:22
dpm(message pairs containing the original messages from the application, and its corresponding translation)19:22
dpmYou can see an example of a PO file here:19:23
dpm* {i} Translators provide translations in PO files. If they use an online translation system they won't directly work with them, but your project sources will still contain them19:23
dpm* {i} In each application source tree there is generally a PO file per language, named after the language code. E.g. ca.po, de.po, zh_CN.po, etc.19:23
dpm 19:23
dpmGettext: POT files19:23
dpmOnce your project has added i18n support, you'll need to give translators an updated list of translatable messages they can start translating.19:23
dpmYou'll also need to update this list whenever you add new messages to your application.19:23
dpmYou achieve that through POT files, or simply templates in l10n (localization) slang (Portable Object Template).19:24
dpmThey are textual files with the same format as PO files,19:24
dpmbut they are empty of translations and are used as a template or stencil to create PO files from.19:24
dpm* {i} There are special tools to update templates. Generally intltool is used, often called from a build system rule or a higher level tool such as python-distutils-extra19:24
dpm 19:24
dpmGettext: Translation domain19:24
dpmThe translation domain is a unique string identifier assigned by the programmer in the code (usually in the build system)19:25
dpmand used by the gettext functions to locate the message catalog where translations will be loaded from.19:25
dpmThe general form to compute the catalog’s location is:19:25
dpm    locale_dir/locale_code/LC_category/domain_name.mo19:26
dpmwhich in Ubuntu expand generally to /usr/share/locale/locale_code/LC_MESSAGES/domain_name.mo19:26
dpmThe locale_code part refers to the language code for the particular language. As an example, when using Nautilus in a Catalan locale with Ubuntu,19:26
dpmthe gettext functions will look for the message catalogue at:19:26
dpm    /usr/share/locale-langpack/ca/LC_MESSAGES/nautilus.mo19:26
dpmThat's where the translations for your application will be installed and searched for19:27
dpmNote that for your app this location might be slightly different:19:27
dpm     /usr/share/locale/ca/LC_MESSAGES/myapp.mo19:27
dpm* {i}The corresponding translation template should have the same translation domain in its filename, e.g. nautilus.pot.19:28
dpm* {i} The translation domain must be unique across all applications and packages. I.e. something generic like messages.pot won’t work.19:28
dpm 19:28
dpmOk, done with the concepts, let's get down to work and to questions19:29
dpmGeneric Steps to Internationalize an Application19:29
dpm* Integrate gettext into the application. Initialize gettext in your main function, most especially the translation domain19:29
dpm* Integrate gettext into the build system. There are generally gettext rules in the most common build systems. Use them.19:30
dpm* Mark translatable messages. Use the _() gettext call to mark all translatable messages in your application19:30
dpm* Care for your translation community. Not necessarily a step related to adding i18n support, but you'll want an active and healthy translation community around your project. Keep the templates with translatable messages up to date. Announce these updates and give translators time to do their work before a release. Be responsive to feedback.19:31
dpm 19:31
dpmHands-on: creating an internationalized app19:31
dpmOk, enough theory, let's have a go at using quickly to create your first internationalized application19:31
dpmYou can install Quickly on any recent Ubuntu release by simply firing up a terminal and executing:19:32
dpm    sudo apt-get install quickly19:32
dpmOnce you've done that, you can run quickly to create your first project:19:33
dpm    quickly create ubuntu-application awesometranslations19:34
dpm(if you like, substitute 'awesometranslations' by your favourite project name)19:34
dpmWe've just told Quickly to use the ubuntu-application template, and to call what is created "awesometranslations"19:34
dpmyou should probably have an open dialog from your new app in front of you.19:35
dpmQuickly has created all that for you!19:35
dpmYou can close the dialog to continue19:35
dpmWhat Quickly did was to copy over basically a sample application, and do some text switcheroos to customize the app19:35
dpmWhat you could see there was the ui containing some text that needs translation.19:36
dpmTo start making change to your app, go to the directory where it's stored. Generally by simply running19:36
dpm    cd awesometranslation19:36
dpmYou can then edit your code with $ quickly edit, change the UI with $ quickly glade, and try your changes with $ quickly run19:37
dpmYou can save your change with $ quickly save19:37
dpmFinally, to package, share, release your apps so that other will be, with the following commands (not all are necessary): $ quickly package / $ quickly share / $ quickly release19:37
dpmAs it stands now, the application has nearly all you need to make it translatable19:37
dpmwhich is the great thing about quickly19:38
dpmFrom now on, while I'll let you play and investigate the application you've created, we'll be looking at the one I created for the purpose of this session19:38
dpmand I'll show you the i18n bits19:39
dpmso that you can add them to your existing applications if you want19:39
dpmFor new applications, I'd simply recommend you to use quickly19:39
dpmand start from there19:39
dpmwhich will set up everything for you, so that you can forget about it and concentrate on all those new cool functions your new app is going to provide :-)19:40
dpmSo let's have a look at:19:40
dpmNotice that we could just call the session finished at this point, as quickly did all the job for us :)19:41
dpmAlso notice how easy it is. I've just created and pushed the application to Launchpad a few minutes ago19:41
dpmRemember we were talking about PO and POT files?19:42
dpmThey are right there, under the po/ folder:19:42
dpmthe po/ folder could be called something else, but it is customary to call it like that, as some tools rely on this convention19:43
dpmNotice the .pot file called the same name as your app19:43
dpmand an example translation file (ca.po) submitted by a translator19:43
dpmNow to the interesting bits:19:44
dpmRemember the generic steps for internationalization we were talking about earlier on?19:44
dpm* Initializing gettext:19:44
dpmso here we include the gettext module19:45
dpmand we define a function called simply _()19:45
dpmAnd finally we define the translation domain19:45
dpmwhich will be the name of the .mo file installed in the system and the name of the .pot file19:46
dpm* Integrating gettext in the build system:19:47
dpmHere the integration happens automagically by using python-distutils-extra19:47
dpmC programs using autotools might need a more complex integration19:47
dpm* Mark translatable messages:19:48
dpmFor every message you want to expose for translation, you simply have to wrap it in the _() function, e.g. _("Translatable message here")19:49
dpmAnd that's basically it, really19:49
dpmeasy, isn't it?19:50
dpmok, so we're running out of time, let's see if there are questions!19:50
ClassBotThere are 10 minutes remaining in the current session.19:52
ClassBotbdfhjk asked: What is the best way to translate QT application? Gettext or QTLinquist?19:52
dpmbdfhjk asked: What is the best way to translate QT application? Gettext or QTLinquist?19:52
dpmTough question :)19:52
dpmBoth Gettext and QT Linguist are excellent i18n frameworks19:53
dpmWith similar functionality19:53
dpmBut I would personally use gettext19:53
dpmBecause it is framework-agnostic and used by the vast majority of Open Source projects19:54
dpmNot only that, but most online translation tools rely on gettext19:54
dpmKDE itself uses gettext, for example19:54
ClassBotbulldog98_konv asked: what’s the difference between GNOMEs and KDEs handling of translations in code?19:54
dpmNot much really19:55
dpmAs I said, both KDE and GNOME use gettext19:55
dpmThe majority of GNOME is written in C, and KDE in C++19:55
dpmI gather that in KDE they wrap Qt Linguist calls through kdelib to actually use gettext to load the actual translations19:56
ClassBotbdfhjk asked: Is Gettext working in windows?19:56
ClassBotThere are 5 minutes remaining in the current session.19:57
dpmYes, gettext works in any platform where glibc can run, including Windows19:57
dpmThere is still time to answer one last question if you've got one19:58
dpmOk, so I think I'll use the last minutes to thank everyone for their participation, and remind you that if you've got any questions on translations, feel free to ping me any time!19:59
dpmI usually hang out on #ubuntu-devel19:59
dpmNow time for KDE/Kubuntu rockstar apachelogger, whol'll tell you about the secret art of writing plasma widgets20:00
apacheloggerthank you dpm :)20:00
dpmthe floor is yours!20:01
apacheloggersalut, bonjour and welcome to an introduction to Widgetcraft oh my :)20:01
apachelogger...also known as the art of creating Plasma Widgets.20:01
apacheloggermy name is Harald Sitter and I am developer of KDEish things20:01
apacheloggerfor this session you will need a couple of packages and any handy editor you like20:02
=== 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: Widgetcraft: The Art of Creating Plasma Widgets - Instructors: apachelogger
apacheloggersudo apt-get install kdebase-workspace-bin kdebase-runtime plasma-dataengines-workspace20:02
ClassBotLogs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html following the conclusion of the session.20:02
apacheloggerthis comand will make sure you get the packages necessary20:02
apacheloggerif the editor can do syntax highlighting for javascript it would be good :)20:02
apacheloggermeanwhile I am going to talk a bit about the technology we are going to work with20:02
apacheloggerplasma is the technology most people refer to as "the KDE desktop"20:03
apacheloggeror "the KDE workspace" if you will20:03
apacheloggerPlasma is just about everything you see when you log into a newly installed KDE system (such as Kubuntu ;))20:03
apacheloggerit is the wallpaper, and the panel at the bottom, and every icon and element within that panel and so on20:04
apacheloggerit comes in many amazing favors and creating new ones is not all that difficult20:04
apacheloggerby favors I mean specific versions of plasma for different form factors (i.e. devices)20:04
apacheloggercurrently there are plasma versions for desktop system, netbook systems, mobile devices (such as phones) and even tablets20:05
apacheloggeralthough the latter 2 are actually more like tech previews and not terribly usable at this time20:05
apacheloggerplasma widgets are widgets for plasma (surprise ;))20:06
apacheloggerthey are also called plasmoids... in particular plasma widget usually means a widget that can run in plasma20:06
apacheloggerthis includes apple dashboard widgets, google gadgets and native plasma widgets20:06
apacheloggerthose native widgets are the ones called plasmiods20:07
apacheloggerplamoids make best usage of plasma's abilities and can be writen in javascript (including qml in KDE 4.6+), c++, ruby and python20:08
apacheloggerhowever only javascript and c++ are builtin (thus always available)20:08
apacheloggerso, usually you want to use on of those20:08
apacheloggerpersonally I would even go as far as saying that javascript is the weapon of choice unless you have good reasons to choose anoter language20:09
apacheloggerthe reason for this is that javascript is of course easier to deploy (as it does not need compliation compared to c++) and is always available on every plasma system (unlike ruby and python)20:09
apacheloggerwe also use javscript in this session ;)20:10
apacheloggerplasmoids are distributed as so called "plasmagik packages" (what a name!)20:10
apacheloggerthey essentially contain one metadata file to describe the plasmoid at hand as well as code, images and other magic files20:11
apacheloggerfor more information have a look at http://community.kde.org/Plasma/Package20:11
apacheloggerQUESTION: can we use Qt/C++20:11
apacheloggeras explained, one can use C++, however there is no particular gain from this for the usual plasmoid20:12
apacheloggeras the javascript API iis very powerful20:12
apacheloggerIf there are no moar questions we can move on to hacking20:12
apacheloggera common step when creating a new plasmoid is setting up the folder structure, for this you can use this magic command sequence of mine:20:13
apacheloggerNAME=dont-blink                   # Set a shell variable20:13
apacheloggermkdir -p $NAME/contents/code/     # Create everything up to the code dir.20:13
apacheloggertouch $NAME/metadata.desktop      # Create the metadata file, which contains name and description...20:13
apacheloggertouch $NAME/contents/code/main.js # Create main code file of the plasmoid.20:13
apacheloggerthis will create a bare setup for a new plasmoid20:13
apacheloggerin the folder dont-blink20:13
apacheloggerQUESTION: can we create plasmoids in Ubuntu/Gnome and of course, test it on Kubuntu?20:14
apacheloggertesting can be done in gnome too20:14
apacheloggerhowever unfortunately at this point there is no actual widget integration, so the plasmoids will only work in KDE with Plasma20:14
apacheloggermovig on20:15
apacheloggerfirst we will need to setup our metadata file20:15
apacheloggeris a good starting point20:15
apacheloggerI believe the file is pretty easy to understand, it simply defines the general properties of our plasmoid20:15
apacheloggername, license, author, version etc.20:16
apacheloggerusually you will want to change at least Name and X-KDE-PluginInfo-Name20:16
apacheloggernow we can already get our hands dirty20:16
apacheloggerPleaes open the contents/code/main.js code file in your editor.20:17
apacheloggerlet's start with a semi-helloworld thing :)20:17
apachelogger    // First create a layout we can stuff things into20:17
apachelogger    layout = new LinearLayout(plasmoid);20:17
apacheloggerlayouts are very handy as we can put just about anything in there and they will automagically figure out how to align stuff20:18
apachelogger(well, almost automagically ;))20:18
apachelogger    // Then create a label to display our text20:18
apachelogger    label = new Label(plasmoid);20:18
apachelogger    // Add the label to the layout20:18
apachelogger    layout.addItem(label);20:18
apachelogger    // Set the text of our Label20:18
apachelogger    label.text = 'Don\'t Even Blink';20:18
apachelogger    // Done20:18
apacheloggernot terribly difficult, right? :)20:18
apacheloggeryou can now run this using plasmoidviewer . or plasmoidviewer PATHTOTHEPLASMOID (depending on where you are in a terminal right now).20:19
apacheloggerthis works on both KDE and GNOME20:19
apacheloggerand XFCE and ....20:19
apacheloggerplasmoidviewer is a very nice app to test plasmiods as you do not need to install the plasmoid to test it20:20
apacheloggerHere is a trick. If you have KDE 4.5 (default on Kubuntu 10.10) you will have a new command called 'plasma-windowed' using this command you can run most Plasmoids just like any other application in a window, is that not brilliant?20:20
apacheloggerfor example you can try that on our new plasmoid20:20
apacheloggeror if you have the facebook plasmoid installed, you can try it with that20:21
apacheloggervery handy to run plasmoids as sort-of real applications20:21
apacheloggerI hope everyone got our first code working by now20:21
apacheloggermaybe let us continue with a buttons20:22
apacheloggerbuttons are cool20:22
apacheloggeroh, in case you have not noticed, code lines are always indeted by 4 characters for your reading pleasure20:22
apachelogger    // Create a new button20:22
apachelogger    button = new PushButton;20:22
apachelogger    // Add the button to our layout20:22
apachelogger    layout.addItem(button);20:22
apachelogger    // Give the button some text20:22
apachelogger    button.text = 'Do not EVER click me';20:22
apacheloggerif you try the plasmoid now you will notice quite the sillyness20:23
apacheloggerthe layout placed the button next to the text20:23
apacheloggernot so awesome :(20:24
apacheloggerand apachelogger claimed layouts are awesome -.-20:24
apacheloggeroh well20:24
apacheloggereasily fixable20:24
apacheloggerthe problem is that the layout by default tries to place things next to each other rather than align them vertically20:24
apachelogger    // Switch our layout to vertical alignment20:24
apachelogger    layout.orientation = QtVertical;20:24
apacheloggernow this should look *much* better20:24
apacheloggerour button does not do anythign yet20:25
apacheloggerthat is a bit boring I might say ... and useless20:25
apacheloggerhwo about adding an image into the mix ? ;)20:26
apacheloggerQUESTION: why is it QtVertical? and not just Vertical like other widgets?20:26
apacheloggerQtVertical is actually coming from Qt and not from Plasma, as to avoid name clashes in the future I suppose it got prefixed with Qt ;)20:27
apacheloggergenerally speaking layout orientation in C++ Qt is also an enum in the Qt namespace, so it looks pretty much the same20:27
apacheloggerbut now for our image20:27
apacheloggerif you still have the same terminal you created the bare folder structure in you can use the following:20:28
apacheloggermkdir -p $NAME/contents/images/20:28
apacheloggerwget -O $NAME/contents/images/troll.png http://people.ubuntu.com/~apachelogger/uadw/04.11/dont-blink/contents/images/troll.png20:28
apacheloggerotherwise jsut navigate to your plasmoid folder, go to contents and create an images folder, then download http://people.ubuntu.com/~apachelogger/uadw/04.11/dont-blink/contents/images/troll.png into that folder20:28
apacheloggerNow for the code...20:29
apachelogger    // Labels can also contain images, so we will use a label again20:29
apachelogger    troll = new Label(plasmoid);20:29
apachelogger    // But this time we set an image. The image path is constructed automatically by us telling it in what directory it is and what name it has20:29
apachelogger    troll.image = plasmoid.file("images", "troll.png");20:29
apachelogger    // So that our image fits in we need to tell the label to consume as much space as possible and necessary20:29
apachelogger    troll.sizePolicy = QSizePolicy(QSizePolicyMaximum, QSizePolicyMaximum);20:29
apachelogger    // We only want to show the image after the user dared pressing the button, so we set it not visible and also do not add it to our layout20:29
apachelogger    troll.visible = false;20:29
apacheloggerthat will not actually do anything20:30
apacheloggeras the troll is set to invisible by default20:30
apacheloggerwe only show it once the user clicked on the button20:31
apacheloggerso this leads us to a very interesting part of Plasma in specific and Qt in particular20:32
apacheloggerconnecting a state change on one thing to an action20:32
apacheloggerusually in Qt we call this the signal and slot system20:32
apacheloggerin javascript plasmoids we have almost the same thing, in fact it is even simpler than in standard c++20:33
apacheloggerlet us try that20:33
apachelogger    // First add a function to handle clicking on the button20:33
apachelogger    function onClick()20:33
apachelogger    {20:33
apacheloggerwithin that function we put our logic for changing the visibility of our troll20:34
apachelogger        // Either the troll is shown or it is not...20:35
apachelogger        // If it is visible -> hide it20:35
apachelogger        if (troll.visible) {20:35
apacheloggerah, this is getting complicated20:35
apacheloggerlets stop here for a bit20:35
apacheloggerso, our troll can be visible and invisible and we change this via .visible and we read it via .visible20:35
apacheloggerthis might be a bit confusing for those of us who drive ourselfs crazy with C++ ;)20:36
apacheloggerhowever, it is really something very Qt20:37
apacheloggerQt adds property functionality to objects, which is really what we are seeing here20:37
apacheloggerour label has a property visibile20:37
apacheloggerand this property has a "setter" and a "getter"20:37
apacheloggerdepending on the context we can therefore use .visible as getter or setter20:38
apacheloggervery handy :D20:38
apachelogger(as we will have some QML sessions later this week ... this is also how QML elements work for the better part ;))20:38
apacheloggernow, moving on...20:38
apacheloggerwe were writing our onClick function, in particular the logic for when the troll is already visible20:39
apachelogger            // Make it invisible20:39
apachelogger            troll.visible = false;20:39
apachelogger            // And remove it from the layout, so that it does not take up space20:39
apachelogger            layout.removeItem(troll);20:39
apacheloggerI think changing the visibility should be clear now ... but that removing there is a bit confusing20:39
apacheloggerapachelogger apparently did not prepare very well :P20:39
apacheloggerso let me show you the rest of the onClick function and explain this afterwards20:40
apachelogger        } else { // If it is not visible -> show it20:40
apachelogger            // Once our button gets clicked we want to show an image.20:40
apachelogger            troll.visible = true;20:40
apachelogger            // Finally we add the new image to our layout, so it gets properly aligned20:40
apachelogger            layout.addItem(troll);20:40
apachelogger        }20:40
apachelogger    }20:40
apacheloggerso, depending on the state of visibility we simply do inverted actions20:40
apacheloggerpossibly you noticed earlier on that we did not add the troll to our layout20:40
apacheloggerthis was very intentional20:41
apacheloggeras soon as you add something to your layout it will usually consume space20:41
apacheloggervisible or not20:41
apacheloggerso, whenver our troll is not visible it also must not be part of the layout20:41
apacheloggerhence the logic in our onClick20:41
apacheloggerif visible -> make invisbile and remove from layout || if invisible -> make visible and add to layout20:42
apacheloggerthe daring programmer will now try this and complain that it is not working20:42
apacheloggeroh my20:42
apacheloggerwe did not yet define that onClick should do something upon button click20:43
apachelogger    // Now we just tell our button that once it was clicked it shall run our function20:43
apachelogger    button.clicked.connect(onClick);20:43
apacheloggerwell then20:44
apacheloggerfor me it works \o/20:44
apacheloggervery useful plasmoid we created there :D20:44
apacheloggeryou can find a version of this I created earlier here : http://people.ubuntu.com/~apachelogger/uadw/04.11/dont-blink/20:45
apacheloggerit also contains additional magic that should trigger a notification on click and display your location as detected by gps or ip lookup ;)20:46
apacheloggernow that we have a wonderful plasmoid we will need to package it properly20:46
apacheloggeras mentioned earlier, plasmoids are distributed in super cool special packages20:47
apacheloggeractually they are just zip files with .plasmoid as suffix20:47
apacheloggerso let us create such a nice package from our plasmoid20:47
apacheloggerif you are still in the same terminal we started off with, the following should do the job:20:48
apacheloggercd $NAME &&20:48
apacheloggerzip -r ../$NAME.plasmoid . &&20:48
apacheloggercd ..20:48
apachelogger$NAME is simply the name of our plasmoid, so you can easy enough create the zip manually too :)20:48
apacheloggerplease note that plasma does expect the contents and metadata to be in the top level of the zip though, so you must not package the plasmoid directory (in our case dont-blink) but only the files20:49
apacheloggerthat is really what that fancy zip command there does20:49
apacheloggerOnce you have your plasmoid you can install it using the regular graphical ways on your plasma version or by using the command line tool plasmapkg.20:50
apacheloggerplasmapkg -i $NAME.plasmoid20:50
apacheloggernow the plasmoid should show up in your widget listing.20:50
apacheloggerconsequently you should be able to use plasmoidviewer $NAME and plasma-windowed $NAME to view the plasmoid without plasma20:50
apacheloggerQUESTION: are there any particular style guidelines for writing code for plasmoids beyond what you have shown us? for those that are used to MVC kinda stuff20:51
apacheloggernot really20:51
apacheloggerif you are using C++ you can do just about anything ... in the future the javascript plasmoids will use QML quite a bit (you will hear about QML later this week)20:51
ClassBotThere are 10 minutes remaining in the current session.20:52
apacheloggerQML usually wants people to use Qt's Model/View system (which is pretty close to MVC)20:52
apacheloggerespecially if you are working with lists of course :)20:52
apacheloggerQUESTION: will it be possible to compress the package with bzip2 in the futur?20:52
apacheloggernot planned in particular, but if you ask in #plasma I am sure someone could tell you whether that would be desirable20:53
apacheloggeras plasmoids are usually atomic it does not make much a difference though20:53
apacheloggerany other questions?20:53
apacheloggerif not, then let me give you some additonal resources where you can find handy super nice things :)20:54
apacheloggerWhere the Plasma community collects its information: http://community.kde.org/Plasma20:54
apacheloggerGeneral tutorials on JavaScript Plasmoids: http://techbase.kde.org/Development/Tutorials/Plasma#Plasma_Programming_with_JavaScript20:54
apacheloggerPlasma and KDE development examples: http://quickgit.kde.org/?p=kdeexamples.git&a=summary20:54
apacheloggerSome general guidelines for Plasmoid programming: http://community.kde.org/Plasma/PlasmoidGuidelines20:54
apacheloggerInformation on Plasma packages: http://community.kde.org/Plasma/Package20:55
apacheloggerlast, but not least20:55
apachelogger*super important*20:55
apacheloggerthe JavaScript API: http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API20:55
apacheloggerif you compare this API to what you can do in C++ you will notice that the JavaScript API is really sufficient for most things :)20:55
apacheloggerOn IRC you can get help in #plasma most of the time20:56
apacheloggerGood luck with creating your brilliant Plasmoids :)20:56
apacheloggeryou can find me in just about every KDE and Kubuntu IRC channel after the sessions if you have any additional questions20:56
ClassBotThere are 5 minutes remaining in the current session.20:57
apacheloggerif you are interested in KDE software development I'd like to direct your attention to the KDE development session tomorrow, the various QML sessions and my talk on multimedia in Qt and KDE on friday :)20:58
apacheloggerthanks everyone for joining and have a nice day20:58
barrywelcome to "rock solid python development with unittest/doctest".  today i'm going to give a brief introduction to unit- and doc- testing your python applications, and hooking these into the debian packaging infrastructure.21:01
barryraise your hand if you're already unashamedly obsessed with testing :)21:01
=== 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: Rock solid Python development with unittest/doctest - Instructors: barry
barrysince it would take way more than one hour, i'm not going to give a deep background on testing, or the python testing culture, or python testing tools.  there are a ton of references out there.  two resources i'll give right up front are the testing-in-python mailing list <http://tinyurl.com/2bl2gk> and the python testing tools taxonomy <http://tinyurl.com/msya4>.  python has a *very* rich testing culture, and i encourage you to explore21:02
ClassBotLogs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html following the conclusion of the session.21:02
barrysorry, i'm going to start over because of the classbot delay...21:03
barrywelcome to "rock solid python development with unittest/doctest".  today i'm going to give a brief introduction to unit- and doc- testing your python applications, and hooking these into the debian packaging infrastructure.21:03
barryraise your hand if you're already unashamedly obsessed with testing :)21:03
barrysince it would take way more than one hour, i'm not going to give a deep background on testing, or the python testing culture, or python testing tools.  there are a ton of references out there.  two resources i'll give right up front are the testing-in-python mailing list <http://tinyurl.com/2bl2gk> and the python testing tools taxonomy <http://tinyurl.com/msya4>.  python has a *very* rich testing culture, and i encourage you to explore21:03
barrythere's a lot you can do right out of the box, and that's where we'll start.  michael foord is hopefully here today too; he's the author of unittest2, a standalone version of all the wizzy new unittest stuff in python2.721:03
barryfor now, we'll keep things pretty simple, and the examples should run in python2.6 or python2.7 with nothing extra needed.21:03
barryfor those of you with bazaar, the example branch can be downloaded with this command: bzr branch lp:~barry/+junk/adw21:03
barryif you can't check out the branch, you can view it online here:21:04
barryi'll pause for a few moments so that you can grab the branch or open up your browser21:04
barryhere's a quick overview of what we'll be looking at: a quick intro to unittesting, a quick intro to doctesting, hooking them together in a setup.py, hooking them into your debian packaging.21:05
barrylet's first look at a simple unittest.  if you've downloaded the branch referenced above, you should open the file adw/tests/test_adding.py in your editor.21:06
barrythe adw package is really stupid.  it has one function which adds two integers together and returns the results.  i won't talk much about test driven development (tdd) here, but i highly encourage you to read up on that and to practice tdd diligently!  these tests were developed using tdd.21:06
barryanyway, looking at test_adding.py, you can see one test class, called TestAdding.  there are some other boilerplate stuff in test_adding.py that you can mostly ignore.  the TestAdding class has one method, test_add_two_numbers().  this method is a unittest.  you'll notice that it calls the add_two_numbers() function (called the "system under test" or sut), and asserts that the return value is equal to 20.  pretty simple.21:07
barrylook below that at the test_suite() function.  this is mostly boilerplate used to get your unittest to run.  the function creates a TestSuite object and adds the TestAdding class to it.  python's unittest infrastructure will automatically run all test_*() methods in the test classes in your suite.21:07
barrylet's run the tests.  type this at your shell prompt:21:08
barry$ python setup.py test21:08
barry(without the $ of course)21:08
barrythe first time you do this, your package will get built, then you'll see a little bit of verbose output you can ignore, and finally you'll see that two tests were run.  ignore the README.txt doctest for the moment.21:08
barryif you want to see what a failing test looks like, uncomment the test_add_two_numbers_FAIL() method and run `python setup.py test` again.  be sure to comment that back out afterward though! :)21:09
barryeverybody with me so far?  i'll pause for a few minutes to see if there are any questions up to now21:09
barryso, obviously the more complicated your library is, the more test methods, test classes, and test_*.py files you'll have.  i probably won't have time to talk about test coverage much, but there are excellent tools for reporting on how much of your code is covered by tests.  you obviously want to aim for 100% coverage.21:11
barryokay, let's switch gears and look at a doctest now.  go ahead and open adw/docs/README.txt21:11
barrydoctests are *testable documentation*.  the emphasis is on the documentation aspects of these files, and in fact there are excellent resources for turning doctests into actual documentation, e.g. http://packages.python.org/flufl.i18n/21:12
barrydoctests are written using restructured text, which is a very nice plain text human readable format.  the key thing for testing is to notice the last three lines of the file.  see the two lines that start with >>>21:12
barry(aside: sphinx is the tool to turn rest documention into html, pdf, etc.)21:12
barryand it's very well integrated with setup.py and the python package infrastructure21:13
barrythat's a python interpreter prompt, and doctests work by executing all the code in your file that start with the prompt.  any code that returns or prints some output is compared with text that follows the prompt.  if the text is equivalent, then the test passes, otherwise it fails.21:13
barryoh, i should mention.  "doctests" can mean one of two things.  you can actually have testable sections in your docstrings, or you can have separate file doctests.  by personal preference, i always use the latter21:14
barrybtw, the use of doctests is somewhat controversial in the python world.  i personally love them, others hate them, but i think everyone agrees they do not replace unittests, but i think they are an excellent complement.  anyway, if we have time at the end we can debate that :)21:16
barryin this example, add_two_numbers() is called with two integers, and it returns the sum.  if you were to type the very same code at the python interpreter, you'd get 12 returned too.  doctest knows this and compares the output21:17
barryrun `python setup.py test` again and look carefully at the output.  you'll see that the README.txt doctest was run and passed.  if you change that 12 to a 13, you'll see what a failure looks like (be sure to change it back afterward!)21:17
barryi'll pause for a few minutes to let folks catch up21:17
ClassBotRawChid asked: So doctest is one way to do uittesting in Python?21:18
barryRawChid: i'd say one way to do *testing*, which i'm personally a big fan of.  i love writing documentation first because it ensures that i can explain what i'm doing.  if i can't explain it, i probably don't understand it.  but for really thorough testing, you must add unittests.  e.g. you typically do not want to do corner case and error cases in doctests.21:19
=== JasonO_ is now known as JasonO
barryalthough the heretic in me says you should try :)21:20
barryunfortunately, python's unittest framework does not run doctests automatically.  if you look in the adw/tests directory, you'll see a file called test_documentation.py.  you don't need to study this much right now, and you are free to copy this into your own projects.  it's just a little boiler plate to hook up doctests with the rest of your test suite.  it looks for files inside docs/ directories that end in .txt or .rst (the reST21:20
barrystandard extension) and adds them to the test suite.  once you have test_documentation.py, you never need to touch it.  just add more .txt and .rst files to your docs directories, and it will work automatically.21:20
ClassBottronda asked: Is doctest somewhat similar to the BDD movement?21:21
barrytronda: probably related.  i don't know too much of the details but i think there are better tools for doing bdd in python21:21
barryvoidspace might know more about that21:21
barryeverybody with me so far?21:22
barrytime to switch gears a little.  how do you hook up your unittests and doctests to your setup.py file so that you also can run `python setup.py test`?  open up setup.py in your editor and we'll take a look21:22
barrynotice first that setup.py imports distribute_setup and then makes a function call.  you'll see the file distribute_setup.py in the branch's top level directory.  this means my package uses *distribute* which is the successor to setuptools.  i highly recommend it, but if you don't know what that is, you can just cargo cult this bit.21:23
barryanyway, the setup.py is fairly simple.  you'll just notice one thing in the second to last line.  it sets `test_suite` to `adw.tests`.  the value is a python package path and it references the directory adw/tests.  this is how you hook up your test suite to setup.py.  when you run `python setup.py test` it looks at this test_suite key, and runs all the files that look like test_*.py21:23
barryvoidspace mentions in #u-c-c that we're pretty sure this is a setuptools extension to the standard distutils setup.py.  so it'll probably work for either setuptools or distribute21:24
barrywe have two of those of course!  test_adding.py and test_documentation.py, and the testing infrastructure automatically finds these, and makes the appropriate calls to find what tests to run.  so that little test_suite='adw.tests' line is all you need to hook your tests into setup.py21:25
barryso far so good.  now let's look at how to hook your python test suite into your debian packaging so that your tests always run when your package is built.  if you're not into debian packaging you can ignore the next couple of minutes.21:25
barryopen up debian/rules in your editor.21:26
barryfirst thing to notice is that my package uses dh_python2, which is the new goodness replacing python-central and python-support.  i highly recommend it as it can make your debian packaging of python code really really easy.  you can see there's not much to my rules file.21:26
barryi won't go into dh_python2 much right now, but you can look at the debian wiki for more details http://wiki.debian.org/Python21:27
barryfor today's class, there are really three parts to take a look at.  the first is the PYTHON2 line.  what this does is ensure that your tests will be run against all supported versions of python (2.x) on your system, not just python2.6 or python2.7.  the commented out line for PYTHON3 will do something similar for python321:27
barry(e.g. line 3)21:27
barryremember that ubuntu 11.04 supports both python2.6 and 2.721:27
barryaside: it is possible to write your package for both python2 and python3, and to run all the tests into both.  we won't have time to talk about that today though.21:27
barryso the next thing to look at is the line that starts `test-python%`.  this is a wildcard rule that is used to run the setup.py test suite with every supported version of python2 on your system.  you'll notice the -vv which just increases the verbosity.21:27
barry(e.g. line 9)21:28
barryoverride_dh_auto_test line then expands the PYTHON2 variable to include all the supported versions of python2, and it runs the test-python% wildcard rule for each of these.  thus this hooks in the setup.py tests for all versions of python2.  the override is currently needed because dh_auto_test doesn't know about `python setup.py test` yet.21:28
barryi won't go into the specifics of packaging building right now, but i've done a build locally, and the results are available here: http://pastebin.ubuntu.com/592711/21:28
ClassBoteolo999 asked: I'm very comfortable with nosetests; is there a particular reason why you left it out from the session?21:28
barryscroll down to line 251 and you'll see the test suite getting run for python2.7.  scroll down to line 268 and you'll see it getting run for python2.6.  the nice thing about this is that if you get a failure in either test suite, your package build will also fail.  this is a great way to ensure really high quality (i.e. rock solid :) python applications in ubuntu.21:28
ClassBotjderose asked: I got the impression that setuptools wasn't well maintained lately, wasn't regarded as the way forward, esp with Python3 - is that true, WWBWD? :)21:29
barryeolo999: mostly just to keep things simple.  voidspace in #u-c-c says that the main advantage of nosetests is the test runner, so it you can basically use all the techniques here with nose21:30
barryi'm pretty sure that the future plans voidspace has for unittest2 include integrating nose more as a plugin than as a separate tool21:30
barrybtw, that's about all the canned stuff i have prepared, so i welcome questions from here on out21:31
barryjust ask them in #ubuntu-classroom-chat and we'll post the answers here21:31
barryjderose: i'd say that's correct, though setuptools does get occasional new releases.  distribute is the maintained successor to setuptools, but for python3 distutils2 will be the way forward21:32
barryi admit that it's all very confusing :)21:32
barrybut my recommendation would be: use distribute for python2 stuff, and for python3 stuff if you want the same code base to be compatible with 2.x and 3.x (i.e. via 2to3).  this is a great way to support both versions of python21:33
barryoh yes, distutils2 will be called 'packaging' in python 3.3 and it will come in the stdlib21:34
barryfrom #u-c-c:21:35
barry<voidspace> barry is correct, I have plans for unittest to become more21:35
barry            extensible (plugins) that should allow nose to become much simpler21:35
barry            and be implemented as plugins for unittest21:35
barry<voidspace> at the moment nose is convoluted and painful to maintain because21:35
barry            unittest itself is not easy to extend21:35
barry 21:35
barryalso lvh mentions trial, which is twisted's test runner.  for mailman3 i use zc.testing which is zope's test runner21:35
barryso yeah, there are lots of testing tools out there :)21:36
barry<jderose> QUESTION: so is it okay/encouraged to run your python tests in PPA21:37
barry          builds, say for daily recipes and whatnot?21:37
barryjderose: i don't recall a discussion about it one way or the other.  personally, i would enable tests for all package builds, just to ensure that what you deploy has not regressed.21:38
barryhowever, you do need to be careful that your test suite can *run* in a ppa environment21:38
barrythis may not always be the case.  some test suites require resources that are not available on the buildds.  those tests would obviously cause problems when your ppa were built21:39
barryin those cases, it may be best to have more than one "layer" of tests.  one that gives good coverage and high confidence against regressions, but requires no expensive or external resources.  and a full test suite you can run locally with whatever crazy stuff you need21:40
barrymocks might be a good answer to help with that21:40
barryqwebirc57920: ppa == personal package archive21:40
barryQUESTION: How do I know what resources are available on the21:41
barry             buildds?21:41
barryyeah, good question :)  ask on #launchpad or launchpad-dev, or just try it and see what fails ;)  there should be better documentation about that on help.l.net21:41
barry<jderose> QUESTION: so if `test` requires a lot more dependencies than21:42
barry          `install`, should we just put those all in Build-Depends?  when will21:42
barry          we get Test-Depends?  :)21:42
barryjderose: excellent question.  for now, i recommend build-depends21:42
barry<tronda> Question: In the Java space there's a lot of mocking21:43
barry         tools/libraries. Any need for that in Python - if so - which are the21:43
barry         recommended ones?21:43
barryvoidspace can tell you how many mock libraries are available in python!  answer is *lots*21:43
barrybtw, please note that there are tools (such as pkgme and stdeb) that can debianize your setup.py based python project.  they do a pretty good job, though i'm not sure they turn test-requires into build-depends.21:44
barry<jderose> QUESTION: you mentioned "layering" tests into light/heavy - what a21:45
barry          good way of doing that?21:45
barry 21:45
barryjderose: i think this depends on the test runner you use.  python's stdlib for example uses -u flag to specify additional resources to enable (e.g. largefile).  most test runners have some way of specifying a subset of all tests to run and what i would do is in your debian/rules file, file the right arguments to your test runner to run the tests you can or want to run21:47
barrynote that in my debian/rules file, i set it up to run 'python setup.py test -vv' but really, it can run any command with any set of options21:47
barry<chadadavis> QUESTION: to different doc tests share a common environment /21:47
barry             namespace? Can I make them explicitly separate / explicitly21:47
barry             shared?21:47
barry 21:47
barrychadadavis: all the doctests in a single file or docstring share the same namespace.  one of the criticisms of doctests is that it builds up state as it goes so it can sometimes be difficult if a test later in the file fails, to determine what earlier state caused the failure.21:48
barryi think that just means you have to be careful, and also, keep your doctests focussed21:48
barrynot too big21:49
barryyou really just have to understand when and where each tool (unittest or doctest) is appropriate21:49
barryvoidspace also points out that every line in a doctest gets executed, even if there are failures (though i *think* there's a fail to cause it to bail on the first failure)21:50
barryi'll just say that that can be an advantage or disadvantage depending on what you like and what you're trying to do :)21:50
barrylooks like we have a few minutes left.  are there any other questions?21:51
ClassBotThere are 10 minutes remaining in the current session.21:52
akgraner<jderose> QUESTION - what's the status of 3to2?  write Python3 is so wonderful, i'd rather go that way than 2to321:52
barryi'll just say again what an excellent resource the testing-in-python mailing list is.  i highly recommend you join!21:52
barryvoidspace answers this as well as i could:21:53
barry<voidspace> jderose: packaging (distutils2) is now using 3to2 rather than 2to321:53
barry<voidspace> jderose: so although I've not used it myself, it must be in a21:53
barry            pretty good state  [16:53]21:53
barry 21:53
barryi've also not used 3to2 myself21:53
barryfwiw, if you look at my test_documentation.py file, you'll see how you can do setups and teardowns for doctests21:54
barryit also does fun stuff like set __future__ flags for the doctest namespace21:54
barryvoidspace says in #u-c-c that sphinx has support for doctests through its doctest:: directive21:56
ClassBotThere are 5 minutes remaining in the current session.21:57
barrywell, time is almost up, so let me thank you all for attending!  i know there was a lot of material and i blew through it pretty fast21:57
barryin closing, i'll say that while we can all debate this or that detail of testing, there's no debate that testing is awesome and we all should do more of it!21:57
barrybig thanks to my colleague voidspace for helping out!21:58
ClassBotLogs for this session will be available at http://irclogs.ubuntu.com/2011/04/11/%23ubuntu-classroom.html22:02
=== 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 ||
=== A is now known as Guest36811
=== beni is now known as Guest18564

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!