[09:32] <mofium> Hey there, I'm doing the yesterdays first session atm wonder what's the difference between changelog.dch
[09:32] <mofium> and the normal changelog file
[09:34] <mofium> by running "dch -i" the first time it created and opened changelog.dch, but after building the package the changelog sais the last edit was done by  holbach although I left my log
[09:35] <mofium> running the dch-i again resultes in the following error
[09:35] <mofium> dch: fatal error at line 757:
[09:35] <mofium> The backup file debian/changelog.dch already exists --
[09:35] <mofium> please move it before trying again
[14:48] <tuxfan_> No work today waiting for next class!Hi everybody!
[14:49] <IdleOne> starting in 11 minutes
[14:50] <smartboyhw> 10 minutes!
[14:50] <JoseeAntonioR> hey guys, we're starting in a short while!
[14:50] <Marin> hello all :)
[14:51] <wei2912> JoseeAntonioR, great :D
[14:51] <wei2912> i've been idling here waiting for a class to start
[14:51]  * rick_timmis waves
[14:51] <rick_timmis> BRB, Just go grab a coffeee
[14:53] <tuxfan_> and RIM is presenting BB10 right now :)....
[14:53] <wei2912> :)
[14:53] <wei2912> btw, i'm curious about what will happen during the class?
[14:53] <tuxfan_> Is it app development today?
[14:54] <wei2912> should be.
[14:54] <wei2912> should be starting soon, How to write apps for Ubuntu.
[14:54] <wei2912> (great coincidence that this is the class i was planning to listen to)
[14:56] <tuxfan_> 4 mins to go :)
[14:56] <wei2912> tuxfan_, do we just listen to the class, or can we ask our questions while the class is ongoing?
[14:57] <IdleOne> wei2912: you can ask questions in #ubuntu-classroom-chat
[14:57] <JoseeAntonioR> WELCOME EVERYBODY!
[14:57] <JoseeAntonioR> This is day 2 of Ubuntu Developer Week and if you're completely new to the the event, you might want to check out https://wiki.ubuntu.com/UbuntuDeveloperWeek to review the schedule. This is also the place where logs and links to videos will be posted after the sessions.
[14:57] <wei2912> IdleOne, thanks
[14:58] <JoseeAntonioR> If you want to ask questions and join the conversation about the sessions, please make sure you also join #ubuntu-classroom-chat
[14:58] <JoseeAntonioR> When you ask questions, please make sure you prefix them with QUESTION: otherwise they will not be picked up.
[14:58]  * rick_timmis waves
[14:58] <wei2912> great...
[14:59] <JoseeAntonioR> We're starting in just a couple seconds! Have fun today!
[14:59] <wei2912> have fun everyone
[15:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html following the conclusion of the session.
[15:02] <dpm> hi everyone!
[15:02] <dpm> Welcome to this introductory session on writing apps for Ubuntu
[15:02] <dpm> aka the first step to becoming a full-blown Ubuntu App Developer :)
[15:03] <dpm> For those of you who don't know me, I'm David Planella,
[15:03] <dpm> and I work as the Ubuntu App Development Liaison in the Community team at Canonical.
[15:03] <dpm> In the past I've work as Ubuntu Translations Coordinator as well,
[15:03] <dpm> but these days I'm more focused on our App Developer story.
[15:04] <dpm> App Development is an exciting territory, and I hope you enjoy it as much as I do :)
[15:05] <dpm> What we are going to see today is a very gentle but quick-paced introduction to
[15:05] <dpm> writing apps for Ubuntu, both on the desktop and for the phone.
[15:05] <dpm> The idea is to get you familiar with the tools and processes to use and to follow throughout your app's lifecycle, which hopefully will whet your appetite for more :)
[15:06] <dpm> I'll be focusing on the desktop story for now, but I will talk a bit about app development for the phone with our preview SDK at the end.
[15:07] <dpm> This is an area that you all probably have heard about, and you probably also know that it's changing, evolving and getting defined very rapidly, but I'll give you the lowdown of the tools available to app devs today.
[15:07] <dpm> I'll also be directing you to the right places to ask for help
[15:07] <dpm> The way the session will be structured will be a bit like the developer journey on the app developer site at developer.ubuntu.com,
[15:08] <dpm> so it will be similar to a tour through the site,
[15:08] <dpm> which is the place you'll generally go to whenever you need more information or whenever you submit an app to ultimately be published in the Software Centre.
[15:08] <dpm>  
[15:08] <dpm> So something like:
[15:08] <dpm>  
[15:08] <dpm> 1. Get started
[15:08] <dpm> 2. Resources
[15:08] <dpm> 3. Publish
[15:08] <dpm> 4. Community
[15:08] <dpm>  
[15:09] <dpm> Oh, and the developer site is, of course, at http://developer.ubuntu.com :)
[15:09] <dpm> Go and check it out :)
[15:09] <dpm> The time is limited, so we'll go into more detail into the more practical step of getting started, which is more fun,
[15:09] <dpm> and we'll just say a few words on the other steps.
[15:10] <dpm> If you've got questions during the session, feel free to ask at any time!
[15:10] <dpm> just do it on #ubuntu-classroom-chat and prepend them with QUESTION:
[15:10] <ClassBot> tuxfan_ asked: mobile application too?
[15:10] <dpm> Yes, we'll see a bit about mobile apps too :)
[15:11] <dpm> So,
[15:11] <dpm> let's roll!
[15:11] <dpm>  
[15:11] <dpm> Developing apps on the desktop
[15:11] <dpm> [15:11] <dpm>  
[15:11] <dpm> The tools
[15:11] <dpm> ---------
[15:11] <dpm>  During the first part of the session I'll be talking about Quickly.
[15:12] <dpm> This is what we'll use to create Ubuntu desktop apps. At the technical level,
[15:13] <dpm> Quickly is nothing else than a command-line utility which acts as a wrapper around the tools we chose to be part of the Ubuntu app developer story.
[15:13] <dpm> It provides a set of commands to act as shortcuts to the key actions a developer most usually needs while writing a piece of software.
[15:13] <dpm> They are quite handy, and they really make life easier for you.
[15:13] <dpm> Here are some examples of such commands:
[15:13] <dpm>  
[15:14] <dpm> $ quickly edit # To open your code files in an editor of your choice
[15:14] <dpm> $ quickly debug # To start debugging your application graphically
[15:14] <dpm> $ quickly package # To automatically package your app for you
[15:14] <dpm>  
[15:14] <dpm> As you see, very easy to use
[15:15] <dpm> Note that you don't have to use Quickly commands if you are already familiar with the underlying tools it invokes.
[15:15] <dpm> Quickly just provides the glue and a few handy shortcuts.
[15:16] <dpm> So for instance using 'quickly save' is the same thing as 'bzr commit' (the command to commit files to the Bazaar distributed revision control system).
[15:16] <dpm> You can see a nice overview of those underlying tools and the commands to activate them here:
[15:16] <dpm>  
[15:16] <dpm>     http://developer.ubuntu.com/get-started/quickly-workflow/
[15:16] <ClassBot> wei2912 asked: do you mind providing some examples? :)
[15:17] <dpm> Yes, we'll get into the examples in a minute :)
[15:17] <ClassBot> tuxfan_ asked: Quickly provides a command adding new Dialogs(GTK.Dialog) how about new Windows (Gtk.Window)?
[15:18] <dpm> indeed it does. Right now there is no command to automatically generate the code to create new windows for you, but as you've rightly noted, we do have a dedicated command for the more usual operation of creating a dialog
[15:19] <ClassBot> bobweaver asked: do you know if there are other options besides just gedit ? like quickly edit <IDE goes here> as gedit is not a Pure IDE and I sometimes have trouble with it
[15:20] <dpm> There are plenty indeed. We're just making an opinionated choice to provide guidance and to concentrate on a set of tools we can support
[15:20] <dpm> So while we recommend Gedit, you can use any other programmer's editor such as Vim, Emacs, Geany... etc.
[15:21] <dpm> If it's your first time writing apps for Ubuntu and you want to try something else than Gedit, Geany might be a good option
[15:22] <dpm> If you want to go for a full-blown IDE, you can try Eclipse with the Python dev plugin, or Ninja IDE, etc
[15:22] <ClassBot> wei2912 asked: could you go indepth into how the application is packaged, as a DEB file or?
[15:22] <dpm> sure, let me go through the example app and then talk a bit about packaging
[15:23] <dpm> Ok, so moving on...
[15:23] <dpm> The technologies you'll see today are Python, Glade and a bit of Bazaar and Debian packaging, although those two will rather be working in the background
[15:23] <dpm> The other nice thing about Quickly is that it installs all the packages you'll need to get started hacking on Ubuntu.
[15:23] <dpm> (as in hacking a new app)
[15:23] <dpm> So if you want to follow along and create your first desktop app, go ahead and:
[15:24] <dpm>  
[15:24] <dpm> * Install quickly by opening http://apt.ubuntu.com/p/quickly on your browser
[15:24] <dpm>  
[15:24] <dpm> In principle, you can use any combination of tools and programming languages for Ubuntu apps.
[15:24] <dpm>  It's just that we simply cannot support every single combination under the sun, so we made a set of oppinionated choices on the tools we think are best and are best supported in Ubuntu and put them together with quickly
[15:25] <dpm> So if you create apps with quickly, they'll be easier to create, review and publish in the Software Centre
[15:25] <dpm> ok, let's finally move on to the fun part :)
[15:25] <dpm>  
[15:25] <dpm> Step 1: Get started
[15:25] <dpm> -------------------
[15:25] <dpm>  
[15:25] <dpm> This is the stage we get straight to business and put on our developer hats for some hacking fun.
[15:25] <dpm> At this point we generally have an idea of the type of app we want to write and go for the implementation.
[15:26] <dpm> In this case, we'll be writing a very very simple 'Hello world!' type ofapp, but with a twist: ours will be an 'Ubuntu rocks!' app.
[15:26] <dpm> There is also a video tutorial you can watch the later at http://developer.ubuntu.com/get-started/, it's detailed but quick to the point,
[15:27] <dpm> but for now, and given that we've already installed the tools, we'll start writing some code.
[15:27] <dpm> Or rather, we'll be writing a minimum amount of code and let Quickly do the heavy lifting for us :)
[15:27] <dpm> Ok, enough talk, now let's get onto it:
[15:27] <dpm> 1. Open a terminal (press the Ctrl+Alt+t key combination)
[15:28] <dpm> 2. Run the following command (again, don't type the leading "$", it's just to mark that it's a command):
[15:28] <dpm>    $ quickly create ubuntu-application ubuntu-rocks
[15:28] <dpm>    -- This will create the boilerplate code for your app, and a first saved revision, so you can concentrate on other more important things :)
[15:28] <dpm> 3. Enter the folder where the code lives now, by running:
[15:28] <dpm>    $ cd ubuntu-rocks
[15:29] <dpm>    -- You'll see all the files Quickly created there. Don't worry too much about them for now, but you can examine them with the file browser later on (e.g. typing 'nautilus .' to fire up the file browser in the folder)
[15:29] <dpm> 4. Next up, we'll modify the AUTHORS file to indicate we're the authors of the code. This is needed by some commands later on. Now type the following:
[15:29] <dpm>    $ gedit AUTHORS
[15:30] <dpm> 5. On the text editor window, add your name and e-mail using the format in the example in there (you'll just need to replace it), then you can save and close the file
[15:30] <dpm> It seems we've got some questions, let me try to answer them quickly
[15:30] <ClassBot> wei2912 asked: what editor do you mostly use?
[15:31] <dpm> I use both Gedit and GVim, the graphical version of Vim, depending on the mood and on the task that I'm working on :)
[15:31] <ClassBot> tuxfan_ asked: So that would be quickly edit <path to eclipse>?
[15:32] <dpm> Quickly currently only provides support for text editors, so while you could use Eclipse for code editing, there wouldn't be direct integration with Quickly
[15:33] <dpm> That is, you could still use the commands, but not within Eclipse (unless you manually add them as external commands to invoke)
[15:33] <ClassBot> JumpLink915836 asked: Is it planned to support more languages with Quickly?
[15:34] <dpm> good question. The way Quickly is designed, it can already support almost any language through its modular design based on templates
[15:35] <dpm> but at the core we focus on Python and a basic Ubuntu GUI app
[15:35] <dpm> There is a community project for those interested in providing templates for app types or different languages for Quickly: https://launchpad.net/quickly-community-templates
[15:36] <ClassBot> xkernel asked: "quickly create ubuntu-application" by defaults create Python app, what if I want to use C or C++?
[15:36] <dpm> I believe the above should also answer this question too :)
[15:36] <dpm> Ok, let's continue
[15:36] <dpm> 6. In order to keep our work, it is good practice to save revisions from time to time. Now it's as good a time as ever. You can do that now by typing:
[15:37] <dpm>    $ quickly save "Updated authors file"
[15:37] <dpm>    -- Now there is a revision identified by a number and the message you passed quickly saved under revision control. You can always come back to it if you like. This command will effectively invoke bzr, the distributed version control system
[15:37] <dpm> 7. Now let's have a look at the code, fire up the text editor to open all the project files:
[15:37] <dpm>    $ quickly edit
[15:37] <dpm>    -- Generally you will be modifying the UbuntuRocksWindow.py file, do not worry about the others for now.
[15:38] <dpm> 8. Ok, now that you know how to edit code, we'll modify the UI a bit to give you a taste of UI design. Fire up glade, the GUI designer:
[15:38] <dpm>     $ quickly design
[15:38] <dpm>     -- What you see are the widgets that are part of your app's main window. You can modify them visually with Glade.
[15:38] <dpm> 9. Go to the widget tree on the top right-hand side, expand the ubuntu_rocks_window until you find 'label1' and select it.
[15:39] <dpm> 10. Now go to the properties dialog below the widget tree and find the 'Label:' property. Change it to something like: "Ubuntu rocks!"
[15:39] <dpm> 11. Check out that the app runs with your UI changes:
[15:39] <dpm>     $ quickly run
[15:39] <dpm> Voilà, your first Ubuntu app, congrats! :-)
[15:40] <dpm> 12. Save the final version of your app:
[15:40] <dpm>     $ quickly save "Modified the GUI with a note"
[15:40] <dpm> At this point I'll leave it up to you to experiment with Quickly and let your imagination run wild with your apps :)
[15:41] <dpm> Unfortunately, we're running out of time, so I'll have to be brief on the packaging command
[15:41] <dpm> However, it works almost magically, just try it:
[15:41] <dpm>     $ quickly package
[15:41] <dpm> and it will package your app automatically for you, which is rather awesome :)
[15:42] <ClassBot> tuxfan_ asked: Why do you put a string after the save command?
[15:43] <dpm> good question. That string will be used as a comment next to the version Quickly (via bzr) will commit. That will help you reviewing history and remembering what you did at each point while developing your app
[15:43] <dpm> you can see such comments using the 'bzr log' command, or any visual revision history viewer
[15:44] <ClassBot> xkernel asked: quickly package raised this error "(setup.py:27328): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken"
[15:44] <dpm> This looks more like a warning than an error to me. Have a look at whether Quickly generated the package or not
[15:45] <dpm> if it didn't, I'd suggest trying to get help on Ask Ubuntu: http://askubuntu.com/questions/tagged/application-development
[15:45] <dpm> which is an awesome resource for all your questions related to Ubuntu, including app development
[15:46] <dpm> I've asked questions there and got answers for the most obscure development topics there, so it's worth checking out
[15:46] <dpm> Ok, so let's move on to mobile, but let me quickly point you to a few useful resources
[15:46] <dpm> http://developer.ubuntu.com/resources/
[15:46] <dpm> Do check out the tutorials in there!
[15:47] <dpm> Also: http://developer.ubuntu.com/community/
[15:47] <dpm> There you'll find all the info you need to get support, and if you like to get involved in the app developer community
[15:47] <dpm>  
[15:47] <ClassBot> tuxfan_ asked: Does that mean i can use the string provided to roll in a previous version?
[15:47] <dpm> ah, let me answer the questions quickly before moving on...
[15:49] <dpm> The string (or comment) is used as a description only (as a human, you are better equipped to understand the description of what you were doing rather than the revision number where you did it). For rolling in previous version you'll use the bzr revision number to which the comment is attached to
[15:49] <ClassBot> yellabs-r2 asked: will future bring integration into glade ?  Or an standalone version for apps development
[15:50] <ClassBot> There are 10 minutes remaining in the current session.
[15:51] <dpm> Quickly is already integrated with Glade in the sense that it invokes it, but tighter integration through an API is planned via the Quickly Reboot project
[15:51] <ClassBot> spav asked: Ok. quickly use gtk+ for UI we can use also Qt witch will use phone version of ubuntu UI
[15:52] <dpm> We're not yet using Quickly for our developer story, as we've just released a preview of our SDK. The Ubuntu SDK preview uses QML for creating mobile apps
[15:52] <dpm> Ok, let's talk more about mobile
[15:52] <dpm>  
[15:52] <dpm> Developing apps for the phone
[15:52] <dpm> [15:52] <dpm>  
[15:52] <dpm> The part that you should get familiar with today is the Ubuntu UI Toolkit, which is part of the Ubuntu SDK preview.
[15:52] <dpm> This is being developer as a separate story from the desktop for now, but you'll gradually see more and more parts converging in our master plan for Ubuntu world domination  :)
[15:53] <dpm> You will find all of the details on how to install the Ubuntu SDK preview and get started here:
[15:53] <dpm>  
[15:53] <dpm> http://developer.ubuntu.com/get-started/gomobile/
[15:53] <dpm>  
[15:53] <dpm> Just try to go through step 1 in the process to install everything while I talk about the UI toolkit for a bit..
[15:53] <dpm> Essentially, the UI Toolkit provides developers with a set of carefully (and beautifully, I shall say) designed standard GUI components
[15:53] <dpm> to use as the building blocks for all user interaction. As such, you'll find labels, buttons, text boxes... all of the standard elements necessary to create a consistent and intuitive app.
[15:54] <ClassBot> JumpLink asked: will it be possible to develop mobile apps with gtk? That would make it easier to port some apps.
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
[15:55] <dpm> Right now we're basing our development toolkit on QML, so while technically possible, I'm not sure what kind of support there will be for developing GTK+ apps for the phone. We're focusing our efforts on developing apps on the QML toolkit only, as it's proven to scale well to different form factors on different devices
[15:56] <ClassBot> tuxfan_ asked: go-mobile recomends 12.10...can it be installed in 12.04 too?
[15:57] <dpm> It can now, but the level of support might not be the same as on 12.10. I believe installing on 12.04 should work already, but if you've got issues, try searching on ask ubuntu for instructions from folks who've already installed it
[15:57] <dpm> The next step in the process is to run the tutorial to get a taste for a real-world working example and having you wanting to get more :)
[15:57] <dpm> But as we're running out of time, what I'll do is to point you to it and let you run through it on your own time:
[15:57] <dpm>  
[15:57] <dpm> http://developer.ubuntu.com/resources/app-developer-cookbook/mobile/currency-converter-phone-app
[15:57] <dpm>  
[15:58] <dpm> What's been really overwhelming is that our community has already been creating lots apps with the Ubuntu SDK preview, which is pretty amazing when you think there still isn't a device for Ubuntu for phones available to them yet!
[15:58] <dpm> Have a peek:
[15:58] <dpm> https://plus.google.com/u/0/communities/111350780270925540549/stream/7914b6fd-cb15-485c-a50a-cd18b7768c2d
[15:58] <dpm> They all look stunning
[15:58] <dpm> As a taster, also have a look at this full-fledged Podcast client written by our friend Stuart Langridge (aquarius) in just a few lines of code
[15:58] <dpm> http://paste.ubuntu.com/1564468/
[15:59] <dpm> You can save it as a .qml file and run it with qmlscene filename.qml once you've installed the SDK preview
[15:59] <dpm> Anyway, time to go,
[15:59] <dpm> If you want to learn more, join Michael Hall and myself next Friday at 15:00 UTC in a public developer hangout, where we'll be talking in detail and answering all of your questions about this project and the phone developer story
[15:59] <dpm> thank you for your time and questions!
[16:00] <dpm> Next up, the awesome Bhavani Shankar will be talking about the Ubuntu App Review Board
[16:00] <dpm> coolbhavi, the floor is yours!
[16:00] <coolbhavi> :) thanks dpm
[16:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html following the conclusion of the session.
[16:00] <coolbhavi> for the cool session
[16:01] <coolbhavi> Alright. Hi All and welcome to my session on introduction to ubuntu app review board, who are we and what we do
[16:01] <coolbhavi> Here is a short intro on me (for those who dont know me :)): I am Bhavani Shankar a Ubuntu developer, currently serving on the Application Review Board and LoCo council in Ubuntu.
[16:02] <coolbhavi> == Who is the Ubuntu App review board and why are we here? ==
[16:02] <coolbhavi> The Application Review Board (ARB) is the team governance council for assessing post-release applications in ubuntu and releasing them into the software center through -extras repository.
[16:02] <coolbhavi> == Our Process ==
[16:03] <coolbhavi> Our process mainly consists of 3 main parts:
[16:03] <coolbhavi> First, when someone uploads their app into myapps portal (https://myapps.developer.ubuntu.com/dev/) we do the following checks primarily:
[16:03] <coolbhavi> We check for the contents of the app as per arb guidelines, check if the app runs as expected, packaged as per arb guidelines. (and vote on them)
[16:04] <coolbhavi> Secondly, Once the compliance checks above are complete we do a qa check after uploading to extras repository.
[16:04] <coolbhavi> Thirdly we publish the app if everything is fine wrt step 1 and 2
[16:05] <coolbhavi> Any questions?
[16:06] <ClassBot> anish1307i asked: arb guidelines ?
[16:06] <coolbhavi> anish1307i, I am going to explain the same in detail as the session goes on :)
[16:07] <ClassBot> jierro asked: how many dudes are in ARB?
[16:08] <coolbhavi> jierro, currently there are 5 members on the ARB https://launchpad.net/~app-review-board/+members#active
[16:08] <coolbhavi> so moving ahead...
[16:09] <coolbhavi> == Seems interesting? Here is a bit more info on the process ==
[16:09] <coolbhavi> == Our general goal ==
[16:09] <coolbhavi> Our focus is on lightweight apps. To give you a general idea, we're looking for the kind of apps that could be reviewed for functionality and security in about an hour reading through the code. We'll also do a licensing and packaging review.
[16:10] <coolbhavi> Submissions should be applications, not stand-alone documentation or media (image bundles, fonts, movies) and we review only free apps
[16:11] <coolbhavi> Apps should not be forks or updates of existing applications in the Ubuntu archive (main/universe/etc).
[16:11] <coolbhavi> Apps should be well integrated into the desktop, working well with the Dash and Launcher. The ARB reviews graphical apps, not command-line apps.  (for the sake of simplicity in reviewing)
[16:12] <coolbhavi> == Content ==
[16:12] <coolbhavi> Content must be suitable under the terms of the Ubuntu Code Of Conduct
[16:13] <ClassBot> bobweaver asked: with more and more developer's every day has there been a movement at all to get more then just X amount of people to ARB ?
[16:14] <coolbhavi> bobweaver, thats the precise reason we are working on automating the review process which I ll come to at a later stage
[16:14] <ClassBot> jincreator asked: If ARB review only free apps, then who review non-free apps?
[16:15] <coolbhavi> jincreator, there is a separate queue for commercial apps handled by the myapps team in a separate queue
[16:16] <ClassBot> jierro asked: and who review heavyweight programs?
[16:18] <coolbhavi> jierro, if you want some app with a lot of features and code functionalities and other functionalities included which is beyond the scope of lightweight apps defined by the ARB, one could go through the normal sponsorship queue in ubuntu
[16:18] <coolbhavi> Applications must be Free/Libre/Open Source software. We follow the Ubuntu Licensing Policy. (http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-ulp)
[16:19] <coolbhavi> Apps should be useful or interesting to a general audience.
[16:19] <coolbhavi> Apps must be able to be built with tools & libraries in the Ubuntu archive. Apps may bundle additional libraries they depend on, but may not include new versions of already packaged libraries.
[16:20] <coolbhavi> == Running of the app ==
[16:20] <coolbhavi> running of the app on a machine covers the below points:
[16:20] <coolbhavi> Application runs correctly
[16:21] <coolbhavi> Major features operate as expected
[16:22] <coolbhavi> most importantly, Does not perform any malicious actions (like accessing/modifying system files)
[16:22] <coolbhavi> == Packaging of the app ==
[16:22] <coolbhavi> The application is well packaged using the Debian packaging system
[16:23] <ClassBot> jierro asked: what is going on with apps from "Ubuntu App Showdown", that are still not in Software Centre?
[16:25] <coolbhavi> jierro, due to the transition from manual reviews to automated reviews, and since most people contribute in their free time, reviews are going on at a slow pace and we are trying our level best to speed up reviews and include the apps into USC
[16:26] <coolbhavi> which we will definitely do in due course of time
[16:26] <coolbhavi> The application is well packaged using the Debian packaging system
[16:26] <coolbhavi> All correct dependencies are met
[16:27] <coolbhavi> Application installs cleanly
[16:27] <coolbhavi> Application can be removed cleanly
[16:28] <coolbhavi> Includes suitable copyright and licensing content
[16:28] <coolbhavi> Application integrates into the desktop, with appropriate Launcher or menu entries
[16:29] <ClassBot> JumpLink asked: the same applies for a new (developer) library instead a app?
[16:29] <coolbhavi> JumpLink, I'll cover the packaging requirements in detail next as its pretty strict
[16:30] <coolbhavi> == A bit more info on packaging guidelines which is pretty strict ==
[16:30] <coolbhavi> We greatly prefer source tarballs with a standard versioning scheme, such as foobar-1.2.3.tar.gz or foobar_1.2.3.orig.tar.gz, that unpacks into a directory named foobar-1.2.3.
[16:31] <coolbhavi> The version for your package in debian/changelog should use the format <upstream>-0extras<ubunturelease>.<packagerev> where packagerev starts at 1 with the first upload. Example: 1.2.3-0extras11.10.1 for the first upload of a package with the upstream version 1.2.3. [Note: This is different from the standard requirements for Debian/Ubuntu packages]
[16:32] <coolbhavi> wherein we use 0ubuntu1 and target it at the main repositories for instance
[16:33] <coolbhavi> you need to have just one entry for each version that's published to Extras.
[16:33] <coolbhavi> (in debian/changelog)
[16:34] <coolbhavi> Make sure the target distro in debian/changelog is the current release of Ubuntu, not an older version, or the development version that hasn't been released yet.
[16:35] <coolbhavi> Your package should install most files in /opt/extras.ubuntu.com/<packagename>. This includes all libraries, binaries, and configuration files, much as a part of avoiding namespace conflicts if any, with extras
[16:35] <coolbhavi> However there are a few exceptions:
[16:37] <coolbhavi> copyright, changelog, and other example files pertaining to the app is allowed to be installed in /usr/share/doc/<packagename>
[16:38] <coolbhavi> The .desktop file is allowed to be installed in /usr/share/applications with the only condition that it should have a extras prefix to it
[16:38] <coolbhavi> Example: extras-foobar.desktop for a package named foobar.
[16:40] <coolbhavi> Same condition goes with any lenses too which are allowed to be installed in their standard locations  but with an extras prefix to the service
[16:41] <coolbhavi> As a side note: this link provides info on some of the awesome apps we received during the app showdown: http://www.omgubuntu.co.uk/2012/08/ubuntu-app-showdown-winners-announced
[16:42] <coolbhavi> == Seems bit too complex? ==
[16:43] <coolbhavi> There is no need to worry as we are automating the process above (as a  after result of our wildly successful recent app developer showdown http://developer.ubuntu.com/showdown/apps/ wherein we reviewed 133 cool apps in a single week)
[16:43] <coolbhavi> The whole spec is here: https://wiki.ubuntu.com/AppDevUploadProcess
[16:44] <coolbhavi> on which we have started working (Presumably lengthy for a first read)
[16:46] <coolbhavi> We hope to have everything in place for 14.04 (and on a personal note, have contributed creation of a lintian profile to check arb-package compliance towards the same)
[16:49] <coolbhavi> and any help in implementing the spec or help in manual reviews as of now (As more hands speed up the review process and the voting process which is a +2 votes currently for an app to get through) You can join the app review contributors team here: https://launchpad.net/~ubuntu-app-review-contributors
[16:50] <coolbhavi> and start reviewing apps which come on the ARB queue
[16:50] <ClassBot> There are 10 minutes remaining in the current session.
[16:52] <coolbhavi> and of course our eternal gratitude will be there with you for your offer of help :)
[16:52] <coolbhavi> Thats it pretty much from my side and the floor is open to any questions.
[16:53] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html
[16:56] <coolbhavi> JumpLink,  basically you ll need to use the software in the ubuntu archives but it can be allowed if it runs in your program as expected
[16:58] <coolbhavi> Original question was <JumpLink> QUESTION: E.g. the JavaScript environment Node.js is not in the Ubuntu archive, is it allowed to use node.js if I install it to /opt / extras.ubuntu.com / <packagename>?
[16:58] <ClassBot> There are 10 minutes remaining in the current session.
[16:59] <ClassBot> There are 5 minutes remaining in the current session.
[16:59] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html following the conclusion of the session.
[17:00] <ClassBot> There are 10 minutes remaining in the current session.
[17:00] <ClassBot> There are 5 minutes remaining in the current session.
[17:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html following the conclusion of the session.
[17:01] <JoseeAntonioR> Hey, guys! You can check the next session at www.ubuntuonair.com
[17:04] <achiang> http://pad.ubuntu.com/9J5hd9GmQK
[17:08] <achiang> If you are on raring, simply:
[17:08] <achiang> $ sudo apt-get install apport-valgrind
[17:09] <achiang> If you are on an older release, create a raring chroot and then:
[17:09] <achiang> $ apt-get source apport-valgrind
[17:09] <achiang> Alternatively, download the following:
[17:09] <achiang> https://launchpad.net/ubuntu/+archive/primary/+files/apport_2.8-0ubuntu2.diff.gz
[17:09] <achiang> https://launchpad.net/ubuntu/+archive/primary/+files/apport_2.8-0ubuntu2.dsc
[17:09] <achiang> https://launchpad.net/ubuntu/+archive/primary/+files/apport_2.8.orig.tar.gz
[17:09] <achiang> And extract with:
[17:09] <achiang> $ dpkg-source -x apport_2.8-0ubuntu2.dsc
[17:09] <achiang> You will also need a newer valgrind, which can be obtained:
[17:09] <achiang> https://launchpad.net/~jtaylor/+archive/jtaylor
[17:09] <achiang> You will also want:
[17:09] <achiang> $ sudo apt-get install ctags cscope
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html following the conclusion of the session.
[18:02] <balloons> Hello everyone
[18:03] <balloons> My name is Nicholas Skaggs, I'm the QA community coordinator..  Recently, we've taken up using autopilot to help meet our automated testing needs. So today I'll be talking about what autopilot is, how it works, and how you might be able to use it yourself for your application
[18:03] <balloons> With me today is Thomi, I'll let him introduce himself as well
[18:04]  * thomi waves
[18:04] <thomi> I'm THomi Richards - I work for Canonical on a number of different projects focused around the desktop & automated testing. I'm here because I'm one of the main authors of autopilot, so hopefully I can help answer any questions you might have....
[18:04] <thomi> it's also really early in New Zealand, so if I don't make sense, I probably just need more coffee
[18:04] <balloons> yes, do thank thomi for getting up early to hang out with us :-)
[18:04] <balloons> so let's begin shall we
[18:05] <balloons> first of all, what is autopilot exactly?
[18:05] <balloons> Well, as eluded to, autopilot is an automated testing tool, originally developed by the unity team for testing unity.
[18:05] <balloons> The goal of autopilot tests is to provide higher level application and functional testing. The tests are written in python and can be user executed or scripted via a test runner such as UTAH or jenkins to run and publish results automatically.
[18:06] <balloons> So what can it do? Well, autopilot can be used to perform functional testing of an application.
[18:06] <balloons> Practically, this means you can simulate user input and drive your application just like a human would. If you have unit tests and build tests for your application, adding autopilot tests will help you to ensure the application actually executes properly when interacted with by a user.
[18:07] <balloons> This allows you to add that final level of what might be called acceptance testing of your application in an autmated way
[18:07] <thomi> Right - autopilot provides a very high-level test. The goal is to simulate user input, and verify that your application does what's expected of it.
[18:08] <balloons> Now, this all sounds good, so you might be asking how this is different from other testing tools
[18:08] <balloons> I'll let thomi pitch in here as well, but.. The unique part of autopilot is that it doesn’t rely on doing screengrabs to interpret application interaction. Instead, the autopilot team has implemented dbus introspection to allow you to machine read the data driving the application interface instead.
[18:08] <balloons> This allows you to read the values being displayed by the application without having to visually look at them. The upsides of this are the ease of maintenance and writing the test. The potential downside is that it does not verify how the application actually appears, since it is not “looking” at it. (Though I will posit you could probably add an assertion to do this, haha!)
[18:10] <thomi> Right - autopilot relies on having code execute inside the application under test. This is easy for the Unity shell (since we wrote it), and for Gtk & Qt applications we have our own autopilot plugin that we persuide the application under test to load for us. THese plugins export internal application values over DBus, for your autopilot tests to read.
[18:11] <thomi> balloons: correctly identified that you cannot verify how something actually looks on the monitor with autopilot. However, hopefully your GUI framework of choice (Gtk+, Qt) contains those sorts of tests. In practise, we haven't missed this functionality at all.
[18:11] <balloons> So, how do you get it? Well autopilot is in the repository since precise I believe..
[18:11] <balloons> but I’d encourage you to get the latest upstream version by installing from the ppa. Upstream development is still happening fast, so it’s nice to use the latest and greatest ;-)
[18:11] <balloons> sudo add-apt-repository ppa:autopilot/ppa
[18:11] <balloons> sudo apt-get update && sudo apt-get install python-autopilot
[18:13] <thomi> balloons: not sure about precise. Quantal & onwards I believe. The application plugins are in the autopilot PPA, so you may want to add 'ppa:autopilot' to your system in order to get them
[18:13] <thomi> If you're running raring, autopilot is released almost daily into the OS, so... yay!
[18:13] <balloons> ^^ :-)
[18:14] <balloons> So, before we delve into the details of how this works, let me show you an example testcase from unity so you can see how a testcase looks
[18:14] <balloons> http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/tests/autopilot/unity/tests/test_home_lens.py
[18:15] <balloons> for those of you familar with xunit tests, you'll feel right at home here
[18:16] <thomi> Autopilot is built on top of the standard python test tools, so we try and keep the structure as simple as possible
[18:16] <balloons> you can probably follow along with what's going on inside the testcase... you have a setup and teardown step which is run before and after each test respectively, and then (in this case) one test function defined
[18:18] <balloons> We'll talk more about writing these testcases in a few mins.. for now, I'd like to ask thomi to talk a little bit about the technical side of autopilot
[18:18] <balloons> please, feel free to ask question as we go.. just prefix your question with 'QUESTION:' in the chat
[18:18] <thomi> sure. I won't go into too much detail, because test authors don't need to know too much about how things work under the hood, but...
[18:18] <balloons> :-)
[18:18] <thomi> as an example, another unity test suite: http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/tests/autopilot/unity/tests/test_spread.py
[18:19] <thomi> this one tests the spread functionality of the launcher icons.
[18:19] <thomi> err, I mean "application windows"
[18:19] <thomi> in the AP test, where we access a python attribute like "self.window_manager.scale_active", we're actually causing a DBus round-trip to the application under test
[18:20] <thomi> so under the hood, autopilot is creating a query that asks unity to provide updated state for the WindowManager object
[18:20] <thomi> when autopilot gets that new information back, it can then pass the new value to python, and the test can be evaluated.
[18:21] <thomi> To run autopilot tests, you can use any standard python test runner
[18:21] <thomi> so, nosetests, testtools, unittest, whatever. *or*, you can use autopilot itself
[18:21] <thomi> autopilot gives you a number of features that other test runners don't, including:
[18:22] <thomi>  * You can record videos of failed tests. We use this *a lot* for the Unity tests. They're run automatically on a jenkins machine, and failed tests appear both as a test result inside jenkins, and as a video/build artifact.
[18:22] <thomi>   this makes it really easy to 'see' why a test is failing on the test machine.
[18:23] <thomi>  * We can also save test results to Junit XML file format, which makes jenkins integration much easier
[18:24] <thomi> So... I'm sure I've forgotten things - any questions about the technical side of autopilot at ths stage?
[18:25] <balloons> if not, let's talk a bit about writing the cases
[18:25] <balloons> I want to mention some resources available to everyone for help
[18:25] <balloons> This friday we’re having a hackfest were we’re encouraging people to come out, learn about autopilot (and autopkg) automated testing, and to contribute some tests. https://wiki.ubuntu.com/QATeam/AutomatedTesting/Hackfest. We’ll give a demo and be on-hand to guide you through contributing and writing tests.
[18:26] <balloons> If your interested in learning to write testcases, attending the session is an excellent place to start. If your not able to attend, the videos will be available afterwards and #ubuntu-quality is always a good place to get help. The autopilot guys as well as myself and other testwriters all idle in the channel.
[18:27] <balloons> In the meantime, please do check out the resources available to you. The official autopilot documentation is a great place to start.
[18:27] <thomi> also, people should feel free to ping me on IRC and ask questions - I might not be awake, but I'll answer them when I see them
[18:27] <balloons> Here's the links to the docs:
[18:27] <balloons> http://unity.ubuntu.com/autopilot/
[18:27] <balloons> Note that the website is still missing docs (build error :-(, we’ll get it fixed), but once you’ve installed autopilot you have a full documentation set locally on your machine. I would encourage you to use this documentation.
[18:27] <balloons> file:///usr/share/doc/python-autopilot/html/tutorial/getting_started.html
[18:27] <balloons> Finally, there is a set of tutorials I have written on my blog that guide you through writing your first autopilot testcases:
[18:28] <balloons> http://www.theorangenotebook.com/2012/11/getting-started-with-autopilot.html
[18:28] <balloons> http://www.theorangenotebook.com/2012/11/our-first-autopilot-testcase.html
[18:28] <balloons> http://www.theorangenotebook.com/2013/01/introspecting-with-autopilot.html
[18:28] <balloons> I owe thomi getting this into the official documentation ;-)
[18:29] <balloons> Last bits of the last session, hang in there everyone :-) Let's talk a bit more now about how ubuntu uses autopilot as an example of how it can help contribute to your application development and release process
[18:30] <balloons> As mentioned, the unity team originally created autopilot to solve their needs for automatically functionally testing unity. This allowed them to test and assure that the designed and coded features actually performed as expected when interacted with by the user. Being a primarily user interaction application, the need for something like autopilot to test was vital.
[18:31] <thomi> Right - this was for the precise release. We needed a way to automatically detect when we'd broken a feature.
[18:31] <balloons> I would encourage you to read a bit about how autopilot plays a role in there release process by reading the excellent articles didrocks has posted on the subject (Unity: release early, release often… release daily!) http://blog.didrocks.fr/
[18:32] <balloons> In addition, we as a ubuntu quality community team are utilizing autopilot to help with our testing efforts. Currently, we’re focused on getting tests for our desktop applications, with the goal of also using autopilot to automate image installations and do other useful tests :-) There is a project page for our work here:
[18:32] <balloons> https://launchpad.net/ubuntu-autopilot-tests
[18:32] <balloons> If your interested in helping, please do come out to the hackfest this friday.
[18:32] <balloons> https://wiki.ubuntu.com/QATeam/AutomatedTesting/Hackfest
[18:32] <balloons> thomi, if you would like to say anything more about how unity uses ap, jump in now ;-) Then we'll field questions
[18:33] <thomi> sure
[18:33] <thomi> so we've been building a test suite since precise
[18:33] <thomi> Right now we have pretty good coverage we have....786 tests in the unity test suite
[18:34] <thomi> which takes over an hour to run right through
[18:34] <thomi> we test all of the main unity components - the dash, launcher, panel, etc...
[18:34] <thomi> we *require* a new feature branch to have an autopilot test before it gets merged
[18:35] <thomi> since the precise release, autopilot has helped us catch *lots* of regressions before we release Unity
[18:35] <thomi> resulting in a more stable & usable development release.
[18:35] <thomi> We also run the unity AP tests over a selection of different hardware
[18:36] <thomi> including machines with ati, nvidia, and intel gfx chipsets, to help catch issues where nux has some bad interactions with the graphics drivers
[18:36] <thomi> we also test with both the free and proprietary drivers
[18:36] <thomi> so... I think the best thing now is to answer questions you may have
[18:37] <ClassBot> manavakos asked: how do we get autopilt? simple apt-get?
[18:37] <thomi> yup - simple apt-get - if you're in raring. Even then, it's best to have the autopilot PPA added. We're hoping to make sure everything is released into Ubuntu proper before too long
[18:38] <balloons> The autopilot ppa is sudo add-apt-repository ppa:autopilot/ppa
[18:38] <ClassBot> manavakos asked: so autopilot is a tool for testing ANY kind of code or of a specific language (python)?
[18:38] <thomi> autopilot is still in very active development, so things change all the time, so the PPA really is your best bet. If you have any problems, ping myself or balloons
[18:39] <thomi> Autopilot can test any Qt4, Qt5, or Gtk+ application (or Unity), but your tests must be written in python
[18:39] <balloons> thomi, so I can't write my tests in smalltalk?
[18:39] <balloons> :-p
[18:39] <thomi> so a typical application will have a C++ component for the actual application, and a python component for the tests
[18:39] <thomi> smalltalk..... no.. just.. no
[18:40] <ClassBot> epikvision asked: What's a unit test and a build test?
[18:40] <balloons> I think this is a good question we can address actually.. So we are saying autopilot fits in the testing strategy as a functional or acceptance testing tool
[18:41] <thomi> right - A unit test is a test that verifies a single unit of code - hopefully a single function. It's written in the same language as the application itself
[18:41] <thomi> so unit tests are about testing very low level functionality - you care about a certain function working as it should...
[18:42] <thomi> autopilot tests, on the other hand, are very high-level tests - we care about the functionality of the applicaton, rather than any specific piece of code
[18:42] <thomi> you need both levels (and a few in-between) in order to have any confidence in your application
[18:42] <thomi> so Unity also has unit tests, written in C++ and using the gtest framework
[18:42] <thomi> ...but that's a discussion for another day :)
[18:43] <balloons> indeed :-) It's important to have tests addressing the different levels to help ensure your application is performing correctly
[18:44] <thomi> We picked python as the language for autopilot because Canonical, and the Ubuntu community in general have many python testing experts.
[18:44] <thomi> so we've got a great body of knowledge around how to write good tests in python :)
[18:44] <thomi> compared to say.. ruby...
[18:44] <balloons> I won't spout on too much about this, but if your curious, google and wikipedia are your friends -- try looking at release and testing methodologies to see a more complete picture of generically how the levels work
[18:45] <balloons> alright, any other questions?
[18:45] <thomi> AMA :)
[18:46] <ClassBot> balloons asked: Do I need to modify my application to use autopilot?
[18:47] <thomi> derp derp
[18:47] <thomi> as long as you haven't prevented Qt/Gtk from loading plugins, then you don't need to modify your application to load the autopilot plugin
[18:47] <thomi> however
[18:48] <thomi> it helps *a lot* if the objects in your application have sensible names
[18:48] <thomi> you use these names in your test to retrieve the objects you care about
[18:48] <thomi> so please - Qt authors, name your objects!
[18:48] <thomi> (I'm sure you do this already)
[18:48] <thomi> but apart from naming your objects sensibly, No: autopilot doesn't require you to change / rebuild your application
[18:49] <thomi> (which is kind of cool) :)
[18:49] <thomi> any other questions?
[18:49]  * thomi glares at balloons
[18:50]  * balloons smiles
[18:50] <balloons> alright, thanks everyone for coming out (and/or reading this log)
[18:50] <ClassBot> There are 10 minutes remaining in the current session.
[18:50] <thomi> I'd encourage people interested in contributing to Ubuntu to help balloons out and start writing AP tests. It's a great way to get involved without having to learn the application internals
[18:51] <thomi> I'm on IRC 24/7, but only awake some of the time. I'm more than happy to help people out when they have questions
[18:51] <balloons> An for application developers, it's a great way to bridge your testing needs easily
[18:51] <balloons> Let's leave some contact information in case you'd like to follow-up
[18:52] <balloons> for myself, I'm balloons on IRC, ping me anytime.. My launchpad page is here and it has other forms of contact info like email as well
[18:52] <balloons> https://launchpad.net/~nskaggs
[18:52] <balloons> #ubuntu-quality is the place to be if you have questions
[18:52] <thomi> I'm also in #ubuntu-quality, and my contact details are listed here: https://launchpad.net/~thomir
[18:53]  * thomi waves
[18:54] <ClassBot> epikvision asked: Is it recommended to do ap on raring?
[18:54] <thomi> yes
[18:54] <thomi> :)
[18:55] <thomi> we update AP all the time, and those new features are only released to raring
[18:55] <balloons> same here if you want to contribute tests to the community project
[18:55] <balloons> raring is our focus for testing
[18:55] <balloons> plus ap has the goodies on raring
[18:55] <ClassBot> There are 5 minutes remaining in the current session.
[18:55] <ClassBot> manavakos asked: what kind of help can we provide, could you be a bit more specific??
[18:55] <balloons> hopefully this answers it for you, but you can do a couple things
[18:56] <balloons> 1) if your an app developer, adopt autopilot and write some tests for your app.. We'll thank you and your users will too :-) not to mention, you'll thank yourself for easier debugging and regression prevention ;)
[18:57] <balloons> 2) If your interested in contributing to ubuntu, learn to write autopilot tests.. We need tests for ubuntu default applications, image installation, and other things we probably haven't thought of yet
[18:58] <balloons> We are happy to take your contribution and help you learn about writing tests.. it's a great way to be invovled
[19:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html following the conclusion of the session.
[19:01] <mhall119> hello everyone
[19:01] <mhall119> for this session I'm going to be talking about how to integrate applications with the Unity desktop
[19:03] <mhall119> which means using the available APIs to add information about your app (or an existing app) to the Unity launchper, indicators, and notifications
[19:04] <mhall119> I'm going to start off with the simplest things you can do to improve how an application looks and works on Ubuntu
[19:04] <mhall119> first of all, provide a hi-resolution icon for the app
[19:05] <mhall119> Unity shows larger icons than Gnome 2.x used in many places, the dash, the launcher and the apt-tab switcher
[19:05] <mhall119> if the app only provides smaller bitmap images, they will be up-scaled to fit, and that doesn't look very good
[19:05] <mhall119> providing large bitmaps (128x128) helps improve the look of the app in Unity
[19:06] <mhall119> SVG icons are even better, as they can be scaled to exacly the right size while staying perfectly clear
[19:07] <mhall119> secondly, there are some easy things you can do with the application's .desktop file to improve it's integration, without any code changes
[19:07] <mhall119> the first of these is the Keywords field
[19:07] <mhall119> Unity uses this field when searching in the Dash, along with the name and description fields
[19:08] <mhall119> so if you have a text editor, it should include "Text" and "Editor" in the Keywords
[19:08] <mhall119> and any other keywords you think a user might search for when they want your application
[19:09] <mhall119> the second thing you can do with the .desktop file is add actions
[19:09] <mhall119> Actions are a new addition to the XDG specification: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions
[19:09] <mhall119> in Unity, these actions become Quicklist entries in the launcher, which can be accessed even when the application isn't running
[19:10] <mhall119> Actions can be anything that you can trigger from the command-line
[19:10] <mhall119> again, this does not require any code change, just changes to the text in the .desktop file
[19:11] <mhall119> alright, those are the easy ones, any questions so far?
[19:11] <ClassBot> manavakos asked: can you give an example of an "action"? what yould one write on the command line?
[19:11] <mhall119> an Action is represented as a sub-section in the .desktop file
[19:12] <mhall119> a common one is to start a new window of an app
[19:12] <mhall119> so you'd create a new section at the bottom of the .desktop called:
[19:12] <mhall119> [Desktop Action NewWindow]
[19:12] <mhall119> and inside that you would have:
[19:12] <mhall119> Name=Open a New Windows
[19:13] <mhall119> Exec=yourexecutable --new-window
[19:13] <mhall119> assuming your application takes a --new-window flag
[19:13] <mhall119> you can see more examples of this here: http://developer.ubuntu.com/resources/technologies/launcher/
[19:14] <mhall119> and also the XDG specification link I pasted earlier
[19:14] <mhall119> alright, now let's get into what you can do inside the application itself
[19:15] <mhall119> the Actions mentioned above are called "static" Quicklist actions, because they can be accessed even when your application isn't running, but they don't change
[19:15] <mhall119> you can also have a "dynamic" Quicklist, which can be updated from the application's code itself
[19:16] <mhall119> if you scroll down a little bit further on the above link, you will see python examples of how to do this
[19:16] <mhall119> but basically you create a new LauncherEntry object for your .desktop file, then attach a DBusMenu to it
[19:16] <mhall119> unlike static quicklists, you can add or remove entries from this dynamic menu
[19:17] <mhall119> you can also use different menu entry types, such as a checkbox or radio selection
[19:17] <mhall119> and of course you connect these menu items to callback functions in your code
[19:18] <mhall119> in addition to dynamic quick lists, you can also add status information to your LauncherEntry that will be displayed on your application's Launcher icon
[19:18] <mhall119> For example, you can set the "count" property, which will show a number in the upper-right corner of your icon
[19:19] <mhall119> this is used to indicate new messages in Thunderbird, for example
[19:19] <mhall119> you can also set the "progress" property, which will draw a progress bar across the middle of your application's icon
[19:20] <mhall119> and finally, you can set the "urgent" propery, which will make your application's icon wiggle and catch the user's attention
[19:20] <mhall119> any questions on Launcher integration?
[19:21] <mhall119> ok, moving on
[19:21] <mhall119> if your application deals with messaging at all, then you probably want to integrate it with the Messaging Menu
[19:22] <mhall119> this is useful to let the user know when they have new messages, or how long ago a message was received
[19:23] <mhall119> now the API for this changed with 12.10, but the way it works is essentially the same
[19:24] <mhall119> you create a new MessagingMenu object with your application's .desktop file
[19:24] <mhall119> which, like the Launcher, is where it gets the icon and name to display
[19:24] <mhall119> from there you can add as many "sources" as your application needs
[19:25] <mhall119> for example, Thunderbird uses a source per mail folder
[19:25] <mhall119> Empathy uses a source per user
[19:25] <mhall119> you can give your source either a count, or a time
[19:26] <mhall119> the Count is simply displayed as it is, next to the source label
[19:26] <mhall119> the time, however, is show as the amount of time between it and the current time
[19:26] <mhall119> so Unity handles updating that as time passes
[19:27] <mhall119> you can also tell the Messaging Menu whether or not to get the user's attention, which wil change the icon's color
[19:27] <mhall119> your sources can also be given a callback function that is executed when the user clicks on it in the MessagingMenu
[19:28] <mhall119> any questions on the MessagingMenu?
[19:28] <mhall119> documentation on that can be found here: http://developer.ubuntu.com/resources/technologies/messaging-menu/
[19:28] <mhall119> and the new API docs are here: http://developer.ubuntu.com/api/ubuntu-12.10/python/MessagingMenu-1.0.html
[19:29] <mhall119> alright, moving on to the Sound Menu
[19:29] <mhall119> this is a little less common for apps to integrate with, but it's useful if you are doing anythign with multi-media playback
[19:30] <mhall119> once again, the process begins by using your application's .desktop file to create a new MusicPlayer instance
[19:30] <mhall119> this will put your application, along with it's icon, into the Sound Menu
[19:31] <mhall119> you can also connect callbacks for play/pause, previos and next, allowing the user to control your app from within the sound menu itself
[19:31] <mhall119> and, if your application has some concept of Playlists, you can add those to the Sound Menu as well
[19:32] <mhall119> documentation on all of this is available here: http://developer.ubuntu.com/resources/technologies/sound-menu/
[19:32] <mhall119> something new that was introduced in 12.10 is Unity Webapps integration
[19:33] <mhall119> what this does is exposes all of the APIs I've mentioned, the Launcher, MessagingMenu and SoundMenu, to javascript in the browser
[19:33] <mhall119> this lets any website that wants it, to integrate with your desktop to provide you with information
[19:33] <mhall119> these APIs are write-only, so you don't need to worry about website gaining information about you or your system
[19:34] <mhall119> but it means you can, for example, get gmail inbox counts without installing a separate script, or change tracks in Grooveshark without switching away from your code editor
[19:35] <mhall119> more information about integrating webapps can be found here: http://developer.ubuntu.com/resources/technologies/webapps/
[19:35] <mhall119> any questions before I move on?
[19:36] <mhall119> guess not
[19:36] <mhall119> ok, next up are Application Indicators
[19:36] <mhall119> these sit alongside the Messaging and Sound menus in the top Unity panel
[19:36] <mhall119> any application can add their own indicator
[19:37] <mhall119> as you would expect, this starts with your .desktop file, and creating a new AppIndicator object
[19:37] <mhall119> your indicator has 3 possible states, Active, Passive, and Attention
[19:38] <mhall119> both Active and Attention can have separate icons, Active being the default and Attention for when you want the user to do something
[19:39] <mhall119> When your AppIndicator is in the Passive state, the icon is not displayed on the Unity panel, but your AppIndicator code is still running
[19:40] <mhall119> And of course you can attach a Menu to your indicator
[19:40] <mhall119> These menus can contain either action entries, which just run a callback function
[19:40] <mhall119> the can also contain Checkbox and Radio entries, as well as separators
[19:41] <mhall119> Lastly we have Notifications
[19:41] <mhall119> Unity uses notify-osd to display unobtrusive message bubbles
[19:42] <mhall119> To create these, you would use the XDG Nofify API, which can support multiple back-end implementations, such as notify-osd
[19:43] <mhall119> the notification can contain an icon, a short title, and a longer body
[19:43] <mhall119> the background color, like other parts of Unity, is determined by the user's wallpaper
[19:44] <mhall119> notify-osd supports three different methods for notifications
[19:44] <mhall119> the first, and most common, is simply creating a new notification
[19:44] <mhall119> these are queued and displayed one at a time to the user
[19:45] <mhall119> you can also update a notification you have already sent, and if it is still being displayed Unity will swap out the text and icons for the new ones
[19:46] <mhall119> finally you can append body text to an existing message, which is helpful if more information becomes available while it is being displayed, but you don't want to completely replace the old information
[19:46] <mhall119> more information and examples for using Nofications is available here: http://developer.ubuntu.com/resources/technologies/notification/
[19:46] <mhall119> and those are the major integration points that are available to applications in Unity
[19:47] <mhall119> any questions about any of these areas?
[19:47] <mhall119> all of these APIs communicate over DBus to the Unity Shell, and can be implemented in a way that won't break the application if it's running in something other than Unity
[19:48] <mhall119> it's also worth pointing out that these APIs will be identical on all formfactors support by Ubuntu, which includes the desktop, TV, and the recently announced Phone
[19:49] <mhall119> so even if they may be visually different in the way they are displayed, from a developer's perspective you won't have to worry about where it is being run
[19:50] <mhall119> all of the documentation for these areas, as well as API docs for each, can be found on the Ubuntu Developer Portal, which I have been linking to throughout this session: http://developer.ubuntu.com/resources/
[19:50] <mhall119> and if there aren't any further questions, we'll call it a wrap for the day
[19:50] <ClassBot> There are 10 minutes remaining in the current session.
[19:50] <mhall119> thank you everybody for coming, and thanks to the volunteers who are coordinating these sessions and helping us instructors
[19:51] <mhall119> Be sure to come back tomorrow for the last day of UDW
[19:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:55] <JoseeAntonioR> Thanks everyone for being here today, we'll be back tomorrow at 15UTC! Make sure to not miss it!
[20:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-classroom.html