[03:35] <karna1> hmm
[03:45] <Guest93940> hi
[03:45] <karna1> hi
[03:46] <Guest93940> hi
[03:46] <Guest93940> hi
[03:46] <Guest93940> hi
[03:50] <jmarsden> There is no class now.
[03:50] <jmarsden> !classroom
[03:50] <ubot2`> The Ubuntu Classroom is a project which aims to tutor users about Ubuntu, Kubuntu and Xubuntu through biweekly sessions in #ubuntu-classroom - For more information visit https://wiki.ubuntu.com/Classroom
[11:17] <Test1> Ciao
[11:42] <noel__> hello
[12:12] <noel__> when does the class start?
[13:18] <iyory> hii
[13:22] <Isti_> hello
[14:47] <mitya57> WHOIS raju1
[15:57] <dpm> is everyone ready for another day of cool app developer sessions?
[15:57] <dpm> day 2 of ubuntu app developer week is about to start!
[15:58] <Andy80> yeeeeeaaahh
[15:58] <dpm> :)
[15:59] <nigelb> There's a change in schedule. Today's first talk will be by dpm :)
[16:00] <dpm> ok, let's wait for Classbot to kick off and then get started
[16:00] <dpm> oh, there it is... :)
[16:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/06/%23ubuntu-classroom.html following the conclusion of the session.
[16:01] <dpm> allright, let's roll
[16:01] <dpm> Welcome to this session on setting up your project for translations in Launchpad
[16:02] <dpm> My name is David Planella I work as the Ubuntu Translations Coordinator in the Community team at Canonical,
[16:02] <dpm> where I work with our translations community to bring you a localized Operating System.
[16:03] <dpm> I also tend to help with any topics related to translations and Launchpad, and that's what we're going to talk about today :)
[16:03] <dpm> That's a really exciting topic to me, as Launchpad makes it really easy to make your applications translatable and available to everyone in almost any language, and I hope you enjoy it as much as I do.
[16:03] <dpm> Translators are really awesome people!
[16:04] <dpm> I'll leave some time for questions at the end, but feel free to ask them throughout the session
[16:05] <dpm> Anyway, let's get started, shall we?
[16:05] <dpm> Assumptions
[16:05] <dpm> -----------
[16:05] <dpm>  
[16:05] <dpm> I will start with an application ready set up for translations, so I'm not going to go into much detail there.
[16:06] <dpm> (I'll take questions, though, if there are any)
[16:06] <dpm> My intention is to focus in getting you started with exposing your project's translations to everyone for translation.
[16:06] <dpm> We're going to be using these tools:
[16:07] <dpm>     bzr
[16:07] <dpm>     quickly
[16:07] <dpm>     python-distutils-extra
[16:07] <dpm> In particular quickly, which we'll use to start with a nearly ready-made project with translations set up
[16:08] <dpm> (You can install it by running the 'sudo apt-get install quickly' command or you can get it from the Ubuntu Software Centre)
[16:08] <dpm>  
[16:08] <dpm> Creating the project and setting it up for translations
[16:08] <dpm> -------------------------------------------------------
[16:08] <dpm>  
[16:08] <dpm> We'll use quickly to create a project called 'fooby', and then we'll set up the last touches needed to configure translations.
[16:09] <dpm> As I said, we won't go into the detail of setting up the application for translation, as quickly will do the heavy lifting for you,
[16:09] <dpm> but here's a high level overview of what needs to be done to add internationalization support to an app, in case you need to do it outside of quickly:
[16:10] <dpm> Generic Steps to Internationalize an Application
[16:10] <dpm> [16:10] <dpm>  
[16:11] <dpm> * Integrate gettext (http://www.gnu.org/s/gettext/) into the application. Initialize gettext in your main function
[16:11] <dpm> * Integrate gettext into the build system. There are generally gettext rules in the most common build systems. Use them.
[16:12] <dpm> * Mark translatable messages. Use the _() gettext call to mark all translatable messages in your application
[16:12] <dpm> * Care for your translation community. Not necessarily a step related to adding i18n support, but you'll want an active and healthy translation community around your project. Keep the templates with translatable messages up to date. Announce these updates and give translators time to do their work before a release. Be responsive to feedback.
[16:12] <dpm> anyway, going back to the subject
[16:13] <dpm> So if you've got all those tools installed, you can simply fire up a terminal window (Ctrl + Alt + T) and run the following command:
[16:13] <dpm>     quickly create ubuntu-application fooby
[16:13] <dpm> This will create an application named 'fooby'
[16:13] <dpm> and give you some information about it on the first run
[16:14] <dpm> then change to the fooby folder:
[16:14] <dpm>     cd fooby
[16:14] <dpm> And finally run:
[16:14] <dpm>     python setup.py build_i18n
[16:15] <dpm> That should have finished the last bits to set up translations, so that you can already link up your application with Launchpad Translations
[16:16] <dpm> in particular, what that last command did was to created the po folder in your project, to contain what it's called the translations template and the translations files themselves
[16:16] <dpm> you can see the template there by running:
[16:16] <dpm>     ls po
[16:16] <dpm> have a look at it:
[16:16] <dpm>     gedit po/fooby.pot
[16:17] <dpm> It's important to get a bit familiar with it, but you don't have to remember the whole format
[16:17] <dpm> you should simply know what it is for now :)
[16:17] <dpm> and that Launchpad needs it to be in your project
[16:18] <dpm> A few bits and pieces on translation templates:
[16:18] <dpm>  * Gettext: They follow the gettext format: http://is.gd/fC8p6
[16:19] <dpm>  * Name: They are generally named after your project, with a .pot extension. E.g. fooby.pot
[16:19] <dpm>  * One template per app: Generally applications need only one template
[16:19] <dpm>  * Layout: They generally live in the po/ folder, along with the translations
[16:19] <dpm>  * Content: They are text files which contain:
[16:19] <dpm>     * A header with metadata
[16:20] <dpm>     * A set of message pairs: msgid are the original strings extracted from the code and exposed to translators, and msgstr are the placeholders for the translations, which are always empty in the templates.
[16:20] <dpm>  * Launchpad import: They are imported into Launchpad and exposed for translations for all languages in https://translations.launchpad.net/$YOUR_PROJECT
[16:20] <dpm>  * Updates: You update the template whenever you have new strings in your app and you think they are stable for translation (generally shortly before release)
[16:21] <dpm>  * Tools: you update templates with gettext based tools:
[16:21] <dpm>     * generally intltool -> 'cd po && intltool-update -p'
[16:21] <dpm>     * or increasingly python-distutils-extra for python projects -> 'python setup.py build_i18n -p'
[16:22] <dpm> You don't have to remember all of this
[16:22] <dpm> But hopefully these points will give you some insight on translation templates
[16:22] <dpm> At least you should know how that you must update the template from time to time
[16:23] <dpm> and the command to do it
[16:23] <dpm> Repeat it with me - "I _will_ update the translation from time to time, at least once before a release"
[16:23] <dpm> :-)
[16:24] <dpm> You'll see that your project still does not contain any translations, but again, let me give you a quick overview on translations, so you know what we're talking about:
[16:24] <dpm> So here we go, a few words on translations:
[16:26] <dpm>  * Template-based: They are created from the template and share the same gettext format
[16:26] <dpm>  * Name: They are named after the $CODE.po scheme, where $CODE is an ISO 639-2 code. E.g. ca.po for Catalan, de.po for German. Some have an optional country specifier. E.g. pt_BR.po (Portuguese from Brazil)
[16:27] <dpm>  * Layout: they are all in the same directory as the POT template. So:
[16:27] <dpm>     * po/fooby.pot
[16:27] <dpm>     * po/ca.po
[16:27] <dpm>     * po/pt_BR.po
[16:27] <dpm>     * ...
[16:27] <dpm>  * Creation: Launchpad creates them for you the minute someone translates the first message online
[16:27] <dpm>  * Code integration: you can let Launchpad commit them to a branch of your choice or you can export a tarball containing them all (more on that later)
[16:28] <dpm> Anyway, let's continue. Now that you've added the template to your code, you can commit it by running the following commands:
[16:28] <dpm>     bzr add po
[16:28] <dpm>     bzr commit -m 'Created my first ever awesome .pot template. Go translators, go!'
[16:29] <dpm> And let's publish it in Launchpad (note that you'll have to change the Launchpad URL to your user name instead of 'dpm'):
[16:29] <dpm>     bzr push lp:~dpm/fooby/translations
[16:29] <dpm> Nothing particularly hard to understand on the naming scheme above: dpm is my user name, fooby is the project and translations is the bzr branch name in Launchpad
[16:29] <dpm> Ok, so that completed the first step!
[16:29] <dpm> Next:
[16:30] <dpm> ah, forgot to ask, any questions so far?
[16:30] <ClassBot> Andy80 asked: what about Qt application? They don't use gettext. They have their own method to be translatable (basically it's just a matter of tr("This is a message") ) and I noticed that in Unity-2D we're using a sort of macro. Why don't we improve the launchpad integration even for Qt applications?
[16:30] <dpm> good question
[16:31] <dpm> as Unity 2D is an Ubuntu project, it has to integrate well with Launchpad and the way Ubuntu translators translate, which is again Launchpad Translations
[16:32] <dpm> in short, in the Unity 2D project there is some code that intercepts the Qt tr() calls and converts them to gettext() calls
[16:33] <dpm> so effectively Unity 2D, despite being a Qt project, uses gettext for translations
[16:33] <dpm> I agree that it'd be nice for Launchpad to support the Qt format
[16:33] <dpm> but as you see, you can easily use gettext from Qt-based apps too
[16:34] <dpm> Ok, let's continue
[16:34] <dpm> Setting up code hosting
[16:34] <dpm> -----------------------
[16:34] <dpm>  
[16:34] <dpm> We want our project to be available to everyone to translate, so we'll need to publish it in Launchpad first.
[16:34] <dpm> That's beyond the scope of this session, so we'll continue from the already registered fooby project in Launchpad:
[16:34] <dpm>     https://code.launchpad.net/fooby
[16:35] <dpm> In case you are interested, though, registering a new project in Launchpad is as easy as going to https://launchpad.net/projects/+new
[16:35] <dpm> Some of the URLs I'll post to set up your project will not allow you to open some of the pages due to permissions, so if you have your own project in Launchpad, just substitute the 'fooby' part in the URL with your project's Launchpad id
[16:36] <dpm> The first thing we'll have to do in our project is registering a bzr branch,
[16:36] <dpm> so we'll simply go to the Code tab in Launchpad, choose the "Configure code hosting" link
[16:36] <dpm> and then on the "Link to a Bazaar branch already on Launchpad" you can enter the branch we published earlier on (~dpm/fooby/translations)
[16:36] <dpm> A shortcut is to simply go to:
[16:36] <dpm> https://code.launchpad.net/fooby/trunk/+setbranch
[16:36] <dpm> to do this
[16:37] <dpm> So now we have all we need to start setting up translations.
[16:37] <dpm> You see that all components in Launchpad are integrated, so you set up a branch to be linked to translations
[16:37] <dpm> Just as a recap, you can see and explore the resulting code from here:
[16:37] <dpm>     https://code.launchpad.net/fooby
[16:37] <dpm> Feel free to browse it (http://bazaar.launchpad.net/~dpm/fooby/translations/files)
[16:37] <dpm> or download it (bzr branch lp:fooby) and play with it
[16:38] <dpm> Ok, so code hosting setup: (./) Finished!
[16:38] <dpm>  
[16:38] <dpm> Setting up translations in Launchpad
[16:38] <dpm> ------------------------------------
[16:38] <dpm>  
[16:38] <dpm> Now we come to the most interesting part
[16:38] <dpm> Let's divide this in 4 steps
[16:38] <dpm> 1. Telling Launchpad where translations are hosted
[16:38] <dpm> The first step it to tell Launchpad that we want to host translations there.
[16:39] <dpm> On your Launchpad's project, just click on the Translations tab, or go to this URL:
[16:39] <dpm> (remember to change 'fooby' to your project's name!)
[16:39] <dpm>     https://translations.launchpad.net/fooby/+configure-translations
[16:39] <dpm> Then choose the "Launchpad" option to tell Launchpad translations will be done there, and click on "Change"
[16:39] <dpm> That was an easy one, wasn't it?
[16:39] <dpm> 2. Configuring permissions
[16:39] <dpm> Now we are going to tell Launchpad how we want our translations permissions to be (i.e. who and how can translate it),
[16:40] <dpm> and which branch translators should focus on.
[16:40] <dpm> Simply go to the Translations tab again and click on the "Change permissions link"
[16:40] <dpm> Or here's the direct link: https://translations.launchpad.net/fooby/+settings :)
[16:40] <dpm> I recommend the following setup:
[16:40] <dpm>     Translations group: Launchpad Translators
[16:40] <dpm>     Translations permissions policy: Structured
[16:40] <dpm>     Translation focus: trunk (or choose your branch here)
[16:40] <dpm> Assigning the translations to a translation group will make sure a team for each language will review translations before they are submitted, ensuring the quality of translations
[16:41] <dpm> A translations group is simply a set of teams, one per language, that takes care of translations in that language
[16:41] <dpm> They can be specific to a project or generic.
[16:41] <dpm> I recommend the Launchpad Translators group because it contains a set of already established and experienced teams:
[16:41] <dpm> https://translations.launchpad.net/+groups/launchpad-translators
[16:41] <dpm> as per the Structured policy
[16:42] <dpm> it gives you a good balance between openness and quality control:
[16:42] <dpm> only the team members of an established team will be able to translate your project
[16:42] <dpm> And for languages without a team it will allow everyone to translate, facilitating the barrier of entry to translators at the expense of QA
[16:42] <dpm> The other ends of the permissions spectrum are Open or Restricted
[16:42] <dpm> You can learn more about these here:
[16:42] <dpm>     https://help.launchpad.net/Translations/YourProject/PermissionPolicies
[16:43] <dpm> It's the project maintainer's call, but I personally discourage them to use Open
[16:43] <dpm> Ok, we're nearly there, next step:
[16:43] <dpm> 3. Setting up what needs to be translated
[16:43] <dpm> You need to also tell Launchpad what needs to be translated. That's again quite easy. On the Translations tab again, choose the trunk series and specify your branch there
[16:43] <dpm> Direct link: https://launchpad.net/fooby/trunk/+linkbranch
[16:43] <dpm> Another easy one done :)
[16:44] <dpm> 4. Configuring imports and exports
[16:44] <dpm> That's for me the most interesting bit
[16:44] <dpm> The settings on this section basically enable Launchpad to do the work of managing translations for you
[16:44] <dpm> You can tell Launchpad to import your translation templates automatically whenever you do a commit in your branch
[16:44] <dpm> So you don't have to upload them manually
[16:44] <dpm> If you are migrating a project with existing translations, you can tell it to import them too
[16:44] <dpm> And finally, you can let Launchpad commit translations automatically to a branch of your choice
[16:45] <dpm> I find that just awesome
[16:45] <dpm> So for the imports, on the Launchpad page, on the "Import translations from branch" section:
[16:45] <dpm> I recommend choosing "Import template files" and then "Save settings"
[16:45] <dpm> For exports: look at the "Export translations to branch" section and then click on the  "Choose exports branch" link
[16:45] <dpm> So that was it!
[16:46] <dpm> 4 easy steps that should not take you more than a few minutes to set up, and your app is ready for the world to translate!
[16:46] <dpm> Just a few final words:
[16:46] <dpm> Play with translations
[16:46] <dpm> ----------------------
[16:46] <dpm> As a developer, it might be interesting to see how translators do their work.
[16:46] <dpm> Exceptionally for this project (remember how I advised not to use Open permissions, tough :) I've set the translations permissions on the fooby project to Open
[16:47] <dpm> So you can submit translations online
[16:47] <dpm> and get a feel for the work that translators do
[16:47] <dpm> As a developer, it will give you an understanding on how they work. It is always interesting to get to know other workflows
[16:47] <dpm> and it's always good to have an insight on all areas of contribution related to your project
[16:47] <dpm> You can start translating fooby here:
[16:47] <dpm> 	https://translations.launchpad.net/fooby
[16:48] <dpm> So that was it really, it wasn't that hard, was it?
[16:48] <dpm> Let me give you a quick summary of what we've talked about and then take questions
[16:48] <dpm> Summary
[16:48] <dpm> -------
[16:49] <dpm> Most of the steps described here today you'll only need to do once, unless you need to change the settings. They were:
[16:49] <dpm>  1. Setting up code hosting (in case you hadn't already)
[16:49] <dpm>  2. Setting up translations in Launchpad
[16:49] <dpm>     2.1. Telling Launchpad that it's hosting your translations (https://translations.launchpad.net/fooby/+configure-translations)
[16:49] <dpm>     2.2. Configuring permissions: recommended -> Structured, Launchpad Translators (https://translations.launchpad.net/fooby/+settings)
[16:49] <dpm>     2.3. Setting up the translations branch (https://launchpad.net/fooby/trunk/+linkbranch)
[16:49] <dpm>     2.4. Configuring imports and exports (https://translations.launchpad.net/fooby/trunk/+translations-settings)
[16:49] <dpm> So really, once your project is set up for translation, the only things you'll have to remember are:
[16:49] <dpm>   to update the template before a release,
[16:50] <dpm>   announce to translators that they can start their work,
[16:50] <dpm>   and merge the translations to your main branch.
[16:50] <dpm> If you are using the same branch for translation imports and exports, you won't even have to do that!
[16:50] <ClassBot> There are 10 minutes remaining in the current session.
[16:50] <dpm> ok, so we've got 10 minutes left - if you've got any questions, bring them on! :)
[16:50] <ClassBot> jsjgruber_natty_ asked: ​ How can an application bring up a translation for a particular local "on-demand"? Now get the spanish version, now french version?
[16:51] <dpm> I'm guessing you're asking this for test purposes
[16:52] <dpm> in normal usage, the application will automatically load the translation for the right locale defined in the system
[16:52] <dpm> so if my desktop's language is set to Catalan, the app, assuming gettext has been correctly initialised in the code, will automatically load the Catalan translation
[16:53] <dpm> but if you want an app to load another language, you can call the app on the command line specifying the language code, e.g.
[16:53] <dpm> $ LANGUAGE=de myapp
[16:54] <dpm> Running that command would load the German translation of myapp ('de' is the ISO code for German)
[16:54] <dpm> other questions?
[16:55] <ClassBot> matteonardi asked: how does translations get into users machines? Is there 1 (and only 1) package for each language? What if my application comes from a ppa?
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:56] <dpm> translations get distributed and installed along with the application. On the technical level, translations are .mo files, one for each available translation in your app
[16:56] <dpm> It does not matter if your application comes from a PPA
[16:57] <dpm> the PPA will contain all the necessary .mo files, which means the translations will be installed on the system of everyone who installs the PPA
[16:57] <dpm> ok, 3 minutes left, I can probably take another one if there is any
[16:58] <dpm> ok, if there aren't any, the only thing remaining is to thank everyone for listening in and asking interesting questions, and I'll see you next time!
[17:00] <dpm> Next up is Kaleo, the man behind Unity 2D, who'll tell you all about how this awesome piece of software was put together
[17:00] <dpm> Kaleo, as soon as the Classbot kicks in with the intro, the floor is yours!
[17:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/06/%23ubuntu-classroom.html following the conclusion of the session.
[17:00] <Kaleo> dpm: thank you David
[17:01] <Kaleo> dpm: thank you everyone for joining this session
[17:01] <Kaleo> dpm: My name is Florian Boucault
[17:01] <Kaleo> dpm: and I am one of the software developers behind Unity 2D
[17:02] <Kaleo> dpm: I would like that session to be as interactive as you guys would like
[17:02] <Kaleo> dpm: so don't hesistate to ask any question at any time
[17:02] <Kaleo> (and I'll drop the dpm :))
[17:02] <Kaleo> Unity 2D is essentially an implementation of the Unity user interface using Qt and QML
[17:03] <Kaleo> it reuses the same backend technologies used in Unity 3D
[17:03] <Kaleo> and intends to provide a UI that matches Unity 3D
[17:03] <Kaleo> the main goal of Unity 2D is to run on platforms that do not provide accelerated OpenGL
[17:04] <Kaleo> it also simplifies the development of the shell UI quite a bit
[17:04] <Kaleo> it is made up of 4 UI components
[17:04] <Kaleo> 3 of which you can see on the following diagram:
[17:04] <Kaleo> http://people.canonical.com/~kaleo/classroom/unity_2d_wireframe.png
[17:05] <Kaleo> - the app launcher on the left
[17:05] <Kaleo> - the top panel with the application menu and the indicators
[17:05] <Kaleo> - the dash that is a UI to essentially search for content
[17:05] <Kaleo> - and the one not in the diagram, the workspace switcher
[17:06] <Kaleo> the workspace switcher allows user to switch between workspace, applications and windows
[17:06] <Kaleo> right now these 4 components are separate programs that are displayed on top of every other windows
[17:07] <Kaleo> they are written with QML
[17:07] <Kaleo> and use APIs defined in C++/QObjects in a common library called libunity-2d-private
[17:08] <Kaleo> a lot of these APIs just wrap other libraries, such as wnck, bamf, dee, etc.
[17:08] <Kaleo> and made these functionalities easily accessible to QML uis
[17:08] <Kaleo> I can go into the details of what each library provides us with
[17:09] <Kaleo> if anybody has questions about that
[17:09] <Kaleo> these 4 components are fairly window manager agnostic
[17:09] <Kaleo> today Unity 2D ships with Metacity
[17:09] <Kaleo> but it should work equally well with others: compiz, kwin, xfwm..
[17:11] <Kaleo> historically Unity 2D's development started last year towards the end of the summer
[17:11] <Kaleo> and grew into being the default interface for ARM based Ubuntu isos
[17:11] <Kaleo> development happens on Launchpad
[17:12] <Kaleo> getting started for developers is straightforward
[17:12] <Kaleo> and documented https://wiki.ubuntu.com/Unity2D
[17:12] <Kaleo> at*
[17:12] <Kaleo> each component (dash, launcher, etc.) has a separate directory in the source tree
[17:13] <Kaleo> and can be hacked on independently
[17:13] <Kaleo> the policy for trunk is that it has to be releasable at any point;
[17:13] <Kaleo> that means, no regression when introducing no features and only landing features that are ready
[17:14] <Kaleo> automated builds are produced every day
[17:14] <Kaleo> and released into a PPA: https://launchpad.net/~unity-2d-team/+archive/unity-2d-daily
[17:16] <Kaleo> (connection issues here)
[17:17] <Kaleo> for developers who want to play around with it (or fix bugs)
[17:17] <Kaleo> the required knowledge to get on the project is:
[17:17] <Kaleo> - QML and Javascript for the UI pieces
[17:18] <Kaleo> - C++ if you want to add features that require new data that our backend does not provide
[17:18] <Kaleo> one thing to remember is that we try to keep the list of features between Unity 2D and 3D to be synchronised
[17:19] <Kaleo> so if you have an idea about the UI, don't forget that it needs to be done in both
[17:20] <Kaleo> I think that's enough for the general presentation.
[17:20] <Kaleo> Do you guys have any specific question?
[17:20] <Kaleo> let me take Andy80's :)
[17:21] <Kaleo> Andy80: we have a wrapper for indicators as well
[17:21] <Kaleo> Andy80: it's a C++/Qt API that calls the API of the unity-panel-service
[17:21] <Kaleo> Andy80: and essentially gives us a list of indicators to render
[17:22] <ClassBot> Andy80 asked: do we have a wrapper for indicators too or are we just calling the original methods?
[17:22] <Kaleo> (thanks ClassBot)
[17:24] <Kaleo> anybody else? :)
[17:24] <ClassBot> dpm asked: which libraries should an app developer wanting to interface his/her app with Unity 2D should know about?
[17:25] <Kaleo> so, dpm, the integration into Unity 2D is the same as the integration into Unity 3D
[17:25] <Kaleo> once you have done it for one you have done it for both
[17:25] <Kaleo> the libraries concretely are libunity
[17:26] <Kaleo> you can integrate with the launcher with that
[17:26] <Kaleo> you can also create a lens to add content to the dash (for example the Gwibber lens)
[17:26] <Kaleo> finally you can also integrate with the top panel's indicators
[17:26] <Kaleo> the way Banshee is integrated for example
[17:27] <Kaleo> in the sound menu
[17:27] <Kaleo> does that answer the question?
[17:28] <ClassBot> mohammedalieng asked: are there any plans to provide desktop gadgets, specially it is the default interface for ARM devices ?
[17:28] <Kaleo> mohammedalieng: there are no concrete plans so far for desktop gadgets
[17:29] <Kaleo> mohammedalieng: right now if one needs them I would personally recommend to use KDE's "gadgets"
[17:29] <Kaleo> that is the Plasma ones
[17:30] <Kaleo> it fits well technology wise with Unity 2D as it uses QML as well
[17:30] <ClassBot> Andy80 asked: if I correctly understand, Unity-2D must have the same features of Unity but without the 3D effects that would not be possible on PC without a 3D graphic card. But we know that QML is used even on hardware with 3D acceleration to have very nice effects too (look for example Harmattan running on Nokia N9). Would not be better to develop just Unity-2D + Unity-effects insted of duplicating the work having to develo
[17:31] <Kaleo> Andy80: I essentially agree with that
[17:31] <Kaleo> to add on that on a technical level
[17:31] <Kaleo> the visual possibilities of QML today are pretty advanced
[17:31] <Kaleo> especially on the effects side
[17:31] <Kaleo> the only limitation today is on the 3D side of things
[17:32] <Kaleo> only rudimentary 3D is available
[17:32] <Kaleo> which is a gap that can be closed with Qt Quick 3D
[17:32] <Kaleo> I have experiments of integrating 3D objects and scenes into the launcher and the dash
[17:32] <Kaleo> it works fairly well
[17:33] <Kaleo> on the performance side, we are already pretty good with the rendering engine we enforce the use of, raster
[17:33] <Kaleo> Unity 2D also works with the OpenGL2 engine
[17:33] <Kaleo> and we are quite looking forward to migrating to QML2
[17:33] <Kaleo> that will provide very nice performance improvements
[17:34] <Kaleo> by adding a better rendering model when it comes to OpenGL and modern GPUs
[17:35] <Kaleo> the important thing to remember here is that:
[17:35] <Kaleo> 1) we are not limited by QML UI-wise (we can use Qt Quick 3D or even write our own OpenGL based QML ui elements)
[17:36] <Kaleo> 2) the QML code we write today for QML1 will work in the future without changes with QML2 and QML3D
[17:36] <Kaleo> Andy80: does that answer the question?
[17:37] <Kaleo> Andy80 asks: "what are we waiting for?"
[17:37] <Kaleo> we are waiting for you :)
[17:38] <Kaleo> there is quite a lot of invisible work happening in Unity 2D
[17:38] <Kaleo> that takes quite a bit of our attention
[17:38] <Kaleo> (we are just 3 developers today)
[17:38] <Kaleo> for example, supporting multi monitor properly
[17:38] <Kaleo> right-to-left languages
[17:39] <Kaleo> languages that need special input methods
[17:39] <Kaleo> fixing important bugs :)
[17:40] <Kaleo> so, developers are of course always available
[17:40] <Kaleo> on freenode #ayatana
[17:40] <Kaleo> and for those lucky ones going to UDS
[17:40] <Kaleo> they will be happy to spend time with those interested
[17:41] <Kaleo> we will have a session as well planning for Ubuntu P
[17:41] <ClassBot> dpm asked: what are the issues with right-to-left languages? Is it a matter of QML not supporting them well?
[17:41] <Kaleo> dpm: the issue was indeed that QML was not supporting them well
[17:41] <Kaleo> dpm: so, we had a first shot at it working around that limitation
[17:42] <Kaleo> but now Qt 4.7.4 is out with Qt Quick 1.1 that supports natively RTL languages
[17:42] <Kaleo> so we are mostly in the clear now
[17:42] <Kaleo> in Oneiric we will support them decently
[17:42] <Kaleo> another example of invisible work is accessibility support
[17:43] <Kaleo> critical for us as Unity 2D is becoming the default desktop on Ubuntu Oneiric where Unity 3D cannot run
[17:43] <Kaleo> I like to see Unity 2D as the universal version:
[17:43] <Kaleo> - works everywhere
[17:44] <Kaleo> - works for everybody
[17:44] <Kaleo> (all machines, all cultures, all needs)
[17:44] <Kaleo> that's being a bit idealistic of course :)
[17:44] <Kaleo> thanks for the question dpm
[17:47] <ClassBot> rsajdok asked: Is there the list of new feature which will be added to Unity-2d in future?
[17:48] <Kaleo> rsajdok: so, the first set of features we want to add are the ones that are in Unity 3D but not in 2D yet because we have not had time to do them
[17:48] <Kaleo> rsajdok: https://bugs.launchpad.net/unity-2d/+bugs?field.tag=delta-with-3d
[17:49] <Kaleo> rsajdok: and of course the wish list items https://bugs.launchpad.net/unity-2d/+bugs?search=Search&field.importance=Wishlist&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
[17:49] <Kaleo> for those who want to start easy to learn how it works inside and implement something not too difficult
[17:49] <Kaleo> we use the bitesize tag
[17:50] <Kaleo> https://bugs.launchpad.net/unity-2d/+bugs?field.tag=bitesize
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:51] <Kaleo> thanks ClassBot
[17:53] <Kaleo> alright folks, just a few minutes for more questions
[17:54] <ClassBot> Andy80 asked: are you aware if any other distro is interested in Unity/Unity-2d? This could bring more contributions to the project
[17:55] <Kaleo> Andy80: I know somebody contacted us to package it up in OpenSuse
[17:55] <Kaleo> but that's the extent of my knowledge
[17:55] <ClassBot> rsajdok asked: Are there bugs in pure javascript?
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[17:56] <Kaleo> rsajdok: yes, it happens often that the issues can be fixed with a bit of QML + javascript
[17:58] <ClassBot> rsajdok asked: How find these bugs?
[17:58] <Kaleo> rsajdok: unfortunately we don't have such a list readily available
[17:59] <Kaleo> rsajdok: you will have to try I am afraid
[17:59] <Kaleo> I think it's time for me to leave the stage to Curtis Hovey
[18:00] <dpm> Thanks a lot for a great session Kaleo!
[18:00] <Kaleo> :)
[18:00] <Kaleo> thanks dpm, thanks for the questions everybody
[18:00] <dpm> Next up Launchpad legend Curtis Hovey will talk about his developer plugins for Gedit
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/06/%23ubuntu-classroom.html following the conclusion of the session.
[18:06] <sinzui>  What is gedit?
[18:06] <sinzui> gedit is a simple text editor
[18:06] <sinzui>  with support for syntax highlighting
[18:06] <sinzui>  that can be extended for new uses
[18:07] <sinzui> See https://live.gnome.org/Gedit to see a full list of features
[18:07] <sinzui> gedit ships with plugins to help power-users
[18:07] <sinzui>  The gedit-plugins package for provides tools to help developers
[18:07] <sinzui>  Many developers provide extra plugins for specific development
[18:08] <sinzui> See http://live.gnome.org/Gedit/Plugins for a list of plugins supported by gedit 3.x
[18:09] <sinzui> Developers will want to install a few packages from Ubuntu universe to get the set of plugins that I recommend and use.
[18:09] <sinzui> Using Software Center
[18:10] <sinzui> Search gedit plugins
[18:10] <sinzui> Show technical items
[18:10] <sinzui> install gedit-plugins, gedit-developer-plugins
[18:10] <sinzui> Edge and bleeding edge archives provide fixes
[18:10] <sinzui> and features several weeks ahead of Ubuntu
[18:10] <sinzui> universe
[18:11] <sinzui> ppa:sinzui/ppa for what I will propose for Ubuntu, and ppa:sinzui/gdp-unstable for what is being tested--can be dangerous
[18:12] <sinzui> Gedit must be configured for development and to use plugins
[18:12] <sinzui> Edit > Preferences > View
[18:12] <sinzui> * View margin and line numbers
[18:12] <sinzui> * Highlight the line and
[18:12] <sinzui> * matching bracket
[18:12] <sinzui> * Disable text wrapping
[18:13] <sinzui> Edit > Preferences > Editor
[18:13] <sinzui> * Set the tab width to 4 or 8 spaces per the project you are working on
[18:13] <sinzui> * Insert spaces instead of tabs
[18:13] <sinzui> * Enable automatic indentation
[18:14] <sinzui> Edit > Preferences > Plugins
[18:14] <sinzui> Enable: Bookmarks,
[18:14] <sinzui> Code comment, Draw
[18:14] <sinzui> spaces, File browser,
[18:14] <sinzui> panel, GDP Bazaar
[18:14] <sinzui> integration, GDP Find,
[18:14] <sinzui> GDP Format, GDP
[18:14] <sinzui> Syntax, Completer,
[18:14] <sinzui> Modelines, Snippets,
[18:14] <sinzui> Sort, Spell Checker
[18:14] <sinzui> ^ that is only half of the plugins that are installed. There are others that you may want
[18:15] <sinzui> There are also competing and overlaping plugins. notably Word Completion, Snippets, and GDP Syntax Completer
[18:16] <sinzui> The Draw spaces plugin requires additional configuration to work
[18:16] <sinzui> Use the Preferences
[18:16] <sinzui> button in the Plugins
[18:16] <sinzui> tab to set the kinds
[18:16] <sinzui> of white-space you
[18:16] <sinzui> want to see:
[18:17] <sinzui> Enable/disable the plugin using Menu > View > Show white space
[18:17] <sinzui> GDP Syntax completer plugin
[18:17] <sinzui> Use Alt+/ to view a list of candidates to replace the text being typed:
[18:17] <sinzui> * Python identifiers
[18:17] <sinzui> * Open or used xml tags
[18:17] <sinzui> * Words in the document
[18:18] <sinzui> ^ Alt+/ is not convenient, but it avoids the conflicting accelerator issue upstream
[18:19] <sinzui> GDP find and replace plugin
[18:20] <sinzui> Search multiple files within a directory Filter on sub-directory or file name fragment
[18:20] <sinzui> * Use regular expressions
[18:20] <sinzui> * Match case
[18:20] <sinzui> * Replace in multiple files (supports REs)
[18:20] <sinzui> * Save the list of matches
[18:20] <sinzui> The plugin appears in the right panel.
[18:21] <sinzui> You can show the side panel from using F9, or Menu > View > Side panel
[18:21] <sinzui> The find and replace actions are also in the Search menu
[18:22] <sinzui> GDP formating and syntax/style checking
[18:23] <sinzui> Menu > Tools > Check style and syntax reports errors and issues in one of more files being edited
[18:23] <sinzui> There is special support for Python, Javascript, and CSS
[18:24] <sinzui> where syntax errors are reported
[18:24] <sinzui> There are actions under Menu > Tools to reformat CSS and doctest files
[18:25] <sinzui> Menu > Edit > Format provides
[18:25] <sinzui> * text rewrapping
[18:25] <sinzui> * Fix line ending
[18:25] <sinzui> * tabs to spaces
[18:25] <sinzui> * regular expression inline reformatting
[18:25] <sinzui> GDP Bazaar integration
[18:26] <sinzui> * Branch, edit, commit, and push bazaar projects.
[18:26] <sinzui> * bzr-gtk is used to visualize the files and tree
[18:26] <sinzui> * Work with SVN, HG, and git branches when the proper bzr plugins are installed
[18:28] <sinzui> I also use Source Code Browser pugin: A source code class and function browser based on Exuberant Ctags
[18:28] <sinzui> See https://github.com/Quixotix/gedit-source-code-browser
[18:29] <sinzui> ^ This, like my own gedit-developer-plugins is transitioning to Gedit 3.x plugin architecture
[18:29] <sinzui> Some features of the plugins there are available in natty are not available at this moment in oneiric
[18:31] <sinzui> If you are using oneiric, you may have noticed that all plugins in gedit, totem, rhythmbox, and any other libpeas-based application were broken. This was fixed in the last 24 hours
[18:31] <sinzui> bzr-gtk is being updated the gtk3. We may see a package for testing this week
[18:32]  * sinzui is doing the conversion
[18:33] <sinzui> The 4 gdp plugins are broken in oneiric with the libpeas fix. I have a fix and it will be released to my unstable ppa in a few hours
[18:34] <sinzui> The source browser plugin could do more. It shows the tags for the open file, but it does not yet allow you to search a tags file for a project.
[18:35] <sinzui> That is all I have to present. I know quite a bit about gedit, its underlying libraries, plugins, and bzr-gtk. I can answer question on these topics
[18:44] <sinzui> bulldog98: there is a vi mode plugin for gedit 2.x
[18:45] <sinzui> mohammedalieng: keyboard shortcuts can be enabled for ALL gtk applications by hacking a gconf/dconf config key
[18:45] <sinzui>  The feature is essentially gtkrc accelerator configs files
[18:46] <sinzui> shazzner: gdp syntax completer will complete python and show the ptyhon help(). It needs refinement
[18:47] <sinzui> shazzner the display window is broken upstream (in the gtk source view complete code). I am working on a work around or an upstream widget fix
[18:49] <sinzui> dpm: gedit-developer-plugins has been in universe since natty and I update it when I see development break. It broke this morning. I already have a fix pushed. I will build and test the package today!
[18:49] <sinzui> I think I have answered everyone's question
[18:50] <ClassBot> There are 10 minutes remaining in the current session.
[18:50] <sinzui> bulldog98, gvim (gtk-version) uses gtksourceview2 (the gedit display lib).
[18:51] <sinzui> The core gedit app adds undo, find and replace, and plugin support to the core lib
[18:52] <sinzui> So gvim just marries gedit display rules with vim's editing rules
[18:54] <sinzui> shazzner: one other point. There is a tab/control+space accelerator conflict in Gedit. There is one completer module that other modules provide for, but there was not mechanism to manage which provider is activate.
[18:55] <sinzui> I use GDP Syntax Completer and snippet, so I choose the awkward Alt+/ combination :(
[18:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/06/%23ubuntu-classroom.html following the conclusion of the session.
[19:00] <achuni> ok, I guess that's me :)
[19:01] <achuni> Hi everybody, I'm Anthony Lenton
[19:01] <achuni> I work at Canonical, in ISD.  We're the team responsible for the development of Ubuntu SSO, Ubuntu Pay, and quite a few other smaller infrastructure-related systems
[19:01] <achuni> Within ISD I'm leading the team that is in charge of the Software Center Server
[19:02] <achuni> that includes ratings and reviews, the software center agent, and the MyApps portal
[19:02] <achuni> ... for those of you that are unfamiliar with the MyApps portal, it's what sits at https://myapps.developer.ubuntu.com/
[19:02] <achuni> we're currently in public beta, so you can create an account and play around with it
[19:02] <achuni> (please let us know what breaks! :) )
[19:03] <achuni> also, apologies up front if I incorrectly call MyApps "the devportal" or "the developer portal"
[19:03] <achuni> We started clalling it that during development, hence the name of the project on Launchpad, https://launchpad.net/developer-portal
[19:04] <achuni> Clearly *the* developer portal is developer.ubuntu.com, this awesome bucket of knowledge dpm and johnoxton are going to tell us all about right here on Thursday at 16UTC
[19:04] <achuni> MyApps is the part of developer.ubuntu.com that takes care of the submission workflow to get your apps published in the Ubuntu Software Center
[19:04] <achuni> so... my plan is to tell you a bit of the story of MyApps, and go over the current workflow
[19:05] <achuni> then tell you a bit about the most immediate milestones in our roadmap, and answer a few questions
[19:05] <achuni> (yay, none so far :) )
[19:06] <achuni> We started with myapps after UDS-N, end of last year-ish, as a way to make it easier for developers to get their (paid) apps into USC
[19:06] <achuni> we had already had for-purchase apps in USC for just over six months by then
[19:06] <achuni> and we still had only a bunch of (not quite 10 iirc) apps available for purchase
[19:07] <achuni> Adding new apps was a painfully manual process, for all parts involved.
[19:07] <achuni> Contacting and arranging an agreement with the developer was done manually, they'd send us the app somehow and we'd manually package it up
[19:07] <achuni> A sysadmin would then manually make it available for sale.  Canonical's finance department would get a monthly report of sales and (manually!) send developers the right amount of money
[19:08] <achuni> We knew if we wanted to make this scale to tens of thousands of apps, we would need to remove all or as many as possible of the manual steps in this process.
[19:09] <achuni> so, what's up on https://myapps.developer.ubuntu.com/ is what we currently have.  There's still quite a few of manual pieces involved
[19:09] <achuni> but the plan is to get it fully automated in the future
[19:09] <achuni> Once you've created an account and accepted the terms of service on that site, you can go straight in and submit an application for review
[19:10] <achuni> (not sure if it's best for you to do that now, this was going to be a more of a hands-on session but in the end it's more of a talk-and-screenshots session :) )
[19:10] <achuni> anyway...
[19:10] <achuni> The submission workflow currently has five steps (or six, depending on how you count)
[19:11] <achuni>  - basic details of your app (name, tagline, price, and upload the actual code)
[19:11] <achuni> - Finding your app (description, keywords, and in which USC department it belongs)
[19:11] <achuni> (  USC is Ubuntu Software Center there ^)
[19:11] <achuni> - Showing your app (Screenshot and icons)
[19:12] <achuni> - License and support (Type of license and support url)
[19:12] <achuni> (Ok, yes, these had no real reason to be together in the workflow)
[19:12] <achuni> - Getting paid (your paypal email, phone number and a postal address for contacting you at)
[19:13] <achuni> After that, the sixth step would be to just check the details and submit the app for review.
[19:13] <ClassBot> bulldog98 asked: when will it be possible to use a Qt based SSO
[19:14] <achuni> bulldog98: hm you mean like the current ubuntu-sso-client that's gtk only? I don't know of a project that does that
[19:14] <achuni> bulldog98: sso provides an api, the current gtk client was developed by U1 because it suited them best, but you can also use the API directly
[19:16] <achuni> bulldog98: I'm not sure how the different bits ussoc does would map to Qt, but it shouldn't be impossible to write such a client at the moment already
[19:16] <achuni> bulldog98: but I'm afraid I don't know of a project for doing that atm
[19:16] <ClassBot> shazzner75 asked: Any chance for alternate payment methods? Google Checkout, etc?
[19:17] <achuni> shazzner75: for purchasing apps, or for paying developers?  there are plans to add new payment methods for both, but a bit longer term  :)
[19:18] <achuni> not sure if Google Checkout is on the roadmap
[19:18] <achuni> anyway, this is what you'd see when you finish providing the details for your app:
[19:18] <achuni> http://ubuntuone.com/6FfqFGgGnNucVS6PiBma7T
[19:19] <achuni> When you submit an app for review, application reviewers are notified via email currently.  They'll pick it up pretty soon
[19:19] <achuni> Packaging the app is still carried out manually at the moment
[19:20] <achuni> Though as jml mentioned yesterday, we're working on integrating pkgme that should automate most of that process
[19:20] <achuni> Once the application has been reviewed and uploaded we do some basic QA to ensure that, if it's made public, purchases will go smoothly and the app will launch successfully when installed.
[19:21] <achuni> This isn't intended to be QA of the application itself (beyond checking that some app actually launches), though very often we get feedback on the app itself during QA.
[19:21] <achuni> If at any point the reviewer has some question, or there's some missing bit of information in the app, the app will be passed back to the developer as "Needs Information".  You can then modify your app with the right information, and resubmit for review
[19:22] <achuni> You can always see the full review feedback history for an app in the "Feedback" tab
[19:22] <achuni> (screenshot coming...)
[19:22] <achuni> http://ubuntuone.com/3bVuC7ZqIGEtTiXpe65zBb
[19:22] <achuni> So, assuming the application passes review, the app is *still* not automatically published in USC.
[19:22] <achuni> It's flagged as "Ready to publish", and you (the developer) can then decide when it actually goes public.
[19:23] <achuni> http://ubuntuone.com/7b97CAI3581sVHg6XpIHw8
[19:23] <achuni> When the developer clicks "Publish" it's made public immediately, except for caching in the api and USC.
[19:23] <achuni> But it'll be really live and out there in USC worldwide in a few minutes.
[19:24] <achuni> The developer can also decide to unpublish an app at will once it's made public.  This will remove the application from USC immediately so taht nobody else can purchase it
[19:24] <achuni> Users that have already purchased *will* still be able to download and/or reinstall the app.
[19:24] <achuni> Also, at any point, you can look at the sales information for your app in the "Metrics" tab
[19:24] <achuni> http://ubuntuone.com/0bbI5tMJ11HSnWJOooxk5N
[19:25] <achuni> So... upcoming features and things we're working on:
[19:25] <achuni> - Reviewer notes! At the moment you can't provide notes for the application reviewer along with the app
[19:25] <achuni> yep, silly, but we're on it :)
[19:26] <achuni> - pkgme integration.  This is the automated packaging that jml went into details about yesterday.
[19:26] <achuni> That'll be *great* to have as packaging the app is one honking big piece of manual work that's still necessary
[19:26] <achuni> and we need to rely on the developer to provide packaging files, or the reviewer has to create them from scratch every time
[19:27] <achuni> - ARB integration.  In the future free (libre and gratis) apps that are currently being reviewed by the Application Review Board will also be submitted through MyApps.
[19:27] <achuni> This will make things clearer, simpler and generally better for developers as you'll have a single place to submit your apps for publishing in USC.
[19:28] <achuni> Stay tuned for stgraber's session about the ARB, coming up next :)
[19:28] <stgraber> yeah!
[19:28] <achuni> :D
[19:29] <achuni> - license key infrastructure.  ...
[19:29] <achuni> this is almost a topic for another talk, but in a nutshell, you'll be able to provide batches of keys for your app
[19:29] <achuni> those will be served up one per purchase, and stored in a file locally for your application to check
[19:30] <ClassBot> shazzner75 asked: how do updates work? ie. developer pushes out new version, will it be available immediately or next Ubuntu cycle? What about free/libre apps?
[19:30] <achuni> shazzner75: so, we're still figuring out some of the details, but you don't need to wait for the next Ubuntu cycle
[19:31] <achuni> I mean, new versions are easier: they go through review as usual, and as soon as the reviewer uploads the fix, anybody that's purchased the app will get the update with the next batch of updates
[19:32] <achuni> when a new Ubuntu cycle comes along, the app will be repackaged for this new distroseries, and uploaded, so people that have purchased the app should still have it when they upgrade
[19:33] <achuni> (the bit that's tricky is apps that work in one version of Ubuntu but not in the next.  currently those users will be update-less until the app is fixed for the new release)
[19:34] <achuni> wow, and that's about it.
[19:35] <achuni> so, the upcoming plan is to fix bugs, polish and add awesomeness.
[19:35] <achuni> be sure to tune in for dpm's and johnoxton's session on Thursday about the general developer.ubuntu.com portal
[19:35] <achuni> ...and jpugh's session on Friday for any questions about the business side of things.
[19:36] <achuni> Questions?
[19:37] <ClassBot> shazzner75 asked: Can you specify things like system requirements? (like for 3d games)
[19:38] <achuni> shazzner75: so, currently the only way to do this is to include a debian control file with your code
[19:39] <achuni> shazzner75: the grand plan is to allow you to do that in a friendlier way that works well with pkgme
[19:39] <achuni> so pkgme will "guess" your system dependencies
[19:39] <achuni> ah, you mean *system* dependencies
[19:39] <achuni> hm... :)
[19:40] <achuni> not that I know of, not currently, but that would be quite interesting
[19:40] <achuni> I mean, software-center would need to perform the checks on the user's box, but it would make sense
[19:41] <achuni> shazzner75: right, as in "at least so much RAM", or "these graphic cards aren't supported"
[19:41] <achuni> shazzner75: so far we've seen comments about system requirements in the application descriptions
[19:42] <achuni> shazzner75: but the system doesn't allow you to specify those in a more structured manner I'm afraid
[19:42] <achuni> (...yet! :) )
[19:45] <ClassBot> shazzner75 asked: since I'm asking questions here, is there any policy about android-like usage of user-data or resources? (notifications, email, connects to web, etc)
[19:46] <achuni> shazzner75:  I'm not really aware of the android policy... I'd pop that question at jpugh on his Friday session
[19:49] <ClassBot> shazzner75 asked: another question, apologies if this has been answered, when submitting a proprietary app. So you submit it as a binary (like jar file) or as source code to be packaged?
[19:50] <achuni> shazzner75: it hasn't been answered, and thanks for asking :)
[19:50] <ClassBot> There are 10 minutes remaining in the current session.
[19:50] <achuni> shazzner75:  you can submit it as a binary (jar file, elf or whatever), no need to submit the source code
[19:51] <achuni> shazzner75: for proprietary apps that is
[19:51] <achuni> shazzner75: for libre apps going in for ARB review I imagine they'll expect to see the source code available :)
[19:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:56] <achuni> ok, I think we're done then.  thanks everybody for joining!  stay tuned for stgraber, coming up next, don't go far :)
[20:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/06/%23ubuntu-classroom.html following the conclusion of the session.
[20:02] <stgraber> Hey everyone!
[20:02] <stgraber> I'm Stéphane Graber, one of the members of the Ubuntu Application Review Board (ARB).
[20:02] <stgraber> During this session I'll try to introduce you on what the Application Review Board does and how it can help you get your apps in Ubuntu.
[20:02] <stgraber> I'll also try to explain the difference with some of the other ways of getting your apps in Ubuntu.
[20:03] <stgraber> As I don't expect to have enough content to entertain you for an hour, please don't hesitate to ask questions, I'll be glad to answer them!
[20:03] <stgraber> Please note that my Internet is a bit laggy at the moment if I disconnect or don't react for a few minutes, that's "normal" :)
[20:03] <stgraber> Let's get started!
[20:03] <stgraber> So, what's the Ubuntu Application Review Board?
[20:03] <stgraber> It's a team of 4 community members, Allison Randal, Andrew Mitchell, Shane Fagan and myself.
[20:03] <stgraber> Our responsability is to review Apps that are submitted for a stable release of Ubuntu and that are open source and gratis.
[20:04] <stgraber> Apps going through that process are usually small standalone apps, ideal examples are small apps made with Quickly.
[20:04] <stgraber> The board offers assistance with the packaging of these apps, making sure they conform to our rules (such as installing in /opt) and once they are good to go, vote on them and get them into the Ubuntu Software Center.
[20:04] <stgraber> Some more details on what's needed for an App to go through the ARB process can be found at: https://wiki.ubuntu.com/AppReviews
[20:05] <stgraber> and some others at: https://wiki.ubuntu.com/AppReviewBoard/Submissions/Request
[20:05] <stgraber> The current list of apps in the process can be found on Launchpad: https://launchpad.net/ubuntu-app-review-board
[20:06] <stgraber> So far we had two apps going through the process and available for Ubuntu 10.10. News and Suspended Sentence
[20:06] <stgraber> It's also worth noting especially after's achuni's session on MyApps that the ARB is now working on switching the process to using MyApps as the single entry path for post-release Apps.
[20:06] <stgraber> We hope in the near future to drop Launchpad from our review process and have everything happen on MyApps and have all our documentation on the development portal.
[20:07] <stgraber> Any question so far?
[20:09] <stgraber> Apparently not
[20:09] <stgraber> So how's that different from the other ways of getting your software in Ubuntu?
[20:09] <stgraber> As you may know, there are a lot of different ways of getting a software in Ubuntu, here are the few I can think of.
[20:09] <stgraber> For Open Source / Free software (and gratis), you can have it enter the archive through:
[20:09] <stgraber>  - Debian and then synced into Ubuntu during the development cycle (before the Feature Freeze)
[20:10] <stgraber>  - Directly uploading to Ubuntu during the development cycle (before the Feature Freeze)
[20:10] <stgraber>  - After the release by getting it in Debian or Ubuntu's development version and requesting a backport
[20:10] <stgraber>  - Through the Application Review Board
[20:11] <stgraber> For Proprietary apps, you can go with:
[20:11] <stgraber>  - Canonical partner apps (my understanding is that it's case by case and only for gratis software)
[20:11] <stgraber>  - For purchase apps in the Ubuntu Software Center.
[20:11] <stgraber> I'm only going to focus on what I know quite well which is the process for open source software.
[20:12] <stgraber> The usual recommendation is for developers to get their package into Debian and either maintaing them themselves there or finding someone who can maintain them.
[20:12] <stgraber> This is great because the maintainer is going to take care of most of the work and you can usually just focus on your "upstream" work.
[20:12] <stgraber> This only works if you plan enough time ahead as you need to get your software into Debian, then synced in Ubuntu (happens automatically early in the cycle) and that's only available until the Feature Freeze.
[20:13] <stgraber> If your package is specific to Ubuntu or you don't want to deal with Debian (or don't have the time to), you can get it directly in Ubuntu as long as it's uploaded before the Feature Freeze.
[20:14] <stgraber> More details can be found at: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[20:14] <stgraber> If you missed the Feature Freeze, you can still get your software in Debian so that it's available as soon as the next Ubuntu release opens. Or you can wait for the next Ubuntu release to open and get it uploaded directly to Ubuntu.
[20:14] <stgraber> Once the package is in the development release, you can ask for it to be backported.
[20:15] <stgraber> More details on backports are at: https://help.ubuntu.com/community/UbuntuBackports
[20:15] <stgraber> And finally, if you're just interested in quickly getting your app available post-release and want to be the one maintaining it, the ARB process is definitely for you.
[20:15] <stgraber> You'll need to submit your app for every version of Ubuntu you want to support and will have to do the same for any update you want to push to your users.
[20:15] <stgraber> It's also worth noting that we don't automatically upload your apps to a new version of Ubuntu, you need to re-apply for that.
[20:16] <stgraber> I guess that should give a pretty good overview of the possible ways of getting an app in Ubuntu.
[20:17] <ClassBot> shazzner75 asked: I remember before users had to add a certain repository to add in post-release apps, is that still the case? (I may be remembering this wrong)
[20:18] <stgraber> the extras.ubuntu.com repository is automatically added at installation time
[20:19] <stgraber> I seem to remember there's a specific installation path where you don't get it though, but in most cases you should have it enabled
[20:19] <stgraber> it's worth noting that there currently aren't any app in Natty's extras.ubuntu.com repository
[20:20] <ClassBot> shazzner75 asked: Can we submit libre apps to be reviewed if we are not the owner? ie. small abandoned software under GPL?
[20:21] <stgraber> I don't think we ever got that case yet.
[20:21] <stgraber> One of the difference from the other ways of getting your package in Ubuntu is that we won't maintain your software, you'll.
[20:22] <stgraber> and that's why we usually prefer to have the upstream do it as they're the one who're the most able to fix any bug or security issue in their software
[20:22] <stgraber> that being said, if the app's upstream is dead and you want to "adopt" it and take care of any issue that might appear, I don't think it'd be a problem
[20:23] <stgraber> in the case where we get a security issue or other critical bug in a software that's in extras.ubuntu.com
[20:23] <stgraber> a board member will quickly try to fix it on a best effort basis, then contact the upstream to get a fix ASAP
[20:24] <stgraber> and if the upstream isn't responsive and it's a critical bug (remote execution comes to mind), then the app will be removed from the repository and from our users' system (by pushing an empty package with a changelog entry indicating what the problem was)
[20:25] <stgraber> this is quite different from the other ways of getting a package in Ubuntu as you'd otherwise get the Ubuntu Security team or Ubuntu MOTU taking care of these issues
[20:25] <stgraber> any other question?
[20:27] <stgraber> ok, so let's continue. I only have for a few more minutes of content, so don't hesitate to ask questions in #ubuntu-classroom-chat
[20:27] <stgraber> Before I'm done talking, I just wanted to list some of the things the ARB is working on to make it easier for you to get your app in Ubuntu.
[20:28] <stgraber> We noticed that our current process is quite long, has quite a few annoying bottlenecks and requires quite a lot of energy from our members.
[20:28] <stgraber> Fortunately for us we haven't got too many submissions so it hasn't been much of a problem.
[20:29] <stgraber> Still we've been discussing of a few ways to get the whole process a lot more efficient so we can handle a lot more apps once we have a better infrastructure to attract app developers.
[20:29] <stgraber> As achuni mentioned in -chat earlier, I'm the upstream of a tool called Arkose that allow easy containing of apps.
[20:30] <stgraber> It can offer something quite similar to what you get on your Android phone with a list of actions that the app is allowed to perform.
[20:30] <stgraber> I'm currently investigating the use of that tool to make the reviews go a lot faster as we won't have to do a full code review.
[20:31] <stgraber> Our current review process includes a full code review of every app by a member of the ARB. This requirement means we're not able to review really complex apps or apps written in some languages.
[20:32] <stgraber> Having Arkose or Apparmor (ideally I'll have apparmor supported in arkose soon) profiles for these apps mean that the ARB can just review the safety of the profile and do targeted code audit, avoiding the very long full audit.
[20:32] <stgraber> Another tool I'm working on is a debhelper script that you can use to basically automatically package your app so that it's compliant with the ARB policy.
[20:33] <stgraber> It basically makes sure everything is in /opt, adapts any .desktop file you ship and uses a small helper to make your app think it's running in /usr
[20:33] <stgraber> My long term goal is to have everything done through MyApps, where you'd send a tarball of your code and a small build recipe.
[20:34] <stgraber> Then you'd be asked to set where your app stores its data, what DBUS APIs you need to access, physical devices, network, ...
[20:34] <stgraber> that'd be used to generate an Arkose or Apparmor profile (or both)
[20:34] <stgraber> Send copyright information, description, screenshot and click Send.
[20:35] <stgraber> Based on that a package can be entirely automatically generated, reviewed in a few minutes by an ARB member and then made available to everyone in the Software Center.
[20:35] <stgraber> Reducing the submission time from a few weeks (our current average ...) to a few hours.
[20:36] <stgraber> I believe this would work quite well for simple apps that don't need complicated packaging and would save the developer a lot of time that they could instead invest in improving their app.
[20:37] <stgraber> And I'm now officially done talking, so if you have any remaining question, please ask in #ubuntu-classroom-chat!
[20:50] <ClassBot> There are 10 minutes remaining in the current session.
[20:55] <ClassBot> There are 5 minutes remaining in the current session.
[21:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/09/06/%23ubuntu-classroom.html
[21:02] <stgraber> thanks everyone for attending today's sessions!