[00:59] <Yulo> Hola, disculpen, alguien habla español?
[01:00] <Yulo> quiero saber si en español habrán charlas relacionadas al Ubuntu developer week
[01:04] <Yulo> Hola, disculpen, alguien habla español?
[01:04] <Yulo> quiero saber si en español habrán charlas relacionadas al Ubuntu developer week
[01:12] <rzanebr10> oi pessoal
[01:12] <rzanebr10> to aqui no Campus Party
[01:13] <rzanebr10> e vou ta participando do ubuntu-class
[01:14] <rzanebr10> já fiz todas configs. que se pede no site do ubuntu-sp
[01:14] <rzanebr10> espero que de certo...
[03:03] <ajua> creo que fue mala idea instalarme ubuntu 10.04
[03:05] <ajua> how to ubuntu 10.04 to 9.10 ???
[03:06] <nhaines> Necesita instalar Ubuntu 9.10 nuevo.
[03:10] <ajua> nos vemos luego ubunteros
[03:20] <mhall119> nhaines, hey
[03:30] <nhaines> mhall119: heya.  :)
[06:42] <AnAnt> Hello, can someone upload yesterday's sessions please ?
[06:43] <Severity1> yes please :)
[06:51] <AnAnt> oh silly me, it can be found on the irclogs site anyways !
[06:52] <AnAnt> Severity1: http://irclogs.ubuntu.com/2010/01/25/#ubuntu-classroom.html
[06:53] <Severity1> thanks AnAnt :D
[06:54] <Severity1> lol which one is it?
[06:55] <AnAnt> it is the whole log of yesterday
[06:55] <AnAnt> better than nothing
[06:55] <Severity1> oh
[06:55] <Severity1> kay i guess i'll just have to skim through them :D
[12:35] <ehlim> date -u
[12:45] <AlanBell> @now
[12:45] <AlanBell> date -u is something you can type into a command terminal running on your machine
[15:14] <dholbach> dpm, soren: just so you can talk in here later on :)
[15:14] <Omar87> Did the sessions start?
[15:15] <dpm> dholbach, ok, thanks!
[15:15] <dholbach> Omar87: not yet, 45 minutes
[15:19] <dholbach> (just added the link to ubuntu developer week)
[15:20] <cjohnston> Mornin all
[15:23] <soren> dholbach: ta
[15:23] <dholbach> de rien
[15:23] <didrocks> dholbach: thans :)
[15:23] <didrocks> thanks*
[15:59] <dholbach> HELLO EVERYBODY! WELCOME TO DAY 2 of UBUNTU DEVELOPER WEEK!
[15:59] <ttx> yay
[16:00] <dholbach> we'll kick off day two with a fantastic Frenchman, it's Thierry Carrez who will talk about Java libraries Packaging
[16:00] <dholbach> one organisational note:
[16:00] <dholbach> if you want to ask questions, please head to #ubuntu-classroom-chat - if you want to ask questions in any other language head into one of the irc channels listed at the bottom of https://wiki.ubuntu.com/UbuntuDeveloperWeek/
[16:00] <dholbach> THANKS
[16:00] <dholbach> and enjoy day 2!
[16:00] <ttx> Let's get started !
[16:00] <ttx> My name is Thierry Carrez, and I'm a member of the Ubuntu Server team.
[16:01] <ttx> This session will be about the packaging of Java libraries.
[16:01] <ttx> It assumes you already know the basics of Debian packaging and want to learn the specificities of Java library packaging.
[16:01] <ttx> We'll first see some basics about Java libraries and how they fit in Debian packaging
[16:01] <ttx> Then the java-specific issues we need to solve in our packaging work
[16:01] <ttx> Then we'll see the rules of java library packaging...
[16:02] <ttx> And we'll look at a few examples, in increasing order of complexity.
[16:02] <ttx> At the end of each section we'll do a quick Q&A...
[16:02] <ttx> Questions should be asked in #ubuntu-classroom-chat and will be relayed here.
[16:02] <ttx> OK, let's start !
[16:03] <ttx> == Java libraries basics ==
[16:03] <ttx> Java is an object-oriented language, so it makes use of object classes.
[16:03] <ttx> Those classes can be grouped inside class libraries, and shipped in a .jar file.
[16:03] <ttx> A JVM runs with a classpath that defines where classes can be found, and a classpath can point to JAR files.
[16:03] <ttx> Those JAR files are usually shipped together with the program that uses them.
[16:04] <ttx> But that results in code duplication, i.e. the same JAR file can be found in several packages.
[16:04] <ttx> That's bad, because bug fixes (and security fixes) cannot be applied once and for all.
[16:04] <ttx> In Linux distributions, we want to share the common code across applications, so we want to package Java libraries separately.
[16:04] <ttx> We follow a few rules, defined in Debian Java policy
[16:04] <ttx> http://www.debian.org/doc/packaging-manuals/java-policy/x105.html
[16:05] <ttx> Binary library packages are named libXXX-java. A fictional library called "hello" would be provided by a libhello-java package.
[16:05] <ttx> They install versioned JAR files in /usr/share/java (hello-1.0.jar) and a unversioned link should point to it
[16:05] <ttx> /usr/share/java/hello.jar -> /usr/share/java/hello-1.0.jar
[16:06] <ttx> Note that without installing a package and unzipping the JAR file, it can be difficult to tell exactly which classes it provides
[16:06] <ttx> So finding where a given class might be shipped would involve installing all the Java library packages and unzipping all the JARs that the distribution contains...
[16:06] <ttx> Fortunately I did that for you and published java-Contents.gz files that contain all classes in all jars in all packages !
[16:06] <ttx> https://wiki.ubuntu.com/JavaTeam/JavaContents
[16:07] <ttx> So finding a given class in karmic is just a matter of downloading the karmic-java-Contents.gz file...
[16:07] <ttx> and do a "zgrep the.class.name karmic-java-Contents.gz"
[16:07] <ttx> OK, questions so far ?
[16:08] <cjohnston> < LumpyCustard> *QN: how often is this file updated?
[16:08] <ttx> I usually release it after each release
[16:08] <ttx> but you can regenerate it at will
[16:09] <ttx> the code is provided in the page I linked to.
[16:09] <ttx> Takes several hours, btw :)
[16:09] <cjohnston> < mscahill> QUESTION: this contains all java classes contained in which repository? main? universe and main?
[16:09] <ttx> main universe, multiverse
[16:09] <cjohnston> < luckyduck> QUESTION: how are the classes/jars added to the classpath? is that done by the ubuntu java env. or the startup scripts of packages?
[16:09] <ttx> the component is listed on each line
[16:09] <ttx> so you can filter output to only main packages if you want
[16:10] <ttx> startup scripts and packages usually take care of setting up the classpath for a given app
[16:10] <ttx> luckyduck: ^
[16:11] <ttx> Let's move on :)
[16:11] <ttx> == Java-specific packaging issues ==
[16:11] <ttx> The main issue with Java packaging is that in Debian packaging we need to build everything from source...
[16:11] <ttx> while most Java programs just build from already-built libraries shipped directly with their source
[16:12] <ttx> So we need to first make sure all those build-time libraries are already properly packaged.
[16:12] <ttx> And we also often need to patch the build system so that it uses the shared libraries in /usr/share/java instead of what it is used to.
[16:12] <ttx> Another issue is that Java "compiling" (which really is bytecode generation) generally requires the presence of a lot of Java libraries
[16:13] <ttx> And not all of them are already packaged. A given library might need 5 missing libraries, which in turn would require 10 others...
[16:13] <ttx> So packaging a seemingly simple Java stack can quickly turn into an exponential packaging game.
[16:13] <ttx> The last issue is that we provide a shared library set, with given version numbers. However, the library APIs can change even in minor releases...
[16:14] <ttx> And since Java software usually conveniently ships with its own version of the library, it doesn't care so much about staying compatible with the latest version.
[16:14] <ttx> Software A can require libhello-java>=2.1.14, while library B won't compile with libhello-java>=2.1...
[16:14] <ttx> We usually patch one to be compatible with the others, but that can quickly become a complicated game.
[16:14] <ttx> Questions, before we really start packaging ?
[16:15] <cjohnston> < LumpyCustard> QUESTION: Does building with Maven make this difficult? <-- this can be answered later if you like!
[16:15] <ttx> LumpyCustard: yes, maven makes it even more difficult
[16:15] <ttx> LumpyCustard: we'll come back to that later, but maven actually helps software to pick a very specific JAR version
[16:16] <ttx> rather than encouraging the use of the latest
[16:17] <ttx> OK, let's start packaging.
[16:17] <ttx> == Packaging libraries ==
[16:17] <ttx> Here are a few debian/control rules that apply to Java libraries:
[16:17] <ttx> - Section should be "java"
[16:17] <ttx> - You should "Build-depends" on default-jdk
[16:18] <ttx> - The library binary package should "Depends" on default-jre-headless | javaN-runtime-headless
[16:18] <ttx> (replace N by the minimum level of Java needed)
[16:18] <ttx> Anticipating the question, how do I figure that out ? Looking at the level of the target Java code in the build system usually gives a clue:
[16:18] <ttx> target=1.6 means you should use "default-jre-headless | java6-runtime-headless" -- that's the default for code generated using default-jdk
[16:19] <ttx> target=1.5 -> "default-jre-headless | java5-runtime-headless"
[16:19] <ttx> target=1.4 -> "default-jre-headless | java2-runtime-headless"
[16:19] <ttx> When starting to package a library, you must investigate what build system it uses.
[16:20] <ttx> If there is a "build.xml" file, then it probably uses "ant", which is like a Java-oriented "make".
[16:20] <ttx> The Makefile is called build.xml and contains targets (in XML) that you can call with ant <target>.
[16:20] <ttx> Sometimes there is no build system.
[16:20] <ttx> Sometimes, it uses maven, which is a complex build/integration system that handles both build rules and dependency management
[16:21] <ttx> Next step is to look at build dependencies. It's not always obvious which libraries are required for compilation.
[16:21] <ttx> You can look into the README, look into the build.xml, see if any .jar files are shipped withing the source...
[16:21] <ttx> Otherwise just try to compile it, it will fail with ClassNotFound errors... and use java-Contents.gz to find where those classes live.
[16:22] <ttx> Questions, before we move on to practical examples ?
[16:23] <ttx> OK, moving on, then
[16:23] <ttx> == Example 1: Simple library ==
[16:23] <cjohnston> < LumpyCustard> QUESTION: Does building with Maven make this difficult? <-- this can be answered later if you like!
[16:23] <cjohnston> sorry
[16:24] <cjohnston> < mscahill> QUESTION: so you're referring to creating a deb of an existing application?
[16:24] <ttx> mscahill: creating a deb of a java library, to be more exact
[16:24] <ttx> mscahill: but applications aren't so different
[16:24] <ttx> mscahill: they just add a launcher, basically
[16:25] <cjohnston> < luckyduck> QUESTION: in gentoo it was very complicated to work with maven in ebuilds, since there was no automated way to pull in jars an app needed to compile (atleast during the time i was part of
[16:25] <cjohnston>                    gentoo java). how is that handled in ubuntu?
[16:25] <ttx> I'll come back to maven, but yes, it's a pain.
[16:25] <cjohnston> < dig> QUESTION: jar to deb?
[16:26] <ttx> dig: not sure I get the question, but yes, the idea is to make a deb that contains jars.
[16:26] <ttx> back to example 1
[16:27] <cjohnston> < dig> QUESTION:i meant if i make a jar which has all the deps in it, it can be made to a deb easily right?
[16:27] <ttx> dig: no. We want to rebuild the jar from source.
[16:27] <ttx> dig: all packages in Ubuntu must be built from source
[16:27] <ttx> making a deb from a JAr file would be "from binary"
[16:28] <ttx> ok, really moving on now :)
[16:28] <ttx> Suppose we want to package a library called "easy", that uses "ant" to build and has no build dependencies
[16:28] <ttx> It uses a build.xml, and simply running "ant" builds build/easy-1.0.jar
[16:28] <ttx> We'll use the CDBS "ant" class to do all the work for us.
[16:29] <ttx> The debian/control file would be like:
[16:29] <ttx> http://pastebin.ubuntu.com/362512/
[16:29] <ttx> And the debian/rules file is then as simple as:
[16:29] <ttx> http://pastebin.ubuntu.com/362514/
[16:29] <ttx> We include the ant CDBS class on line 3
[16:29] <ttx> JAVA_HOME on line 5 matches our "default-jdk" build-depend
[16:30] <ttx> Lines 8 to 10 take care of installing the JAR and the unversioned link to it.
[16:30] <ttx> Easy enough, if you already know a bit of debian packaging
[16:30] <ttx> The issue is, I couldn't find a single library as simple as that one. Let's look into real world examples now :)
[16:30] <ttx> This is the debian/rules file for "trove":
[16:30] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/trove/lucid/annotate/head%3A/debian/rules
[16:31] <ttx> It's mostly identical to our easy one, except we had to specify a DEB_ANT_BUILD_TARGET, since just calling "ant" without argument wouldn't build anything
[16:31] <ttx> It also builds the Java documentation, so there are special rules to take care of the produced javadoc.
[16:31] <ttx> Questions !
 QUESTION does it just use javadoc?
[16:33] <ttx> well, it uses ant, which calls javadoc
[16:33] <ttx> see DEB_ANT_BUILD_TARGET := jar javadoc
[16:33] <ttx> that means it will call "ant jar javadoc"
[16:33] <ttx> if you look into the build.xml you'll find a "javadoc" target
[16:34] <ttx> that does ant magic to build the doc, by calling javadoc
[16:34] <ttx> we are just calling ant here.
[16:34] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/trove/lucid/annotate/head%3A/build.xml#L167
[16:35] <ttx> ^that's where the build.xml file specifies it. But that is part of upstream distribution, not written by us
[16:35] <ttx> OK, complexity level 2 now...
[16:36] <ttx> == Example 2: Build dependencies ==
[16:36] <ttx> When you have build dependencies, you'll need to add the required libraries to the build classpath.
[16:36] <ttx> The CDBS ant class has a nifty mechanism for that, just add the required JAR names on a DEB_JARS line.
[16:36] <ttx> You can put JAR names (without path or extension, it will look in /usr/share/java) or complete paths.
[16:37] <ttx> See that example with the "jug" library:
[16:37] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/jug/lucid/annotate/head%3A/debian/rules
[16:37] <ttx> line 11
[16:37] <ttx> Also note that DEB_ANT_CHECK_TARGET lets you specify a build.xml target to be called for post-compilation tests.
[16:38] <ttx> The other thing you might need to do at that point is to patch the build.xml file to make it use the system classpath instead of a build.xml-specific one.
[16:38] <ttx> See line 16 of the build.xml patch needed for jug:
[16:38] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/jug/lucid/annotate/head%3A/debian/patches/build-xml.diff
[16:39] <ttx> Quick tip, you can also pass "DEB_ANT_ARGS := -Dbuild.sysclasspath=last", that will make sure the system classpath is appended to any build.xml local classpath.
[16:39] <ttx> Questions ?
[16:39] <ttx> I don't know if this is too easy or too complex :)
[16:41] <ttx> ok, let's move on
 QUESTION: I am completely new to this kind of stuff, but I sill want to learn. So, is this some kind of a markup language or something?
[16:42] <ttx> Omar87: depend on what you mean by "stuff". Is is the debian/control or the build.xml that looks like stuff to you ?
[16:42] <ttx> It's impossible to cover both debian packaging *and* java libraries packaging in a single hour, sorry :)
[16:43] <ttx> On to complexity level 3 !
[16:43] <ttx> == Example 3: Write a build.xml ==
[16:43] <ttx> Sometimes there will be no build.xml, or the provided build.xml will be so funny rewriting it is better than trying to use it.
[16:43] <ttx> Then you should provide your own debian/build.xml and point the CDBS ant class to it.
[16:43] <ttx> See that minimal debian/build.xml example for "mvel":
[16:44] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mvel/lucid/annotate/head%3A/debian/build.xml
[16:44] <ttx> just takes classes, compiles them and makes a jar out of them
[16:44] <ttx> And here is the rules file that makes use of it (see DEB_ANT_BUILDFILE at line 10):
[16:44] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mvel/lucid/annotate/head%3A/debian/rules
[16:44] <ttx> Also note the passing of parameters to the build.xml file, using DEB_ANT_ARGS on lines 11-12.
[16:45] <ttx> Questions on this example ?
[16:46]  * ttx lets some time for students to catch up
[16:46] <ttx> Time for level 4, I guess
[16:47] <ttx> == Example 4: Shipping POM / maven-repo-helper ==
[16:47] <ttx> That's starting to be interesting to LumpyCustard
[16:47] <ttx> Like I already said, maven is a build/integration system that handles both build rules and dependency management
[16:47] <ttx> It relies on a specific repository layout and dependency description files called .pom files.
[16:48] <ttx> Usually it just downloads dependencies from the Internet directly
[16:48] <ttx> We want it to use the system-installed libraries and not use internet for anything
[16:48] <ttx> because we want reproduceable builds, not depending on the state of internet at any given time
[16:49] <ttx> In order to support building packages using maven, we need to start shipping our libraries in a maven-compatible form.
[16:49] <ttx> Debian Java developers worked on a spec, it requires installing JARs and POM files in /usr/share/maven-repo
[16:49] <ttx> To ease that they created a maven-repo-helper package that provides convenient helpers:
[16:50] <ttx> mh_installjar will install a JAR in /usr/share/java and create all the necessary links, including the classic unversioned one
[16:50] <ttx> mh_installpoms will install POM files
[16:50] <ttx> See this debian/rules example for commons-beanutils, in particular lines 15-16:
[16:50] <ttx> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/commons-beanutils/lucid/annotate/head%3A/debian/rules
[16:51] <ttx> (this library isn't using maven to build, it's just installing itself in a maven-friendly way)
[16:51] <ttx> Those maven-friendly libraries allow "maven" to make use of the system installed libraries
[16:52] <ttx> Questions ?
[16:52] <ttx> that was the last example, we'll move now to more general Q&A about any subject you want...
[16:52] <Pendulum> < luckyduck> QUESTION: what is installed by the mh_installjar tools?
[16:52] <ttx> I'll talk a little about packaging stuff that uses maven, for LumpyCustard
[16:53] <ttx> mh_installjar makes sure that the jar is installed at the right place with links. For example:
[16:54] <ttx> easy.jar 1.0 gets installed in /usr/share/java/easy-1.0.jar
[16:54] <ttx> + the following symlinks:
[16:54] <ttx> /usr/share/java/easy.jar -> /usr/share/java/easy-1.0.jar
[16:54] <Pendulum> < luckyduck> QUESTION: a link from an debian/ubuntu package?
[16:54] <ttx> /usr/share/maven-repo/com/easycorp/easy/easy-1.0.jar -> /usr/share/java/easy-1.0.jar
[16:54] <ttx> /usr/share/maven-repo/com/easycorp/easy/easy-debian.jar -> /usr/share/java/easy-1.0.jar
[16:55] <ttx> yes, the jar and the links get installed by dpkg when installing the libeasy-java package
[16:55] <Pendulum> < SevenMachines> [QUESTION] I've seen packages that carry the actual source files inside a jar, is there any reasonable way to use patches in the packaging in that sort of case?
[16:56] <ttx> SevenMachines: the source should be repackaged as an orig.tar.gz
[16:56] <ttx> About maven, having more and more libraries maven-compatible finally allows to use maven in debian packaging
[16:56] <Pendulum> < LumpyCustard> QUESTION: Would there need to be a new <repository> in the application pom to use the jars already found on the system?
[16:57] <ttx> http://wiki.debian.org/Java/MavenBuilder
[16:57] <ttx> LumpyCustard: that's a good question
[16:58] <ttx> LumpyCustard: I'm far from being a maven expert. All I can say is that pom files are patched at install
[16:58] <ttx> and our maven is also patched to use /usr/share/maven-repo
[16:59] <ttx> The MavenBuilder link above points to the work in Debian to further support maven
[16:59] <ttx> it's still very much work in progress, since maven is so distribution-unfriendly (it's basically another packaging system)
[16:59] <ttx> ok, time is up
[17:00] <ttx> thanks everyone !
[17:00] <ttx> next up is...
[17:00] <aquarius> me. :-)
[17:00] <ttx> "Adding Ubuntu One support to your applications" :)
[17:01] <ttx> Led by the incredible Stuart Langridge
[17:01] <aquarius> [SLIDE 1]
[17:02] <aquarius> hm, that didn't work, that's kees's talk. never mind :)
[17:02] <aquarius> Hi! I'm Stuart Langridge, from the Ubuntu One team, and this talk is called "Adding Ubuntu One support to your applications".
[17:02] <aquarius> You can ask questions at any time in #ubuntu-classroom-chat. Please write QUESTION at the beginning of your question so I can see it more easily. I'll stop at the end of a section and answer some questions.
[17:02] <aquarius> During this talk I'm going to explain the different ways your applications can take advantage of Ubuntu One...
[17:03] <aquarius> ...talk about why you'd want to do that...
[17:03] <aquarius> ...and give a couple of sneak previews of things that you can't *quite* do yet but will be able to do for Lucid 10.04, so you can be ready!
[17:03] <aquarius> Firstly, though, remember that "integrating with Ubuntu One" isn't really the point; the point is to give features to your users that make their lives easier.
[17:03] <aquarius> Now, obviously, using Ubuntu One will make you taller, it'll make you more attractive to the appropriate sex, and it'll make the sun shine more brightly, but remember that it's all about providing things that your users want...
[17:04] <aquarius> ...and Ubuntu One gives you the infrastructure you need to do that. If it doesn't, come talk to us!
[17:04] <aquarius> OK, so, the first thing is: files.
[17:04] <aquarius> As you know, Ubuntu One automatically synchronises files in your Ubuntu One folder to Ubuntu One itself in the cloud and to all your other machines.
[17:04] <aquarius> This means that you can take advantage of automatic file backup just by having your application save things to the filesystem!
[17:05] <aquarius> Imagine that you want attachments that you receive by email to be stored online and backed up so you can get at them later.
[17:05] <aquarius> [SLIDE 2]
[17:05] <aquarius> (bah. ignore the slides. they're not my slides)
[17:05] <aquarius> Most mail clients will already let you do this in some way. So, change the folder that these attachments are saved in to be an Ubuntu One folder and suddenly all your attachments are backed up online and available on every machine!
[17:06] <aquarius> For example, there is a Thunderbird attachment called "Attachment Extractor" (https://addons.mozilla.org/en-US/thunderbird/addon/556)
[17:06] <aquarius> Install it, select "Automatically extract attachments on email receipt" in Tools > AttachmentExtractor settings > Auto-Extract, and set the "Save Path for Attachments" to /home/YOU/Ubuntu One/Mail Attachments, and that's all you need!
[17:07] <aquarius> Similarly, if you want off-site backups of your computer, then you can install one of the many simple backup programs, like backintime (http://backintime.le-web.org/) and choose the backup folder to be inside your Ubuntu One folder.
[17:07] <aquarius> With no extra effort you've got off-site online backups which you can get at from any of your machines or from the web.
[17:07] <aquarius> As another example, imagine you've built yourself a digital picture frame out of an old laptop, which is a pretty cool project for your weekends. How do you get the photos on it?
[17:08] <aquarius> [SLIDE 3]
[17:08] <aquarius> Well, when I did this, I created a new Ubuntu One user for the picture frame, and then I shared a folder with that picture frame user through Ubuntu One.
[17:08] <aquarius> The picture frame just did this: eog --slideshow "/home/pictureframe/Ubuntu One/Shared With Me/pictures from Stuart Langridge"
[17:09] <aquarius> and then to add new pictures to the frame, I just copy them into the folder that I shared.
[17:09] <aquarius> I could share that folder with anyone else, too, and allow them to write to it, and then they'd be able to add pictures to the frame too!
[17:11] <aquarius> The way I'll do this from 10.04 Lucid onwards is to use the new User Defined Folders feature, where any folder, anywhere, can be designated as an Ubuntu One synced folder
[17:11] <aquarius> and you can elect to have some folders but not others synced to particular machines
[17:11] <aquarius> So I'd create my "digital picture frame" folder in my home folder (or wherever), and then mark it as a UDF.
[17:11] <aquarius> Then on the picture frame itself, I'd sign into Ubuntu One, and say that I only want to subscribe to that particular UDF and not any of the others.
[17:12] <aquarius> so then files that I put into "digital picture frame" on my laptop will be synced to the picture frame
[17:12] <aquarius> and the picture frame just displays all the files in that folder
[17:12] <aquarius> ta daaah, it Just Works.
[17:12] <Pendulum> QUESTION: Is there a full GObject U1 API for storing data, settings etc. or do we have to make use of ~/Ubuntu One/ for now?
[17:13] <aquarius> A much-requested feature which will be available in Lucid is "public files", the ability to publish an Ubuntu One-synchronised file to a public URL so anyone can get at it.
[17:14] <aquarius> This is useful for the user directly; they can easily make a file available to the world.
[17:14] <aquarius> It's also really useful for applications, because you can now build one-click publish-to-the-world directly into your apps.
[17:14] <aquarius> Imagine that your app is Shutter, which is like the standard Gnome Screenshot tool on steroids.
[17:14] <aquarius> If you install Shutter and then hit the Print Screen button, it'll take a picture of your screen.
[17:15] <aquarius> One of the main reasons people take screenshots of their screen is to show them to other people, which makes this a perfect case for publishing the screenshot to a URL so anyone can see it.
[17:15] <aquarius> So, in Shutter (or your similar app), provide a "Publish with Ubuntu One" button.
[17:15] <aquarius> [SLIDE 4]
[17:15] <aquarius> That button should do the following:
[17:15] <aquarius> 1. Save the file into the user's Ubuntu One folder (just save, as normal)
[17:15] <aquarius> 2. Call the publishing API
[17:15] <aquarius> The publishing API will be D-Bus; I can't confirm exactly how it will work, yet, because the team are still constructing it, but keep your eyes open for more details!
[17:15] <aquarius> This shows a basic principle of Ubuntu One's design; pretty much anything you can do explicitly, like publish a file, or share a file, can also be done using the D-Bus API from applications.
[17:16] <aquarius> I'll answer some questions here about using Ubuntu One file sync in your apps.
[17:16] <aquarius> kklimonda|lernid> QUESTION: Is there a full GObject U1 API for storing data, settings etc. or do we have to make use of ~/Ubuntu One/ for now?
[17:17] <aquarius> Data and settings are best stored in desktopcouch if you want to take advantage of all that lovely synchronization goodness; there are benefits to doing it that way, and I'll talk about desktopcouch in a bit.
[17:17] <aquarius> But you can certainly store settings files in ~/Ubuntu One if you want to
[17:17] <aquarius> and obviously actual data *content* that your apps work on, your documents and so on, are stored in ~/Ubuntu One
[17:18] <aquarius> mhall119|work> QUESTION: in 10.04 you will be allowed to have multiple sync folders outside of ~/Ubuntu One/ ?
[17:18] <aquarius> mhall119|work, yep, you sure will. UDFs (user defined folders) are a big feature that'll land in 10.04.
[17:18] <aquarius> strycore89> QUESTION : will we be able to share single files and not whole directories ?
[17:19] <aquarius> No. Sharing is done folder-by-folder, and we're not planning on changing that.
[17:19] <aquarius> mhall119|work> QUESTION: right now the local folder names match the online folder names.  With the ability to have multiple sync folders, how are naming conflicts resolved?
[17:19] <aquarius> I'm not sure what you mean here by "naming conflicts"; maybe we can pick that point up after the session, or later on?
[17:19] <aquarius> foobob> QUESTION: are you thinking of giving some GB more to the free plan?
[17:20] <aquarius> I don't believe we are at the moment, no.
[17:20] <aquarius> yltsrc> QUESTION: will be ready symlincs in U1?
[17:21] <aquarius> yltsrc, UDFs, being able to mark any folder as Ubuntu One synchronized, takes the place of symlinks. If you use, er, some alternative to Ubuntu One and you're used to putting a symlink in, say, ~/SyncedFolder which points at ~/SomeOtherFolder to get SomeOtherFolder synced, you don't need to do that in Ubuntu One; you just mark SomeOtherFolder as a UDF and it will be synced for you.
[17:22] <aquarius> lantash49> QUESTION: Will there be more detailed specification w.r.t storing settings in ~/Ubuntu\ One? Storing them there directly seems to conflict with the XDG directory specs.
[17:22] <aquarius> lantash49, one obvious approach to this is to mark XDG_CONFIG_DIR and XDG_DATA_DIR as UDFs, so they're synchronized across your computers.
[17:23] <aquarius> yltsrc> QUESTION: i want participate in testing U1, how can I do it?
[17:23] <aquarius> Drop into #ubuntuone and talk to the team about what's going on and how you can help; we've had some really helpful community members already, like rtgz, who's done tons of stuff
[17:23] <aquarius> taj> QUESTION: Are there any plans to make U1 cross-platform?
[17:24] <aquarius> There's a sprint at PyCon US to port Ubuntu One file sharing to Windows: http://us.pycon.org/2010/sprints/projects/ubuntuone/
[17:24] <aquarius> and mandel, another incredible community member, is currently porting desktopcouch to Windows: http://www.themacaque.com/?p=372
[17:25] <aquarius> both of those projects are great, and if you can help that'd be wonderful
[17:25] <aquarius> mhall119|work> QUESTION: If I put a symlink inside of a UDF, that points elsewhere, does U1 sync that as a link, or as a copy of what is linked to?
[17:25] <aquarius> it's synced as a symlink.
[17:26] <aquarius> right, let's carry on :)
[17:26] <aquarius> The second leg of Ubuntu One for developers is desktopcouch, the CouchDB on your desktop.
[17:26] <aquarius> If you missed my last Ubuntu Developer Week talk about the basics of desktopcouch and what it's for, you can read it at http://www.kryogenix.org/days/2009/09/03/desktop-couch-irc-talk
[17:26] <aquarius> In fact, you can read all the desktopcouch documentation at http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/, and you should do so :-)
[17:27] <aquarius> The bit that's most likely to be relevant here is the "I am a developer, and I want the applications I write to store data in and work with desktopcouch" section. It contains much that is relevant to this talk!
[17:27] <aquarius> http://arstechnica.com/open-source/guides/2009/12/code-tutorial-make-your-application-sync-with-ubuntu-one.ars/1 is a really great guide, written by segphault, of how to support cloud synchronization of data in your applications.
[17:27] <aquarius> Essentially, if you use desktopcouch to store your application's data, instead of using sqlite or flat files, then the data will be synchronised between all your machines *without you having to do anything*.
[17:27] <aquarius> [SLIDE 5]
[17:28] <aquarius> So your app will work the same on all your machines with no effort.
[17:28] <aquarius> To store a record in desktopcouch, simply do:
[17:28] <aquarius> >>> from desktopcouch.records.server import CouchDatabase
[17:28] <aquarius> >>> from desktopcouch.records.record import Record
[17:28] <aquarius> >>> db = CouchDatabase('testing', create=True)
[17:28] <aquarius> >>> r = Record({'key':'value'}, record_type='http://example.com/testrecord')
[17:28] <aquarius> >>> record_id = db.put_record(r)
[17:28] <aquarius> and to get it back, by record ID:
[17:28] <aquarius> >>> fetched = db.get_record(record_id)
[17:28] <aquarius> >>> print fetched['key']
[17:28] <aquarius> 'value'
[17:28] <aquarius> The Quickly project, for writing Ubuntu apps, have created "widgets" that use desktopcouch without you having to think about it. CouchGrid, for example:
[17:29] <aquarius> >>> from desktopcouch.records.couchgrid import CouchGrid
[17:29] <aquarius> >>> keys=["key","another key"] # to label the columns
[17:29] <aquarius> >>> couchgrid = CouchGrid(db_name, record_type=record_type, keys=keys)
[17:29] <aquarius> >>> mywindow.pack_start(couchgrid)
[17:29] <aquarius> and then you have a CouchGrid, which is a data table where all the data is automatically retrieved from desktopcouch and stored back into desktopcouch when changed
[17:30] <aquarius> http://www.youtube.com/user/calorielookup#p/a/u/0/Vwr5Xw5ZrIE has a video demonstrating couchgrids
[17:30] <aquarius> You don't have to know anything about desktopcouch at all for this! Just use the widget and your data will be saved to the database and synced to your different machines with no effort or code on your part at all.
[17:31] <aquarius> https://wiki.ubuntu.com/Quickly/Snippets has a few more examples of using desktopcouch from Python and from Quickly apps.
[17:31] <aquarius> So, cloud-enable your apps! Let's see my song ratings in Rhythmbox or Banshee or Amarok or Exaile or Quod Libet appear on all of my machines. Let's see my Chrome bookmarks appear everywhere, like my Firefox bookmarks already do.
[17:31] <aquarius> Remember, too, that apps can share data. If you want to store song ratings for Amarok in desktopcouch, don't make that storage Amarok-specific; that way, if I decide to switch to Quod Libet I don't have to re-rate all my songs!
[17:31] <aquarius> I'm happy to answer questions about sharing of data between apps if you have them.
[17:31] <aquarius> Also, I'll stop now to take some questions about desktopcouch generally.
[17:32] <aquarius> andypiper> QUESTION: what is Quickly....?!
[17:32] <aquarius> Quickly is an app that helps you make Ubuntu apps really...quickly
[17:33] <aquarius> it takes care of putting together the framework of an application for you, and it makes a deb package for you and uploads the code to launchpad, etc. All the boring stuff that you don't care about when you just want to get your app done
[17:33] <aquarius> the next session, by didrocks, is about quickly, so I'd stick around for that :-)
[17:34] <aquarius> https://wiki.ubuntu.com/Quickly has more
[17:34] <aquarius> yltsrc> QUESTION: is available any standard for database name? And how resolve conflicts with different application?
[17:34] <aquarius> yltsrc, there isn't a standard, as such, for database names, because what the desktopcouch project is trying to avoid is laying down lots of standards that you Must Comply With
[17:34] <aquarius> we're a "rough consensus and running code" sort of group :-)
[17:35] <aquarius> the best place to have discussions about that sort of thing is at http://groups.google.com/group/desktop-couchdb which is the desktopcouch mailing list
[17:35] <aquarius> dekstopcouch records are deliberately set up to have two sections, a "main section" and an "application specific" section
[17:36] <aquarius> so the idea is that apps co-operate on the main section and store app-specific data in the app-specific section
[17:36] <aquarius> for example, Evolution contacts sync in Ubuntu One is done by Evolution storing your contact data in desktopcouch
[17:36] <aquarius> but the format for a contact has been defined
[17:37] <aquarius> and the contacts are stored in a database in desktopcouch called "contacts"
[17:37] <aquarius> so Thunderbird, for example, could *also* sync its contacts to that same database, in the same format
[17:37] <aquarius> and Evolution stores Evo-specific data (like, say, an internal ID) for a contact record in the app-specific part of the contact record
[17:37] <aquarius> and Thunderbird would do the same
[17:38] <aquarius> what this means is that if you decide to switch from Evolution to Thunderbird, you've still got your addressbook! You don't have to export it and re-import it every time you move between applications
[17:38] <aquarius> yltsrc> QUESTION: U1 require python (2.6). Is any plans to run it on python3?
[17:38] <aquarius> I don't believe there is, at the moment, no.
[17:38] <aquarius> b1ackcr0w> QUESTION: SpiderOak is said to be going Open Source soon, are there oppertunities to integrate their services with U1?
[17:39] <aquarius> There could be, certainly. I haven't looked into that in detail myself, but I'll be sure and bring it up!
[17:39] <aquarius> mhall119|work> QUESTION: I want to hack on the server-part of U1, short of becoming a Canonical employee, what can I do?
[17:39] <aquarius> At the moment, you can't, I'm afraid. The source code for the server part of file synchronization is closed.
[17:40] <aquarius> The source code for the server part of desktopcouch is CouchDB, though, and work on that is perfectly doable.
[17:40] <aquarius> We worked closely with the CouchDB upstream project to make sure that all the changes we needed to use CouchDB in Ubuntu One were part of the main CouchDB trunk.
[17:40] <aquarius> yltsrc> Is avalably any FEATURE ROADMAP for U1?
[17:41] <aquarius> that's...sorta what this talk is :) I can see how it might be useful to have a more formal statement of "what's coming up", though. I'll bring that up with the team.
[17:42] <aquarius> yltsrc> QUESTION: is U1 uses dbus? and how i can extend my application to use it?
[17:43] <aquarius> Yes. The syncdaemon, which is the bit that handles file synchronization, exposes D-Bus commands for almost everything it does.
[17:43] <aquarius> OK, I'll carry on.
[17:43] <aquarius> Since desktopcouch is a CouchDB, and since your data is synchronised not only to your other machines but up to the cloud as well, this opens up the intriguing possibility that you can build a web app that can share data with your desktop app.
[17:43] <aquarius> Ubuntu One's CouchDB uses OAuth for authentication.
[17:43] <aquarius> This means that your web app can ask permission from the user to read your desktop app's CouchDB data directly from Ubuntu One.
[17:44] <aquarius> So the data that appears in your desktop app can also be available to that user on the web.
[17:44] <aquarius> This is a pretty new area, so nobody's using it yet, but it's possible.
[17:44] <aquarius> You use OpenID to log the user in to your web app using Ubuntu One -- you may have seen "log in with Twitter" buttons, or "Facebook Connect", which work on the same principle.
[17:44] <aquarius> Once that's done, your web app can then request permission to read the user's CouchDB database to get at the data that your *desktop* app stored there.
[17:44] <aquarius> So, if we think about the song ratings example above, you can build a web application that can show all the song ratings that the user has entered and allow them to be edited.
[17:45] <aquarius> Your users can then manage their song ratings or playlists or whatever else you've stored directly from a web interface if they're not at their actual computer.
[17:45] <aquarius> Sharing data between web apps and desktop apps is quite hard, and not many people are doing it, so this is a chance to offer a feature that no-one else has!
[17:46] <aquarius> DesktopCouch plus web apps give you the ability to share that data without you having to do any extra work.
[17:46] <aquarius> This also gives you the ability to offer mobile apps as a web interface, so people can work with their data from their smartphone and see their work reflected on their desktop when they get back to it.
[17:47] <aquarius> Are there any questions about how linking up desktop apps and web apps would work?
[17:48] <aquarius> mhall119|work> QUESTION: how does it handle when a file is edited on2 different computers before syncing?
[17:49] <aquarius> If that happens, you'll get a .u1-conflict file showing you that there was a conflict, for file synchronization.
[17:49] <aquarius> In desktopcouch, there will be a conflict record for the data.
[17:50] <aquarius> One of the things that we have on our Big List Of Stuff To Do is some sort of graphical conflict management to make dealing with these situations even easier, but that won't be done for 10.04.
[17:51] <aquarius> So at the moment, handling data conflicts is done by the applications that use the data; the applications have a better idea about how to merge/overwrite/handle conflicts than Ubuntu One does most of the time anyway, because Ubuntu One just moves the data around, it doesn't always understand it.
[17:51] <aquarius> qense> (late) QUESTION: When you define a UDF outside the Ubuntu One directory, where will it be synced to when you enable/install Ubuntu One on a different computer?
[17:51] <aquarius> It'll be synced to the same path, so if you mark ~/myfolder as a UDF on computer 1, it'll appear as ~/myfolder on computer 2.
[17:52] <aquarius> duanedesign> QUESTION: Where can I find documentation on the U1 API
[17:52] <aquarius> the desktopcouch API is defined (mostly) in the desktopcouch documentation at http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation
[17:53] <aquarius> the file sync API isn't defined anywhere yet, I don't believe, because we haven't had a chance to do it, so it's reading the source, I'm afraid. https://wiki.ubuntu.com/UbuntuOne has some details, though.
[17:53] <aquarius> emoreno> QUESTION: Is there any way to use a Private Cloud rather than U1 with the same API
[17:54] <aquarius> Not at the moment. The protocol that the syncdaemon uses to talk to the cloud isn't secret, though, so it would be possible to implement a private cloud.
[17:54] <aquarius> mhall119|work> QUESTION: does U1 offer any kind of versioning on it's data, like the ability to retrieve an older version?
[17:54] <aquarius> Not at the moment, no. We've talked about that, but it isn't available now.
[17:55] <aquarius> OK, that's a brief tour of what services Ubuntu One can bring to your apps. You can make the files your app uses be synchronised, you can publish those files publically, you can store data from your apps that will be available everywhere, and you can share that data with web applications.
[17:55] <aquarius> [SLIDE 6]
[17:55] <aquarius> Are there any further questions before I hand over to our next speaker?
[17:56] <aquarius> nealmcb> QUESTION: Re the question on working on the U1 server end - Elliot Murphy recently talked about your open file storage protocol, noted his "build no silos" policy for U1, and talked about e.g. Tomboy integration.  Can you expand on the places that people can work on servers that integrate with U1 protocols?
[17:57] <aquarius> desktopcouch is a CouchDB, so it can replicate data with any CouchDB, including other desktopcouches on your LAN -- see the desktopcouch-pair tool for this, in the desktopcouch-tools package -- and so doesn't even need a server at all
[17:57] <aquarius> Tomboy notes sync was done by us implementing the Snowy API -- Snowy is a Django server to which you can sync your notes, designed by the Tomboy team, and they're looking at doing their own deployment of it
[17:58] <aquarius> qense> QUESTION: Any change there will be a small collection of snippets showcasing webintegration of Ubuntu One?
[17:58] <aquarius> if someone does that I'll love them forever.
[17:58] <aquarius> I'd certainly like to, it's just finding the time :-)
[17:58] <aquarius> OK, if you have other questions, feel free to ping me, or chat on #ubuntuone
[17:59] <aquarius> and I'll hand over to the wonderful dpm and didrocks who are talking about internationalisation, quickly, and Launchpad!
[17:59] <dpm> thanks aquarius!
[17:59] <didrocks> thanks aquarius :)
[18:00] <dpm> [SLIDE 1]
[18:00] <dpm> hey everyone
[18:00] <dpm> and welcome to this session on internationalizating applications with Quickly (https://wiki.ubuntu.com/Quickly)
[18:00] <dpm> https://wiki.ubuntu.com/Quickly
[18:00] <dpm> now
[18:01] <dpm> In the next hour we'll be talking on how to make applications speak your own language using several awesome technologies: Quickly, Gettext and Launchpad
[18:01] <dpm> Your equally awesome speakers today (well, at least didrocks is) will be:
[18:01] <didrocks> Hi, I'm Didier Roche, I work in the Ubuntu Desktop team. I'm more focused on packaging UNE (Ubuntu Netbook Edition), which is the new name of UNR (Ubuntu Netbook Remix) and some GNOME related components.
[18:01] <dpm> [SLIDE 1]
[18:01] <dpm> Hi my name is David Planella, I work as the Ubuntu Translations Coordinator and as such my job is to work together the wonderful Ubuntu translations teams and make sure translations keep rocking as usual. I'm also a GNOME and Ubuntu translator, and lead of the Ubuntu Catalan translation team
[18:02] <dpm> So, without further ado, let's start the session by having a quick look at the main players involved in the internationalization game:
[18:02] <dpm> [SLIDE 2]
[18:02] <dpm> == GNU Gettext ==
[18:02] <didrocks> dpm: maybe, the link to the slides for people not having lernid if you have it :)
[18:03] <dpm> here it is : http://people.ubuntu.com/~dpm/Quickly-i18n.pdf
[18:04] <dpm> Gettext is the underlying and most widely used technology to enable translations of Open Source projects.
[18:04] <dpm> It defines a standard format of translation files translators can do their work with (PO files)
[18:04] <dpm> and lets applications load those translations compiled in a binary format (MO files) at runtime.
[18:04] <dpm> It has implementations for many programming languages, and amongst them, of course, Python.
[18:05] <dpm> You'll find that the comprehensive gettext manual at http://www.gnu.org/software/gettext/manual/gettext.html can be a very useful reference,
[18:05] <dpm> especially in those sleepless nights.
[18:05] <dpm> The Python implementation of the gettext API is what we'll use to internationalize our project with Quickly today.
[18:05] <dpm> Needless to say, it also comes with some nifty documentation at http://docs.python.org/library/gettext.html
[18:05] <dpm> == intltool ==
[18:06] <dpm> Intltool is a higher level tool that adds functionality to gettext by allowing the extraction of translatable strings from a variety of file formats
[18:06] <dpm> It has also become a standard tool when implementing internationalization for OSS projects. Nearly all (if not all) GNOME projects, for example, use intltool.
[18:06] <dpm> It has also become a standard tool when implementing internationalization for OSS projects. Nearly all (if not all) GNOME projects, for example, use intltool.
[18:06] <dpm> For those interested in trivia, Danilo Šegan (or Данило Шеган, for those who can read cyrillic), our very own Launchpad Translations developer lead is also the co-maintainer of intltool.
[18:07] <dpm> == python-distutils-extra ==
[18:07] <dpm> Python-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.
[18:07] <dpm> The project's page is at http://www.glatzor.de/projects/python-distutils-extra/
[18:08] <dpm> The three above technologies (gettext, intltool, python-distutils-extra) are transparently used by quickly, so we won't get into much more detail for now.
[18:08] <dpm> There are also more aspects involved in internationalizing applications, such as font rendering, input methods, etc., but this should get you started for now.
[18:08] <dpm> == Quickly ==
[18:08] <dpm> I'll be very brief here and let Didier tell you more about Quickly in a bit.
[18:08] <dpm> For now, it will suffice give you a teaser and tell you that it is the tool which brings back the fun in writing applications
[18:09] <dpm> == Launchpad Translations ==
[18:09] <dpm> Launchpad 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.
[18:09] <dpm> Apart 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),
[18:10] <dpm> global 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.
[18:10] <dpm> On 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.
[18:10] <dpm> I'll now hand over the mike to Didier to tell you more about what you all have wanted to hear: Quickly!
[18:11] <didrocks> [SLIDE 3]
[18:11] <didrocks> To follow that session, you can install Quickly on karmic or lucid simply by executing $ sudo aptitude install quickly.
[18:11] <didrocks> well, if you are brave an courageous, you can also run from the trunk lp:quickly ;)
[18:12] <didrocks> Once Quickly is installed, close the terminal and open a new one so that statement completion works (and you will love Quickly statement completion ;))
[18:12] <didrocks> But first, what is Quickly? In a nutshell, Quickly makes it easy and fun to write apps.
[18:12] <didrocks> Rick Spencer (leader of Ubuntu Desktop team) is the inspiring sources of Quickly and he started the first version of the app in May 2009.
[18:12] <didrocks> In Ubuntu and more generally in GNU/Linux, we have tons of good libraries, rocking technologies and programming languages.
[18:13] <didrocks> But there are so many that some times it's difficult to pick "what I should choose".
[18:13] <didrocks> Not talking about deprecating technologies that you just discover their current unmaintained state once you have almost finished your apps (libglade, I'm looking at you!)
[18:14] <didrocks> So, what's in Quickly?
[18:14] <didrocks> Quickly has two parts: the core, which basically parses your input and templates.
[18:14] <didrocks> Templates are sets of commands and code generators that are designed to work together in an end to end fashion to help developers write a certain kind of application.
[18:15] <didrocks> But we can also imagine a LaTeX template, a template to manage doc…
[18:15] <didrocks> A template can be written for using whatever technology in whatever language of your choice.
[18:15] <didrocks> for instance, I'm working on a snippet template for awesome Jono's acire app :)
[18:16] <didrocks> So, with templates, you can then create application or document set.
[18:16] <didrocks> We'll focus there only on i18n with the first template that Quickly 0.2 provides: ubuntu-project (renamed ubuntu-application on the coming 0.4 release!)
[18:16] <didrocks> (this template is using Glade, couchdb, has some nice trick for gedit, use bzr, and complete integration with LaunchPad and debian packaging)
[18:16] <didrocks> For instance, Lernid that some of you may use to assist UDW, has been created with the ubuntu-project template. (http://www.jonobacon.org/?p=2258 for a shot of the story)
[18:17] <didrocks> [SLIDE 4]
[18:17] <didrocks> So, let's create first a simple ubuntu-project (assuming you are using Quickly 0.2):
[18:17] <didrocks> $ quickly create ubuntu-project fooby
[18:17] <didrocks> (assuming also that you successfully installed Quickly and opened a command line ;))
[18:18] <didrocks> this tells Quickly to use the ubuntu-project template, and to call what is created "fooby"
[18:18] <didrocks> This causes a bunch of info to be dumped to the command line, but ends with the application being run
[18:18] <didrocks> What Quickly did was to copy over basically a sample application, and do some text switcheroos to customize the app
[18:18] <didrocks> You can see there the ui which contains some text that needs translation.
[18:19] <didrocks> To start making change to your app, cd to it (normally "$ cd fooby").
[18:19] <didrocks> You can then edit your code with $ quickly edit, change the ui with $ quickly glade, and try your changes with $ quickly run
[18:19] <didrocks> You can save your change with $ quickly save
[18:19] <didrocks> Finally, to package, share, release your apps so that other will be, with the following commands (not all are necessary): $ quickly package / $ quickly share / $ quickly release
[18:20] <didrocks> It would ask for minor things that it'll do for you as creating the package, licensing, etc.
[18:20] <didrocks> We won't cover in anymore detail Quickly or ubuntu-project template here (quickly help <command> does this for you), you can find more pratical info at: https://wiki.ubuntu.com/MeetingLogs/devweek0909/QuicklyFun
[18:21] <didrocks> And a detail review of Quickly there: http://blog.didrocks.fr/index.php/post/Build-your-application-quickly-with-Quickly%3A-part1 (this will kill my local Internet connection as I'm self-hosted ;))
[18:21] <didrocks> You can also appreciate (or not) my French accent and see Rick and myself (jet lagged for my defense) presenting how to create an app with Quickly ubuntu-project template at http://www.youtube.com/watch?v=OOQOzPgLGLg
[18:21] <didrocks> It was during last Ubuntu Developer Summit at it's starting at minute 17'.
[18:22] <didrocks> David will now present you in more details what you will do in "quickly edit" and "quickly glade": adding internalization support to your app.
[18:22] <dpm> Thanks Didier, I hope this got you all excited about trying out Quickly!
[18:23] <dpm> As the project stands now, it has the infrastructure for internationalization in place, but we have to initialize it to enable it.
[18:23] <dpm> This will include:
[18:23] <dpm>   * Initializing gettext
[18:23] <dpm>   * Marking strings for translation
[18:23] <dpm>   * Updating the translation template
[18:23] <dpm> [SLIDE 5]
[18:24] <dpm> [SLIDE 5]
[18:24] <dpm> First of all, we'll initialize gettext, which will basically be adding four lines of code. Here's how it goes:
[18:24] <dpm>   quickly edit
[18:24] <dpm> This will open all your project files in a text editor (Gedit by default)
[18:24] <dpm> 1. Go to the fooby file and add the following two lines below 'import gtk', near the top of the file:
[18:24] <dpm> import gettext
[18:24] <dpm> import locale
[18:25] <dpm> This will import the required modules for internationalization
[18:25] <dpm> 2. Still on the fooby file, add the following line below the 'import logging, optparse' one, near the end of the file:
[18:25] <dpm> gettext.install('fooby', unicode=True)
[18:25] <dpm> This will install the _() function to mark (and call) translations as such in Python’s builtins namespace, based on the 'fooby' domain. The domain basically tells gettext where to load translations from.
[18:25] <dpm> This will also save you to include 'import gettext' statements in all of your project files using gettext.
[18:25] <dpm> Refer to the gettext documentation to find out more about translation domains.
[18:26] <dpm> 3. Finally, add the following line to 'fooby', before the 'builder = gtk.Builder()' line
[18:26] <dpm> locale.textdomain('fooby')
[18:26] <dpm> This will tell GtkBuilder about the translation domain as well
[18:26] <dpm> So that was it! Let's move on to marking strings for translation:
[18:26] <dpm> First of all we'll tackle the .destop file
[18:27] <dpm> Open the fooby.desktop.in file and prepend the Name and comment fields with an underscore (_), so they look like:
[18:27] <dpm> _Name=Fooby
[18:27] <dpm> _Comment=Fooby application
[18:27] <dpm> This will tell intltool that this strings contain translations
[18:27] <dpm> Next comes the UI. Let's see how you can mark strings in the UI for translation. Try:
[18:27] <dpm>   quickly glade
[18:27] <dpm> This will open your UI files in the glade editor.
[18:28] <dpm> Once opened, click on the "Your application has been created! ..." label, find it in the General > Label field on the right, click on the ellipsis (the three dots) button and...
[18:28] <dpm> amaze at the fact that it has already been marked as "Translatable", so you won't have to do anything.
[18:28] <dpm> Right, so next comes something very important that you'll have to bear in mind for all strings you'd like to be translatable in your application:
[18:28] <dpm> using the _() function call.
[18:28] <dpm> This will mark them as translatable and call gettext to load the translations, and should be used for all messages you'd like to present to users.
[18:29] <dpm> Let's just see how we can do this.
[18:29] <dpm> Go back to your fooby file and find the "parser.add_option("-v", "--verbose", action="store_true", dest="verbose", help="Show debug messages")" line near the bottom.
[18:29] <dpm> We want the "Show debug messages" message to get shown to users in their language, so we'll enclose it with the _() function, and it will look like:
[18:29] <dpm> parser.add_option("-v", "--verbose", action="store_true", dest="verbose", help=_("Show debug messages"))
[18:30] <dpm> Now we're done
[18:30] <dpm> The last part will be to update the translations template.
[18:30] <dpm> A translations template is a formatted text file generally named yourproject.pot
[18:30] <dpm> which contains your project's translatable strings in English and what translators use as a basis for their translations.
[18:30] <dpm> You should do this before each release, so that translations are put in this template and are up-to-date for translators to work on.
[18:30] <dpm> It is considered good practice to announce a string freeze (that is, the period in which strings are considered to be stable) a week or two before the release, so that translators know when they can start their work.
[18:31] <dpm> This can be done in several ways with quickly, let's pick one:
[18:31] <dpm>   quickly package
[18:31] <dpm> After running this, you'll notice that (apart from having your application packaged!) there is a 'po' folder containing the translation template, ready for translators to work on.
[18:31] <dpm> If you open it, you'll notice the format and will see that all the strings you marked for translation are there.
[18:31] <dpm> You can also do this with 'quickly share', 'quickly release' or directly using the python-distutils-extra command: './setup.py build_i18n'
[18:32] <dpm> == Launchpad Translations ==
[18:32] <dpm> If this weren't awesome enough, once you've created a project in Launchpad ('quickly share', 'quickly release' or https://help.launchpad.net/ will help you on that) you can expose it for translations,
[18:32] <dpm> so that you as a developer can use the automatic bzr import/export features to basically "forget" about translations and translators can use the web UI to translate.
[18:33] <dpm> Let me tell you a bit more on those:
[18:33] <dpm> [SLIDE 6]
[18:33] <dpm> == Automatic imports ==
[18:33] <dpm> Enabling this feature will allow you to automatically import the translation template for your application into Launchpad upon commit, with no further steps required.
[18:34] <dpm> So the basic workflow will be: hack, hack, hack, update template, commit, have translators automagically see the new strings in Launchpad.
[18:34] <dpm> In time, Launchpad Translations will grow the ability to automatically generate the templates, so you won't have to worry about updating it and commit it, but for now, the .pot template has to be kept under revision control.
[18:34] <dpm> You can find more about this at http://blog.launchpad.net/translations/import-translation-templates-from-your-projects-bazaar-branches and http://blog.launchpad.net/general/trying-out-launchpad-translations
[18:34] <dpm> Even better, there's a screencast available showing how to enable this at http://blog.launchpad.net/translations/screencast-importing-translation-templates-from-a-bazaar-branch
[18:35] <dpm> == Automatic exports ==
[18:35] <dpm> With automatic exports, you'll be able to complete the whole circle for automation: getting translations committed automatically (daily) to a bzr branch of your choice, so that neither you nor translators have to worry to get translations into your project.
[18:35] <dpm> I personally find this one of the most coolest features
[18:35] <dpm> Here's more info: http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch
[18:35] <dpm> And here's a screencast on how to enable it http://blog.launchpad.net/translations/screencast-exporting-translations-to-a-bazaar-branch
[18:36] <dpm> Least but not last, you might also want to find out more on what message sharing is, enabling translations between multiple project series to have strings translated automagically across those series: http://blog.launchpad.net/translations/screencast-sharing-translations-between-releases-of-the-same-project
[18:36] <dpm> == Permissions ==
[18:36] <dpm> One very important aspect is how you want translations permissions for your project to be. This basically means choosing who will be responsible for submitting and reviewing those translations for each language.
[18:37] <dpm> Launchpad is flexible in allowing different levels of openness for translating your project.
[18:37] <dpm> This generally means that you as a maintainer will have to make a decision to balance openness (open translations for everyone) with quality control (a more closed process with reviewers and a QA workflow).
[18:37] <dpm> The Launchpad help page on permissions at https://help.launchpad.net/Translations/YourProject/PermissionPolicies explains very well the different permissions you can use (Open, Structured, Restricted and Closed).
[18:37] <dpm> If you decide for quality, you'll next have to choose to whom you assign the translation of your project.
[18:38] <dpm> Here is where translation groups come to the rescue.
[18:38] <dpm> Translation groups are confederations of translation teams, one for each language you can assign as a pack to translate your project. The teams in those groups are considered to be trusted to have experience with translations and generally have a review process in place.
[18:38] <dpm> Here's a list of all current translation groups: https://translations.launchpad.net/+groups
[18:39] <dpm> You can see that the two biggest ones are Launchpad Translators and Ubuntu Translators.
[18:39] <dpm> While you can create a translation group specific to your project, we generally encourage maintainers to choose one of the existing ones,
[18:39] <dpm> in order to reuse the pool of translators and not to further fragment translations communities.
[18:39] <dpm> I personally recommend choosing Restricted (or Structured), assigned to the trusted Launchpad Translators or Ubuntu Translators (if your project is Ubuntu-specific) translations groups
[18:39] <dpm> I'll now leave you in didrocks' good hands to tell you more on Quickly's new to come in the internationalization front:
[18:40]  * dpm hands the mike to didrocks
[18:40] <didrocks> Thanks David, you know that Quickly is using automatic export/import for Quickly itself? That's just awesome, no more to bother about generating templates, uploading them, downloading the localization: just use bzr!
[18:40] <didrocks> It's using Restricted permission and we already have a lot of language supported in Quickly thanks to the rocking Launchpad Translator groups :)
[18:40]  * dpm knew, he's been translating Quickly into Catalan! ;)
[18:41] <didrocks> amazing ;)
[18:41] <didrocks> (you started it IIRC)
[18:41] <didrocks> ;)
[18:41] <didrocks> [SLIDE 7]
[18:41] <didrocks> Quickly 0.4 will bring a lot of new experiences and commodities to the users (more than 200 commits, 6 months of hard work!) and will be delivered in lucid.
[18:42] <didrocks> Regarding internationalization, all the tedious job of importing/initalizing gettext and adding _() will be done for you in all newly created apps.
[18:42] <didrocks> (now that I've assisted to the session, will be easier to do the right thing ;))
[18:42] <didrocks> "$ quickly add pythonfile" will also add one boiler plate file containing that for you.
[18:42] <didrocks> Quickly 0.6 (don't know when it'll be available but at least in 6 months ;)) will try to achieve the automatic imports and exports previously described on each $ quickly share / $ quickly release command.
[18:43] <didrocks> So, normally, you won't have to bother anymore about localization and being in sync with the awesome work of your contributors
[18:43] <didrocks> just use _(…) for each string
[18:43] <dpm> I think we should then announce that there won't be any need for such talks in the future, as quickly will do nearly all this for you!
[18:43] <didrocks> ok, and that's it for the session, dpm, back on the field to tackle questions? ;)
[18:44] <dpm> sure, didrocks, if you give me a hand with the quickly ones?
[18:44] <didrocks> dpm: for great pleasure :)
[18:44] <didrocks> with*
[18:44] <cjohnston>  AnAnt> QUESTION: why is it advisable to export to another bzr branch ?
[18:44] <dpm> you can use the main branch if you like
[18:45] <dpm> in fact Lernid does IIRC
[18:45] <dpm> but this adds a lot of automatic commits to the branch
[18:45] <dpm> and not all developers like this
[18:45] <dpm> so they use a separate b ranch for the auto-commits
[18:45] <dpm> of translations
[18:45] <dpm> and then merge those translations back to the main branch when they need to
[18:46] <dpm> e.g before release
[18:46] <dpm> next question?
[18:46] <didrocks> look at: https://code.edge.launchpad.net/~quickly/quickly/quickly-po for instance (merged in Quickly trunk before release) :)
[18:46] <cjohnston> < foobob> QUESTION: any plans to use transifex for the localization of ubuntu?
[18:47] <dpm> that's a bit out of topic, since we're not discussing the translation of Ubuntu - in any case, as awesome as Transifex is, we'll continue using owr own awesome translations tool
[18:47] <dpm> Launchpad Translations
[18:47] <dpm> which has got many features no other tool has
[18:47] <dpm> next questio, please?
[18:47] <cjohnston> If you asked a question during the class that has not yet been answered, please ask it again.
[18:48] <cjohnston> < lernid_alucardni> QUESTION: any plans to integrate Quickly with other version control systems such as git?
[18:48] <didrocks> lernid_alucardni: Quickly is only the core: so, you can implement your own template using any other vcs
[18:48] <didrocks> something like ubuntu-application-with-git :)
[18:48] <didrocks> or a better name of course
[18:49] <didrocks> but if you want to develop a template with that, you can. Quickly 0.4 is able to import commands from another template
[18:49] <didrocks> so, that save a lot of typing and ease your template creations
[18:50] <didrocks> I don't personnaly know very well git and I think ubuntu-application user, in the ideal case, don't have to bother with which VCS its using
[18:50] <didrocks> also, moving to another VCS means loosing the tight integration with Launchpad :/
[18:50] <didrocks> so, well, it's possible and if you want to give it a try, just go on #quickly, I'll help you to be on the track :)
[18:51] <didrocks> next?
[18:51] <cjohnston> < AnAnt> QUESTION: some projects use XML (rather than po) for translation, is that supported (or will be supported) in Launchpad ?
[18:51] <dpm> Launchpad standardises on the Gettext format, so it does not directly work with xml. That said,
[18:52] <dpm> you can use conversion tools to convert e.g. docbook, xml docs to PO and then import them to Launchpad
[18:52] <dpm> There are some projects which successfully do that
[18:52] <dpm> like for example the ubuntu-dosc
[18:52] <dpm> ubuntu-docs
[18:52] <dpm> also,
[18:53] <dpm> Launchpad is open source, so if anyone is willing to implement other formats
[18:53] <dpm> the developers will be happy to mentor them
[18:53] <dpm> check out
[18:53] <dpm> https://dev.launchpad.net/Getting
[18:53] <dpm> and the session tomorrow on Launchpad translations under the hood
[18:54] <dpm> by adiroiban and henninge
[18:54] <dpm> or you can ask for help on #launchpad-dev
[18:54] <dpm> sorry, I forgot to mention the tool to convert xml to PO
[18:54] <dpm> that's xml2po, available in the main repositories
[18:55] <dpm> and it can convert back to xml once the translations are done
[18:55] <dpm> ok, next question?
[18:55] <cjohnston> < bullgard47> QUESTION: You showed us wonderful translation tools. Why does a German user still find a lot of untranslated strings in Karmic GNOME programs?
[18:56] <dpm> Well, there's quite a lot of translation work to do to translate a full OS - you can contribute to the German translation by joining the Ubuntu German translations team at https://launchpad.net/~ubuntu-l10n-de
[18:56] <dpm> and they should get you started
[18:56] <dpm> or ask us at #ubuntu-translators
[18:57] <dpm> any quickly-related questions?
[18:57] <didrocks> dpm: seems, that people are more focussed on i18n ones ;) You won't get any rest :)
[18:57] <dpm> hehe
[18:58] <dpm> I like that
[18:58] <didrocks> oh, I saw that one:
[18:58] <didrocks> Nafai | Question: Can quickly be configured to use an editor other than gedit?
[18:58] <dpm> well spotted ;)
[18:58] <didrocks> Nafai: yes, you just have to configure it with sensible-editor or export EDITOR variable in your shell
[18:58] <didrocks> then, ubuntu-project template will spot your preferred editor with quickly edit
[18:58] <didrocks> quickly help edit for more info :)
[18:59] <cjohnston> < OwaisLone> QUESTION: Any plans for a Quickly API so that it can kinda hooked into IDEs like Anjuta and Geany?
[18:59] <didrocks> OwaisLone: yes, it's on the road for 0.4
[19:00] <didrocks> so, you'll get a nice API on lucid version of Quickly :)
[19:00]  * didrocks taps gavel
[19:00] <dpm> cool, so I think we can just to thank everyone listening to us and participating, you truly rocked! Thanks!
[19:00] <didrocks> I think we should leave the field to the next session before being hit :)
[19:00] <didrocks> thanks a lot everybody, feel free to ping us and join #quickly
[19:01] <didrocks> soren will now discuss about Automated server testing :)
[19:01] <didrocks> oups
[19:01] <didrocks> sorry, tedg's turn
[19:02] <didrocks> from the awesome dx team and indicator applet's hacker
[19:02] <tedg> Cool, thanks cjohnston!
[19:02] <cjohnston> yup
[19:02] <tedg> I was yelling, but it was no good :)
[19:02] <tedg> Howdy everyone.
[19:03] <tedg> This is the session on AppIndicators
[19:03] <tedg> Or I guess "Application Indicators" but I'll use AppIndicators for short.
[19:04] <tedg> Basically what AppIndicators are is a way for applications to add extra things to the panel for functionality that is continuously used throughout a users session.
[19:04] <tedg> For the most part, there aren't a lot of applications that users need all the time, so it's important to think about whether an application needs an AppIndicator before starting.
[19:05] <tedg> Some of the design considerations that you should take into account are available here:
[19:05] <tedg> https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines
[19:06] <tedg> One of the key values of AppIndicator that makes it a little different that the legacy notification area in the Freedesktop world (and systray in win32) is that it restricts every application to having a menu.
[19:06] <tedg> This is a tradeoff.
[19:06] <tedg> We want something that let's applications do really cool stuff and provide rich functionality to users, but at the same time we want the user to know what to expect when the click on an icon.
[19:07] <tedg> With the old notification area, users didn't know what to do.  They learned it, but they didn't know, and often made mistakes.
[19:07] <tedg> This predictability will hopefully make users feel more comfortable using Ubuntu.
[19:07] <tedg> Some of the usability rationale is here:
[19:07] <tedg> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
[19:08] <tedg> Of course, as you go down that page you'll start to realize that we do have migration issues.
[19:08] <tedg> If we removed the notification area in a signal release, that would suck for both users and app developers as there'd be no way to port all those applications in one cycle.
[19:08] <tedg> So, for Lucid, there will still be a notification area, but we want to get rid of it ASAP.
[19:09] <tedg> I hope we can for Lucid + 1, but we're planning to make the final decision there at UDS.
[19:09] <tedg> You can see our planes in abstract fashion here:
[19:09] <tedg> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Proposed%20changes
[19:10] <tedg> So, then, that leads to: How do you do it?
[19:10] <tedg> :)
[19:10] <tedg> What we did is provide a small convenience library called libappindicator which provides the basic interface for adding an application to the panel.
[19:11] <tedg> At a high level you give it an icon, and a standard GTK menu, and it does the rest.
[19:11] <tedg> Though, it's likely that many applications will want to move slightly beyond that.
[19:12] <tedg> Let's first look at a sample little program in Python.
[19:12] <tedg> because well, python make jonobacon25 happy :)
[19:12] <tedg> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Python%20version
[19:12] <tedg> If you look at that python snippet one of the most important things is the object creation.
[19:13] <tedg> appindicator.Indicator ("example-simple-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS)
[19:13] <tedg> Basically there are three parameters.
[19:13] <tedg> The first is a unique ID for your application.
[19:14] <tedg> In most cases this will be the program name, package name, or something that is unique to your app
[19:14] <tedg> The second is your default icon.  In this example the indicator-message icon is being stolen.  Any icon in an icon theme can be used.
[19:14] <tedg> Lastly is the category that your app indciator is in.
[19:14] <tedg> This category is used for general grouping of the app indicators.
[19:15] <tedg> This creates the basic object that is the app indicator.  But, you also need a menu.
[19:15] <tedg> Basically that is done with: ind.set_menu(menu)
[19:16] <tedg> The rest of the code is standard PyGTK code for creating the menu.
[19:16] <tedg> Let me grab some questions here.
[19:16] <tedg> jwendell: QUESTION: why to do this if panel is about to dead anyway?
[19:16] <tedg> jwendell: I don't think panels in general are dead.  GNOME Panel is, but that's only a small part of this.
[19:17] <tedg> jwendell: The overall user experience change is what we're pushing right now, the gnome-panel applet is a small part of that.
[19:17] <tedg> ripps818: QUESTION: Are there going to be vala bindings?
[19:17] <tedg> ripps818: Yes, there's actually a patch for that now.  I just need to get it merged in.
[19:18] <tedg> ripps818: I'll find the bug number for you afterwards, ping me.
[19:18] <tedg> qense: QUESTION: GNOME Shell is developing things that replace the functionality of AppIndicator, Notify OSD, MeIndicator, etc almost exactly. Is Ayatana working there as well, or is this duplicating of effort?
[19:19] <tedg> qense: I hope that they won't duplicate all of this effort.
[19:19] <tedg> qense: They're working on various things, but mostly I believe they've used some existing specs like the notification area so far.
[19:19] <tedg> qense: I hope that they'll use some of this work when they go beyond this.
[19:20] <tedg> qense: But, of course, I can't force them to take our code.
[19:20] <tedg> qense: :)
[19:20] <tedg> Okay, I think I caught up on some of the questions.  I'll continue on for a bit to collect some more :)
[19:21] <tedg> So we went through some of the basic code to create an AppIndicator.
[19:21] <tedg> This is the core boiler plate, but I want to talk about a few other bits that are in the examples.
[19:21] <tedg> One of the things that the appindicator library provides is an easy way to switch between an attention icon and a standard icon.
[19:22] <tedg> First you'll need to set the AttentionIcon using a call like this: ind.set_attention_icon ("indicator-messages-new")
[19:22] <tedg> That basically just puts the icon in queue for when the status gets changed.
[19:23] <tedg> And then you can call "set_status" like this:
[19:23] <tedg> ind.set_status (appindicator.STATUS_ACTIVE)
[19:23] <tedg> There are three statuses (statusi ?)
[19:23] <tedg> Passive, which means the icon isn't shown.  Active, which shows the default icon.  And Attention, which uses the attention icon.
[19:24] <tedg> Many apps do something like this where you'd have a basic icon in a standard state, then when something like you have a task to complete, it switching to an icon that draws the users attention.
[19:25] <tedg> Those are probably the most interesting parts of the libappindicator API for app developers.
[19:25] <tedg> The full API (in C) is available here: http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html
[19:26] <tedg> It has all the functions you could possibly love :)
[19:26] <tedg> npmccallum: tedg: QUESTION: One of the biggest advantages of the standard GtkStatusIcon (and I know Qt has something similar) is cross-platform support.  What is the cross-platform support plan for AppIndicators?
[19:26] <tedg> npmccallum: Thanks, I forgot to mention that :)
[19:27] <tedg> npmccallum: We've based all of this work on a spec developed and released by the KDE developers.
[19:27] <tedg> npmccallum: It's call StatusNotifierItem and it's currently being discussed on the XDG list for official Freedesktop.org status.
[19:28] <tedg> npmccallum: So we hope for Lucid to provide an experience where KDE apps will run under GNOME with native menus and look beautiful.
[19:28] <tedg> npmccallum: And integrated with the desktop as a whole.  More than with the notification area previously.
[19:28] <tedg> AnAnt: QUESTION: is there a screenshot (or video) showing AppIndicators in action ? I saw some video few days ago, but I figured nothing from it
[19:29] <tedg> AnAnt: The only video I have is an early demo that I put on my blog.
[19:29] <tedg> AnAnt: http://gould.cx/ted/blog/Having_a_tidy_systray
[19:29] <tedg> AnAnt: It just has a few of the same, but kinda shows them working.
[19:30] <tedg> npmccallum: BTW, here's the spec: http://www.notmart.org/misc/statusnotifieritem/
[19:30] <tedg> qense: QUESTION: Does it do flickering and yelling and fireworks? Or just another icon?
[19:31] <tedg> qense: Just another icon.  The goal here is to use icon names for the different visualizations so they can be better matched to the panel theme in general.
[19:31] <tedg> qense: Also, in general, I dislike the <blink> tag :)
[19:31] <tedg> npmccallum: tedg: QUESTION2 - How about rendering icons on the fly?  I have an app that currently draws the icon on the fly with cairo and renders into a pixbuf, then displays with GtkStatusIcon.  Can I do this with AppIndicators?
[19:32] <tedg> npmccallum: No, for the same reason as above.
[19:32] <tedg> npmccallum: tedg: QUESTION1 revisited - I meant cross-platform as in win32 and mac
[19:33] <tedg> npmccallum: The libappindicator will fallback and create a GtkStatusIcon if there is no Application Indicator service availabe.
[19:33] <tedg> npmccallum: So I would image that it would work on win/mac like the current status icon.
[19:33] <tedg> npmccallum: Though I haven't tested it or tried.
[19:34] <tedg> I wanted to talk a little more about the fallback.
[19:35] <tedg> The way that the fallback is implemented is that it's a set of two functions that are on the class of the AppIndicator.
[19:35] <tedg> Some applications may wish to provide a different fallback than what is set up by default.
[19:35] <tedg> To provide a different fallback what an app developer will need to do is to subclass the AppIndicator class and replace those two functions.
[19:36] <tedg> Actually, a good place to look for that example is in the app-indicator.c file.
[19:36] <tedg> As the two functions that are put there were designed to only use public API functions.
[19:36] <tedg> So you should be able to copy-and-paste them into your own code, and then modify what you'd like to change.
[19:37] <tedg> I wanted to talk a little about menus, and a good lead off is:
[19:37] <tedg> lantash58: QUESTION: Is there a reason why menu entries with icons are indented? See http://dl.dropbox.com/u/232786/indicator.png Will the still icons be dropped as seen in regular menus?
[19:37] <tedg> Yes the icons are indented.
[19:38] <tedg> This is an issue with being cross desktop.
[19:38] <tedg> The reason that they're not indented on GTK is that you can't have a check box and an image in the same item.
[19:38] <tedg> So they can both override that space with their own graphic.
[19:38] <tedg> But most toolkits don't have that restriction.
[19:39] <tedg> So we need to be able to do both in a consistent fashion, and thus the icons need to be indented as shown there.
[19:39] <tedg> In general, for Lucid we're supporting the basic menu types that are found in stock GTK.
[19:39] <tedg> Those are image item, label item, radio and checkbox.
[19:40] <tedg> While we certainly realize that people do more with menus than just those, the realities of a timed release schedule is that we don't get all we want :)
[19:40] <tedg> (and I need to sleep sometime) :)
[19:40] <tedg> So we expect to, for Lucid + 1 and beyond to start taking into account more complex menu needs.
[19:41] <tedg> For instance in Tomboy there are pins in the right gutter.
[19:41] <tedg> Or in KNetworkManager there are widgets to show signal strength.
[19:42] <tedg> These menus pose quite a challenge, but it's one I'm personally excited to take on.
[19:43] <tedg> Okay, that's all I have in my outline.
[19:43] <tedg> Are there more questions for me?
[19:44] <tedg> AnAnt: QUESTION: so how will clutter be reduced ?
[19:45] <tedg> AnAnt: We expect clutter to be reduced in a few ways.
[19:45] <tedg> AnAnt: The first is that a lot of clutter is disorganization, when things to feel like they connect together right.
[19:45] <tedg> AnAnt: By having a single interface (menu) we hope that the whole thing will feel more unified.
[19:45] <tedg> AnAnt: Secondly, but using icon names theme designers can do a specific "panel" theme that'll work across applications.
[19:46] <tedg> AnAnt: Where before that was nearly impossible as changing an icon would change it everywhere.
[19:46] <tedg> AnAnt: So if you changed the panel, in many cases you'd change the About screen too.
[19:46] <tedg> AnAnt: So we expect less visual clutter on the panel itself.
[19:46] <tedg> npmccallum: tedg: QUESTION: Would you consider adding a set_icon_with_number() API which would take a background icon and render a number on top of it?
[19:47] <tedg> npmccallum: Definitely consider it.  I think I'd need to see some use cases for how it should work and all that jazz.
[19:47] <tedg> npmccallum: Jump onto the Ayatana mailing list and let's talk about it further.
[19:47] <tedg> npmccallum: Though, just incase my manager is listening, not for Lucid.  Lucid + 1 ;)
[19:48] <tedg> qense: QUESTION: Is there a library for receiving the AppIndicator signals?
[19:48] <tedg> qense: For the most part there aren't that many AppIndicator signals, just a couple coming off the object itself.
[19:48] <tedg> qense: For most of the user actions they're routed into the various GTK menu items.
[19:48] <tedg> qense: So you can use the standard GTK signaling that is already in the rest of your application.
[19:49] <tedg> oskude: joined little late, so maybe i missed a question like this QUESTION - is there a tutorial to do an "applet" with a window that opens directly under the applet icon ? (like time/date/calendar/tasks/locations applet)
[19:50] <tedg> oskude: No, we'd really like people to think of this as "applications" and "menus" instead of doing pseudo menus like the calendar applet.
[19:50] <tedg> oskude: If you have specific features you'd like in a menu for an idea you have.
[19:50] <tedg> oskude: I'd like to talk about that, so we can make sure menus handle as many use cases as possible.
[19:51] <tedg> (obviously we don't want a mail client in a menu) :)
[19:52] <tedg> oskude: Yes, I'd agree.  I think that a internet radio tracklisting is a usecase that we can put into a menu.
[19:53] <tedg> oskude: Draw it up, by hand, whatever.  Throw it on the Ayatana list, and lets try to get that spec'd out for Lucid + 1.
[19:54] <tedg> I've said it a couple of times, but here's the link for the Ayatana mailing list.
[19:54] <tedg> https://launchpad.net/~ayatana
[19:54] <tedg> It's in Launchpad so you just have to join that team and you'll start getting mail :)
[19:56] <tedg> Cool, I think that pretty much wraps things up.
[19:57] <tedg> Thanks everyone for coming.
[19:57] <tedg> I'm usually in #ayatana on Freenode if something comes up.
[19:57] <tedg> Ping me there, or join the Ayatana mailing list above.
[19:57] <tedg> Thanks again!
[20:00]  * soren clears throat
[20:00] <soren> Hi, everyone.
[20:00] <soren> Thanks for coming to my session on Automated Server Testing.
[20:00] <soren> So..
[20:00] <soren> In the server team, we've traditionally had a problem with collecting test results.
[20:01] <soren> (question in #ubuntu-classroom-chat, by the way. please put "QUESTION" so that I will spot them)
[20:01] <soren> This is because our target audience and most of our users are using Ubuntu on servers that are being used to service real users.
[20:01] <soren> Real users, as you are probably aware, depend on their servers to work.
[20:01] <soren> They need mail server to be up and delivering mail so that they can get their daily dosage of spam..
[20:02] <soren> They need their file server to be around so they can get access to their music and various pirated software..
[20:02] <soren> They need their proxy server to work so that they can log onto facebook..
[20:02] <soren> They need the LDAP server to work so that they can look up the phone number for the pizza guy..
[20:02] <soren> And other important things.
[20:02] <soren> You get the idea.
[20:02] <soren> If something should fail, it means pain and suffering for the poor sysadmin.
[20:02] <soren> Hence, sysadmins are very hesitant to upgrade anything before it's been through lots and lots of QA.
[20:03] <soren> However, unless /some/ of them /do/ upgrade, there's not going to be much QA work done.
[20:03] <soren> This places us in a rather unfortunate situation, where a significant portion of our bug reports don't come in until after release.
[20:03] <soren> Anyone involved in Ubuntu development will know that this is a hassle, since fixing things after release is much more tedious than before release, since we have much less freedom to make changes.
[20:04] <soren> This is very difficult to change, and I haven't come up with a golden solution.
[20:04] <soren> However, the sooner we catch problems, the more time we have to work on fun stuff since we'll be putting out less fires in the end.
[20:04] <soren> See, while we're cursed with a user base that doesn't start testing our product until it's essentially too late..
[20:05] <soren> ..we areblessed with a type of software that traditionally comes with a good test suite.
[20:05] <soren> MySQL for instance, comes with an extensive test suite.
[20:05] <soren> This test suite runs every time we upload a new version of mysql to Ubuntu.
[20:06] <soren> If the test suite fails, the build fails, and the uploader gets an e-mail.
[20:06] <soren> ...and it's all very obvious that something needs fixing.
[20:06] <soren> This is great.
[20:06] <soren> Well..
[20:06] <soren> Sort of.
[20:06] <soren> The thing is, every package in Ubuntu has dependencies of some sort.
[20:06] <soren> For instance, almost everything depends on libc
[20:07] <soren> This means that a change in libc will inevitably affect MySQL somehow.
[20:07] <soren> Luckily, if this causes problems, it is (hopefully) caught by MySQL's test suite.
[20:07] <soren> Less luckily, this test suite, as I just mentioned..
[20:07] <soren> is run when MySQL is uploaded..
[20:07] <soren> not when libc is uploaded.
[20:08] <soren> So we may not notice a problem until the next time someone uploads MySQL. This could be weeks or even months!
[20:08] <soren> And trying to narrow down the change that broke something is hard with all the stuff doing on in Ubuntu development over the course of months.
[20:08] <soren> So..
[20:09] <soren> to address this, we've set up and automated system that rebuilds MySQL ( and a bunch of other stuff) every night in a PPA.
[20:09] <soren> That way, if we trust the test suite, we can relax  and know that MySQL still works, despite any changes in its dependency chain.
[20:09] <soren> We do the same for libvirt, php5, postgresql, etc.
[20:10] <soren> Basically, anything that has a test suite that runs at build time and that causes the build to fail if it doesn't pass, should be added.
[20:10] <soren> This at least makes me sleep better :)
[20:11] <soren> So, the automated testing stuff in Lucid consists of two parts.
[20:11] <soren> The above is the first part, which is pretty nice.
[20:11] <soren> The second part is awesome:
[20:11] <soren> :)
[20:11] <soren> It's an automated ISO testing system.
[20:11] <soren> ISO testing is the thankless and tedious job of installing Ubuntu from an ISO over and over again..
[20:12] <soren> ..with small adjustmets each time to make sure things haven't changed unexpectedly.
[20:12] <soren> QUESTION: ~Shkodrani> why not run the test suite only when a packege on which, for instance MySQL relays on?
[20:13] <soren> The cost of checking whether something in MySQL's dependency chain has changed is rather high. At the very least, it's tedious.
[20:13] <soren> ..and just doing the rebuild is cheap and simple to get up and running.
[20:13] <soren> It's all run by a 10 line shell script or thereabouts.
[20:13] <soren> Ok, ISO testing..
[20:14] <soren> Every time we come close to an alpha, beta or any other kind of release..
[20:14] <soren> ..we all spend a lot of itme going through this install process.
[20:14] <soren> Well, we /should/ anyway. I positively suck at getting it done, but there you go.
[20:14] <soren> My fellow server team member, Mathias Gug, has had a preseed based setup running for a while now.
[20:15] <soren> Basically, preseeding is a way to answer all of the installer's questions up front.
[20:15] <soren> So, he takes all the answers..
[20:15] <soren> passes them to the install using clever hacks..
[20:15] <soren> ..and the install zips through the instlalation without bothering Mathias with questions.
[20:15] <soren> In the end, he can log into the installed system and run the las tparts of the test cases.
[20:16] <soren> This has served us well, and has probably saved us several man days (or weeks?) of testing tie over the last few years.
[20:16] <soren> However, it doesn't actually test the same things as the ISO test cases describe.
[20:16] <soren> The ISO test cases speak of the interaction between the user and the installer..
[20:16] <soren> However, the point of preseeding is to /avoid/ interaction, and to skip it entirely.
[20:16] <soren> Don't get me wrong..
[20:17] <soren> Preseed testing is super valuable.
[20:17] <soren> Installing that way is a supported install method, so having this well tested is wicked cool and really important.
[20:17] <soren> ...but I wanted to test the interactivity as well.
[20:18] <soren> So, being the virtualisation geek that I am..
[20:18] <soren> I decided to use the KVM autotest framework to do the ISO testing.
[20:18] <soren> Now, KVM autotest was designed to test KVM.
[20:19] <soren> KVM developers use it to install a bunch of different operating systems and test things to make sure they didn't change anything in KVM that broke functionality in one of the guest operating systems.
[20:19] <soren> What we want to do, though, is somewhat the opposite.
[20:19] <soren> We assume that KVM works and instead want to test the operating system.
[20:20] <soren> So, the KVM autotest framework works by runing a virtual machine..
[20:20] <soren> grabs a screenshot every second..
[20:20] <soren> ..and when the screenshot looks a particular way (e.g. when a particular dialog comes up),
[20:21] <soren> it can respond with a series of key presses or mouse events.
[20:21] <soren> This way, we can emulate a complete, interactive install session.
[20:21] <soren> Awesome stuff.
[20:21] <soren> I've started documenting this, but haven't gotten all that far, since I kept changing things faster than I could update the docs :)
[20:22] <soren> The documentation lives at  https://wiki.ubuntu.com/AutomatedISOTesting
[20:22] <soren> If you all open that page..
[20:22] <soren> ..and scroll down to the "step files" section..
[20:23] <soren> you can see a sample step from a "step file".
[20:23] <soren> A step file is a description of a test case.
[20:23] <soren> Now, looking at the sample, you can see a "step 9.45" and a "screendump" line.
[20:23] <soren> They're pretty much just meta-data for the creator or editor of the step file
[20:24] <soren> so don't worry about those.
[20:24] <soren> The important lines are the "barrier_2" and "key" ones.
[20:24] <soren> The barrier_2 line tells the testing system to wait..
[20:24] <soren> ..until the rectangle of size 117x34 of the screen, starting at 79x303..
[20:24] <soren> should have md5sum de7e18c10594ab288855a570dee7f159 within the next 47 seconds.
[20:25] <soren> If this doesn't happen, the test will fail, and a report will be generated.
[20:25] <soren> If it does pass, it goes on to the next step: "key ret"
[20:25] <soren> As you can probably guess, "key ret" sends a keypress to the guest, namely Return.
[20:26] <soren> The result of those two lines is: Wait for the language prompt right after boot to show up, and once it does, press return to accept the default "English".
[20:26] <soren> Now, pretty soon, it became obvious that there was going to be a lot of duplication involved here.
[20:26] <soren> ...all the installs would have to wait for that prompt and respond to it in the same way.
[20:27] <soren> Even worse: If that prompt were to change, /every/ step file would need to be updated.
[20:27] <soren> Even worse again: In the beginning there was no concept of "updating" step files. You had to start all over.
[20:28] <soren> Starting over makes plain old ISO testing feel like a fun time.
[20:28] <soren> It's not.
[20:28] <soren> Just so you know.
[20:28] <soren> I love people for doing it, but it's really not that much fun. :)
[20:28] <soren> Ok, so to address the mass duplication of steps and stuff, I added a step file generator.
[20:29] <soren> The step file generator generates a step file (you probably guessed this much) based on the task to be installed and the partitioning scheme to be used.
[20:30] <soren> This means that I can tell the test frame work: Hey, please test an install of the LAMP task, with LVM partitioning and do it on amd64.
[20:30] <soren> And it does so.
[20:30] <soren> See, this is all running in a virtual machines.
[20:30] <soren> Virtual machines are cool.
[20:30] <soren> So cool, in fact...
[20:30] <soren> That you can use them to make installer videos.
[20:30] <soren> So, to see what happens during a test run, you can attach a recorder thingie and turn the result into an avi.
[20:31] <soren> Now, like any decent TV chef, I've cheated and done this all in advance.
[20:31] <soren> Now, unlike most decent TV chef's, what I did in advance failed.
[20:31] <soren> And even more unlike TV chef's, I'm going to show it to you anyway, because it's useful.
[20:32] <soren> Without further ado:
[20:32] <soren> heh..
[20:32] <soren> wait for it..
[20:32] <soren> http://people.canonical.com/~soren/lamplvminstall.avi
[20:32] <soren> There we go.
[20:32] <soren> wget http://people.canonical.com/~soren/lamplvminstall.avi ; mplayer lamplvminstall.avi
[20:32] <soren> This test case failed.
[20:33] <soren> Somewhat surprisingly.
[20:33] <soren> If you fast forward all the way to the end..
[20:33] <soren> (watch the rest as well, it's fun to watch the test system typing the username "John W. Doe III" and the password and whatnot)
[20:34] <soren> ..at the end, you'll see if breaks off before the install actually finishes.
[20:34] <soren> Like... seconds before it would have finished.
[20:34] <soren> Honestly, I did not mean for this to happen, but it's a good learning experience :)
[20:34] <soren> Ok, if we all look at..
[20:34]  * soren digs through launchpad, bear with me.
[20:34] <soren> http://bazaar.launchpad.net/~soren/autotest/automated-ubuntu-server-tests/files/head:/client/tests/kvm/generator_data/lucid/
[20:35] <soren> Those are the input files for the step file generator.
[20:35] <soren> Yes, they are poorly named, but please appreciate that just days ago, they were all named "foo", "bar", "wibble", "wobble", etc. so this is a massive improvement.
[20:36] <soren> QUESTION: That method could be used for UI testing in a *lot* of different GUI apps, not just ISO installations. Any plans to  document/release it more generally?
[20:36] <soren> (from rmunn)
[20:36] <soren> Yes1
[20:36] <soren> !
[20:36] <soren> I meant to get that done for today, but the real world imposed and made a mockery of my plans.
[20:36] <soren> This can totally be used to do GUI installs as well.
[20:37] <soren> Looking at http://bazaar.launchpad.net/~soren/autotest/automated-ubuntu-server-tests/files/head:/client/tests/kvm/generator_data/lucid/ again..
[20:37] <soren> Specifically, 060-finish_install_and_reboot.steps
[20:37] <soren> http://bazaar.launchpad.net/~soren/autotest/automated-ubuntu-server-tests/annotate/head:/client/tests/kvm/generator_data/lucid/060-finish_install_and_reboot.steps
[20:38] <soren> This is the step that failed.
[20:38] <soren> For some reason (that I have yet to figure out, I only spotted this failure an hour ago) this times out.
[20:38] <soren> It says 579, but perhaps those a special kind of seconds that are not as long as most people's seconds.
[20:39] <soren> The point is this: I only have to change the timeout in this one place, and all the test cases will be updated.
[20:39] <soren> < ~rmunn> QUESTION: I see a lot of keystrokes used to select various dialog widgets. Can the KVM testing system simulate mouse clicks and/or mouse
[20:39] <soren>                    movements (e.g., for testing mouseover stuff) as well?
[20:39] <soren> cut'n'paste for the lose :(
[20:39] <soren> Well..
[20:39] <soren> Yes.
[20:39] <soren> Sort of :)
[20:40] <soren> The autotest framework supports it, I've added support for it to the frontend, but kvm has an.. um.. issue :)
[20:40] <soren> It used to emulate a mouse, so it would move the cursor relative to the current position.
[20:40] <soren> However, these days, GNOME and such give you...
[20:40] <soren> mouse acceleration!
[20:40] <soren> Yay!
[20:40] <soren> No. Not yay.
[20:41] <soren> Mouse acceleration is the enemy when you're actually warping the mouse from one place to another, because it thinks you just moved your mouse /really/ fast, and then moves it even further than you wanted it to.
[20:41] <soren> This took me /forever/ to realise.
[20:41] <soren> So, I've made it pretend to use a tablet.
[20:41] <soren> Tablets offer absolute positioning, so this helped a lot.
[20:42] <soren> However, the command to tell kvm to click on something internally translated into "mouse_event(click_button1, 0, 0, 0)", where 0,0,0 are the coordinates.
[20:42] <soren> Now, if you're in relative positioning mode (using a regular mouse), this is good.
[20:42] <soren> You want to click right where you are.
[20:42] <soren> ..if you're using a tablet, it means you can only click in the top left corner.
[20:42] <soren> No fun.
[20:43] <soren> I wrote a patch for that, but I'm not sure it's in upstream KVM yet, but it'll be in Lucid half an hour after I start working on those GUI test cases :)
[20:44] <soren> So, yes, GUI testing is totally an optoin.
[20:44] <soren> option, too.
[20:44] <soren> Another problem I had with this is that it was designed to test a variable kvm against a static set of OS's.
[20:45] <soren> The OS's should look and act the same regardless of what changed in KVM. That is the whole point of these tests: To make sure they don't change.
[20:45] <soren> However, we change the OS all the time. That's what we do :)
[20:46] <soren> ..but since the designers of this test system never meant for it to be used this way, they didn't add an option to edit these step files very conveniently.
[20:46] <soren> To fix this, I've added an option to the test system to fall back to the stepmaker (the GUI used to create step files) if a test fails.
[20:46] <soren> This is great if you're running tests on your laptop or a machine you have direct access to rather than a machine running in a dusty corner of a data center.
[20:47] <soren> It really comes in useful when the screens change (wording changes, extra/fewer dialogs, change of theme (in the GUI)).
[20:47] <soren> Having to start over is, as I mentioned, no fun at all.
[20:48] <soren> Please shoot any questions you may have. I haven't really prepared much more than this.
[20:48] <soren> Still, questions belong in #ubuntu-classroom-chat
[20:50] <soren> If there are no more questions, I'll sing for the rest of the time slot.
[20:50] <soren> 21:50:25 < ~Omahn23> soren: QUESTION As an end user/sysadmin, is there anything I can do to help in testing with this new framework?
[20:51] <soren> Well, seeing as these things run in virtual machines, running them in more places is not going to make much difference, so /running/ the tests is probably not something we need help with
[20:51] <soren> However!
[20:51] <soren> The more test cases we can include, the better.
[20:51] <soren> The more, the merrier.
[20:51] <soren> I'd love to have more test cases to include in our daily runs of this system.
[20:52] <soren> 21:52:01 < hggdh> QUESTION: so we can automate pseudo-interactive testing. How to deal with the tests that require meat between the keyboard and the chair?
[20:52] <soren> Examples?
[20:52] <soren> 21:50:12 < Ramonster> soren: Any thoughts on testing servers while they actually perform one of the roles you talked about at the start ?
[20:52] <soren> Ramonster: You mean functional testing of e.g. a LAMP server?
[20:53] <soren> 21:52:23 < mscahill> QUESTION: you briefly mentioned PPA testing. what packages are included in this testing?
[20:53]  * soren looks that up.
[20:53] <soren> 21:53:08 < Ramonster> soren: Yeah
[20:53] <soren> alright.
[20:53] <soren> Um, yes, but it's not part of this work I've been doing.
[20:53] <soren> We're not very strong in that area at all.
[20:53] <soren> ...and that's a shame.
[20:54] <soren> PKGS="libvirt postgresql-8.3 postgresql-8.4 mysql-dfsg-5.0 mysql-dfsg-5.1 openldap php5 python2.6 atlas"
[20:54] <soren> Is the list of packages built daily.
[20:55] <soren> Well, the security team has a bunch of tests they run whenever they change anything. They often can't rely on anyone else to test anything (since they don't go through -proposed), so they need to be really thorough.
[20:55] <soren> I'm working on getting those run every day as well. They should provide some amount of functional testing.
[20:55] <soren> 21:53:12 < yltsrc> QUESTION: is writing test cases required for bugfixing?
[20:55] <soren> Not per se.
[20:56] <soren> Most test cases need updating once a bug is fixed, and most things I can think of would be covered by this, so new test cases (for this system, I mean) wouldn't be a requirement for bug fixes.
[20:57] <soren> 21:54:55 < mscahill> QUESTION: are there plans to allow automated testing for package maintainers with their own PPA?
[20:57] <soren> Sure, anyone is free to run that script and do their own testing.
[20:57] <soren> Hm... I may not have published it anywhere.
[20:57]  * soren fixes that.
[20:57] <soren> Well, /me makes a note to fix that
[20:58] <soren> I do have a few ideas for doing functional testing of upgrades of various sort, but most of those ideas are only a few hours old, so they're not even half baked yet :)
[20:59] <soren> Did I miss any questions?
[20:59] <soren> 21:59:33 < Ramonster> soren: That's the problem atm everyone is walking around with these half-baked ideas :)
[20:59] <soren> Whoops, didn't mean to post that here :)
[21:00] <soren> Thanks for showing up, everyone.
[21:00] <soren> that's it!