Archive for the ‘Desktop’ Category

Posted on February 8, 2010 - by jono

Ubuntu Opportunistic Developer Week: Call For Participation!

In the continued interests of helping to make Ubuntu rock as a platform for scratching itches and making awesome apps, I am putting together a new online learning event: Ubuntu Opportunistic Developer Week, happening online between 1st – 6th March 2010.

The week will be just like our previous online learning events such as Ubuntu Developer Week and Ubuntu Open Week, but instead providing a week jam packed with awesome sessions about writing applications that scratch your itch, and predominantly focusing on Python tools and frameworks, Bazaar, Launchpad and infrastructure. The goal for the week is give attendees a head start on a given technology useful for applications.

So, I am looking for volunteers. If you feel you could give a tutorial about a given Python module or associated technology (e.g. Glade, Launchpad, Bazaar etc), please drop me an email at jono AT ubuntu DOT com and I will liaise with you to get it scheduled. I am also look for some showcase sessions: stories about how you put together an application, how it scratched your itch and what tools you used. Thanks to everyone who contributes to leading a session!

The week has already been added as a Lernid event and I am going to encourage session leaders to create slides for their sessions. As each session is confirmed it will appear in Lernid and on the wiki page. Rocking!

Posted on February 4, 2010 - by jono

Project Awesome Opportunity

In the continued interests of making Ubuntu a rocking platform for opportunistic developers, today we formulated the plan for Project Awesome Opportunity. The goal is simple: build an opportunistic development workflow into Ubuntu. You will install one package from Universe and your Ubuntu will be hot-rodded for opportunistic application development, making development more fun and more accessible for a glorious itch scratching smackdown.

At the heart of the project is Ground Control by Martin Owens and Quickly by Rick Spencer and Didier Roche. I have been thinking about the challenges of how we build a great first incarnation of a platform optimised for opportunistic developers, and it struck me that we can divide the first set of tasks into three broad areas:

• Creating a Project – we need to help opportunistic developers ramp up as quickly as possible: they feel the itch and they are ready to scratch right away.
• Collaborating on a project – it should be really simple grab code, create a contribution and submit it to the project.
• Fixing a Bug – bugs are at the heart of software projects, and we should optimize the bug fixing process making it a doddle for opportunistic bug fixing developers to grab some code and make it work.

A key part of this workflow which I designed yesterday is the Fixing a Bug component, and this is something I am really passionate about us trying to deliver in the Lucid timeframe. This is not a formal project that my team is working on, this is something that I am focused on in my spare time and coordinating with Ground Control author and rock star, Martin Owens.

Let me explain how it works:

Opportunistic development lives in the Projects/ directory in your home directory. When you load this directory in Nautilus, you see this:

Ground Control places three buttons that identify the key use cases we are keen to satisfy. When the user clicks the ”Fix Bug” button the following dialog box appears

For the first cut of this feature a bug number is required, but the feature could also include a search box for finding bugs and even potentially have an option on the Launchpad project page saying ”Fix a bug on your desktop” (or some other descriptive term) and when you click that link, Nautilus opens up and is fed the bug number.

When a bug number is submitted, Ground Control will create a branch that the bug affects (typically trunk) into your Projects/ directory. You can then go and hack the code:

When a source file in the branch is changed (and ultimately the coder fixes the bug), we now see an ”Upload Fix” button:

At this point the branch has the fix committed, so the coder clicks the button and then sees this dialog box:

This dialog box asks for the following:

• The first box is the content that goes into the commit message.
• The second box is the content that goes into the merge proposal.
• The third box is optional additional characters for the branch name.

When the user clicks the OK button, the following process occurs:

• Bazaar commits to the local branch.
• The branch is pushed to the branch location specified.
• The branch is added to the bug report.
• A merge proposal is made.

So, I fleshed this idea out over the last few days and documented it and had a chat with Martin Owens who created Ground Control, and he has committed to finish off the current feature set of Ground Control and creating the Fix a Bug feature in the next two weeks. Martin has volunteered to invest a significant amount of time and effort into solving this problem in Ground Control, and I am going to be working to grow awareness of the project, handle the packaging in Universe, and help to get more people involved in testing and translations. See the Create a Project, Collaborate and Fix a Bug blueprints for this feature. Feel free to subscribe to them to track progress.

For this feature to flourish and for us to rock the socks off opportunistic developers everywhere, we are going to need your help, particularly with testing and where possible bug fixes. Here are the main ways in which you can help:

• Fixing Bugs – Martin is largely a one man band on this project and he needs help fixing Ground Control Bugs. If you are interesting in helping, see the bug list here and get involved. He will love you and I will hail you.
• Testing – Testing is critical to this project. We have a tight timeframe on this, so we need you to help. How do you test? Simple, grab the dailly PPA of Ground Control set up by the awesome Nathan Handler, test it and report bugs.
• Moral Support – Martin Owens is doctormo on Freenode. Ping him and tell him he is awesome. He and I hang out in #ubuntu-community-team: buy him a virtual beer.

So that is the goal. Let’s see if we can rock it and fire up more opportunistic developers.

Posted on January 30, 2010 - by jono

Connecting The Opportunistic Dots

Something I have talked about extensively recently has been my passion to see opportunistic developers served well on the Linux desktop. These kinds of programmers are people who want to write small, focused, fun little applications that scratch an itch, even if that itch is to have fun. These kinds of developers are having a whale of a time filling the iPhone App Store with scratch-your-itch type of applications, and I am really keen to see more of these kinds of applications on the Linux desktop, and making Ubuntu the perfect platform to develop them on.

We have been seeing a growing movement inside the Ubuntu community in helping to make Ubuntu a rocking platform for opportunistic developers. While all the components are Open Source and can be shipped on any distribution, I am really keen for Ubuntu to really optimize and integrate around the needs of opportunistic programmers and I just wanted to highlight some of the work that has happened here.

In much the same way that Linux/Apache/MySQL/PHP (LAMP) became a popular arrangement of tools for web development, we have been seeing a similar scenario in Ubuntu too, in which a set of tools work well together and are often preferred by developers. These are:

• Python – a simple, easy to learn, flexible and efficient high-level language.
• GTK – a simple, comprehensive and powerful graphical toolkit for creating applications.
• GNOME – the desktop environment that ships with Ubuntu, offering many integration facilities.
• GStreamer – a powerful but deliciously simple framework for playing back and creating audio, video and other multimedia content.
• Glade – an application for creating user interfaces quickly and easily, which can then be loaded right into your Python programs.
• DesktopCouch – a framework for saving content in a database that is fast and efficient, hooks neatly into Ubuntu One and is awesome for replication.

In Ubuntu land we love this framwork. Many of our applications are written using them and this helped make it simple for others to get involved and contribute patches and bug fixes. It has been interesting seeing many folks settle on the same set of tools.

There are of course may other tools and facilities that can augment this list, but this is a common foundation in many applications. Fortunately, all of these ship with an Ubuntu system except Glade, but you can install Glade 3 by using Applications->Ubuntu Software Center.

Many of you will have heard of Quickly which provides a devilishly simple way of generating a new application, hacking on the code, changing the GUI and saving it to bazaar. Quickly also provides some awesome features for uploading the code to Launchpad and releasing your program to others in a Personal Package Archive.

What I like about Quickly is that it automates much of repetition surrounding software development and it ultimately allows you to deploy software to a PPA which people can then download and use. Now, PPAs are a little more complicated to install right now: you need to know what a PPA is, know where to find it, and click a few things or enter some commands to switch it on. Fortunately, the rather awesome Ubuntu Software Center which everyone’s favourite Vogt…Michael Vogt…is developing, is going to be extended with functionality to better support PPAs. This, combined with the ratings and review features coming to the Ubuntu Software Center is pretty rocking. I am not sure of the specifics of how PPAs will be supported, but I believe they will first begin on visibility and then follow up with integration features later. If you want to get started with quickly take a look at this entry.

With Quickly able to get folks up and running with development, I wanted to make it easier for opportunistic developers to get their hands on code snippets and examples to learn from. As such, I created the Acire and Python Snippets projects. These projects provide a simple means in which you get access to a freely available regularly updated library of examples, across a range of different areas. With Acire you will always have a growing knowledge base of real code that you can read, run and share, and the community works together to regularly add to and support that knowledge base. The response so far has been great and you can read more about this in my previous blog post.

So, at this point we have all the tools needed to build applications, learn from code examples, and publish packages that ultimately will be visible in the Ubuntu Software Center. The one area that neither Quickly nor Acire has particularly served well is improving on how we collaborate together on software. Few Open Source projects have one sole developer, so we really want developers work well together, in conjunction with translators, documentation writers, bug triagers and more.

To do this we have the rather awesome Launchpad and Bazaar which are a doddle to use. Launchpad provides everything you need to work together on a software project and I have become a bit of a Launchpad fan as I have got used to using it. In my earlier days I tried Sourceforge, Trac and other systems, but Launchpad is rocking it for me.

While I love Launchpad and Bazaar, their integration in Ubuntu could have been better. As an example, to get code in and out of Launchpad so you can contribute to a project, you use the bzr command and the process typically works like this:

• You download some code from the Launchpad project with bzr.
• You branch the code: this effectively means making a duplicate directory of the code.
• In that duplicate directory you add a feature, fix a bug or make some other kind of improvement.
• You then commit your changes to your local branch: this effectively tells Bazaar of the changes you have made.
• You then upload your branch to Launchpad (this is called pushing a branch).
• The final step is to propose a merge. This is when you offer your branch and it’s changes to the project maintainer to merge into the main codebase. Launchpad ties together nicely with bzr to handle this process and has a web front end for doing code review.

Now, understanding how all this works and doing it a few times takes a little getting used to, and much of it is learning how to use the different bzr commands and how they hook in with Launchpad. Well, very recently my friend and yours Martin ‘doctormo’ Owens has released his Ground Control project which provides a graphical interface to the whole process by building it into the file manager in Ubuntu. I cannot tell you how bloody cool this is. It works a little like this:

• You create a Projects directory in your home directory.
• Click Places->Home Folder and go to the new Projects folder.
• In there you can see a button to login to Launchpad. Click the button, enter your username and password. Job done.
• You now see a a button where you can select a project to work on. Click on it, enter a project name, select it and it creates a new folder.
• Now go into the folder and there is a button to download the code. Click it, select a branch and the code is downloaded.
• You can now hack on your feature and a button will appear to commit your changes.
• Finally, you will then see a button to propose a merge. You enter some text to describe your change, and it is uploaded.

No commands. None. What I love about Ground Control is that it is highly contextual: it is built into the file manager and it only ever shows you a button for what you can do at that time. It is simple, quick and Martin has done a wonderful job with it. Go and see a video demo of Martin showing Ground Control here.

Ground Control is still very very new so expect bugs, but do give it a go, report bugs, and importantly, he is looking for help to make sure it has full translations support. If you have done this before, drop him a line. The Ground Control Launchpad project is here.

With each of these components we are seeing more and more gaps in the integration and ease of the development process getting filled. I am hugely excited about this and I am excited about it bringing more and more people to Ubuntu as a development platform and it ultimately generating more and more Free Software for us all to use. We still have a long road ahead though and plenty of good work yet to do. If you think there is a gap you can fill, come and help us rock it.

Posted on January 26, 2010 - by jono

Application Indicator Online Tutorial Today

Recently I have been talking about how stoked I am that we are solving the problems in the notification area with Application Indicators based on this spec from the KDE team. We are now shipping this functionality in Lucid with Rhythmbox, Nautilus, Empathy, XChat-GNOME, Lernid and other applications using it.

Application developers are pretty excited about the technology, and as such we have scheduled a tutorial session about how to make use of the application indicator framework as part of the awesome Ubuntu Developer Week. The session is today, the 26th Jan at 7pm UTC / 11am PST / 2pm EST lead by the always awesome Ted Gould. More info on joining the session is here or you can use Lernid to join really easily.

Posted on January 14, 2010 - by jono

Application Indicators Rocking The House

Something we have been spending some time working on in this cycle has been fixing the mess that is the system tray. This is based upon an awesome specification submitted to Freedesktop by KDE. The spec has been implemented by KDE, we have written an implementation for the GNOME panel and it will ship in Ubuntu 10.04 Lucid Lynx Alpha 2. We have also started adding application indicator support to many of the applications we ship in Ubuntu, and of course these patches are going upstream as they are written. I would to encourage GNOMErs to join the discussion on the XDG list regarding the spec.

I think the Application Indicator framework rocks. It solves a problem that has niggled me for years: with it system tray applets now have a consistent UI in terms of spacing, a unified left click to access the menu (no more confusing different left/right menus in different apps), you can scrub between icons, KDE applications render their application indicator menus in GNOME as GTK menus and vice versa and the whole shebang is a lot more accessible.

The Application Indicator team have produced C, Mono and Python bindings and documented it all on this wiki page. I wanted to have a play with it with Python so I knocked together a simple little script that demos how it works:

#!/usr/bin/env python
#
# [SNIPPET_NAME: Create an Application Indicator]
# [SNIPPET_CATEGORIES: Application Indicator]
# [SNIPPET_DESCRIPTION: How to create an application indicator and add items to it]
# [SNIPPET_AUTHOR: Jono Bacon <jono@ubuntu.com>]
# [SNIPPET_LICENSE: GPL]

import pygtk
pygtk.require('2.0')
import gtk
import appindicator

class AppIndicatorExample:
    def __init__(self):
        self.ind = appindicator.Indicator ("example-simple-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS)
        self.ind.set_status (appindicator.STATUS_ACTIVE)
        self.ind.set_attention_icon ("indicator-messages-new")
        self.ind.set_icon("distributor-logo")

        # create a menu
        self.menu = gtk.Menu()

        # create items for the menu - labels, checkboxes, radio buttons and images are supported:

        item = gtk.MenuItem("Regular Menu Item")
        self.menu.append(item)

        check = gtk.CheckMenuItem("Check Menu Item")
        self.menu.append(check)

        radio = gtk.RadioMenuItem(None, "Radio Menu Item")
        self.menu.append(radio)

        image = gtk.ImageMenuItem(gtk.STOCK_QUIT)
        image.connect("activate", self.quit)
        self.menu.append(image)

        self.menu.show()

        self.ind.set_menu(self.menu)

    def quit(self, widget, data=None):
        gtk.main_quit()


def main():
    gtk.main()
    return 0

if __name__ == "__main__":
    indicator = AppIndicatorExample()
    main()

To make this as helpful as possible for people I have added it to python-snippets which you can of course enjoy using my little Acire tool that I blogged about recently. If you want to give it a go, I recommend you use it with another app that uses Application Indicators, and then you can play with scrubbing between icons and using the arrows on your keyboard to move around. It is pretty awesome.

To continue playing with it I thought I would have a go at writing an application indicator plugin for the always awesome Getting Things GNOME. I only had time spend an hour or so on it last night, but my work in progress is available in this branch. Most of it is complete, but what I am missing from the framework is a signal when a user clicks on the indicator icon: I need this to re-generate the dynamic list of tasks in that menu. I spoke to Ted Gould about it and he said this is likely to be added in the future. When it is ready I will propose it to upstream GTG for inclusion.

Posted on January 13, 2010 - by jono

Two GNOME Contractors Required

We are currently looking for two paid home-based contractor positions in Europe or the USA to come and work at Canonical to write some upstream code to help GNOME applications fit into the full Ubuntu desktop experience. This is an awesome opportunity for talented GNOME developers and a a great way to dip your feet into the Ubuntu development team. The roles involve these elements:

Responsibilities

• Create patches for GNOME Desktop applications to provide complete integration with the Ubuntu desktop experience
• Work with upstreams on planning and creating packages
• Work with upstreams to get patches integrated upstream
• Fix integration related bugs and other bugs

Skills

• Ability to hack in C and Python
• Experience with bzr, git, and other concurrent versioning systems
• Experience with launchpad and bugzilla bug tracking
• Social skills needed to interact with upstreams and Ubuntu teams
• Ability to set work schedule and systematically report on status

If you are interested, we are looking to fill these roles ASAP, so email me at jono AT ubuntu DOT com ASAP and I will forward you on to the right people.

Posted on December 30, 2009 - by jono

Announcing Acire

After a wonderful week in England with family celebrating Christmas, Erica and I flew home to the East Bay. We were sat at Heathrow having a cup of coffee and I was thinking of what I occupy myself with on the plane ride over. Unfortunately, Lernid hacking was out of the question as I had no net connection on the plane, so I got to thinking of something else. After some busy hacking time at 35,000 feet I am proud to show of the results of my labor: a little program called Acire.

Let me provide a bit of an introduction.

I love Python and I love PyGTK and as I have waxed lyrical about recently, I am passionate about how tools such as Quickly are lowering the bar for opportunistic programmers to scratch their itch. The problem is, much as Python and PyGTK are incredible for writing apps, like any other tool they still need to be learned, and the best way to learn is by downloading, running and playing with code snippets. Traditionally this has involved finding scattered bits of sample code online and stuffing it into a directory. Not only do we download other people’s sample code but we often write our own little code snippets as we learn new parts of these tools, and these would be perfect to share with others. Unfortunately, many of us never end up putting them anywhere online. Acire is a first step in making this whole process easier.

Right now, Acire is a tool that allows you to browse snippets easily. It looks like this:

The combo box in the top left provides different categories of snippets. In the screenshot above you can see the general category PyGTK, but there is no reason why we can’t have sub-categories such as PyGTK -> TreeViews. When you select a category, the list underneath it shows all the current snippets. Clicking on a snippet not only loads the code in the view to the right, but also provides a simple description and location of the snippet underneath the code. You can then run the snippet by clicking the Execute button or copy the full code to the clipboard by clicking the Copy button.

To make snippets work in Acire, I have created some simple metadata tags that snippet authors should put at the top of the snippet in the code. Here is an example:

# [SNIPPET_NAME: Actions]
# [SNIPPET_CATEGORIES: PyGTK]
# [SNIPPET_DESCRIPTION: Demonstrates using Actions with a gtk.Action and gtk.AccelGroup]

To test this out I have already added this meta data content to all the examples from the PyGTK Manual. This functionality already makes browsing available snippets, running them and looking at the code an absolute doddle.

I have just got in from a day of traveling, I am exhausted, and headed to bed. I will get the code online tomorrow and talk more about plans for Acire.

Posted on December 17, 2009 - by jono

Application Indicators In Python

I am really excited to see Ted’s post regarding some of the improvements coming to the desktop notification area. This part of our desktop has become something of a wild west – icons look ugly, are spaced too close together, have left/right click inconstancy, often provide obscure and inaccessible widgets and cannot be easily controlled across notification icons with a single keyboard shortcut. This approach will fix many of these issues.

This approach has two distinctive components – the user interface improvements and the technology to implement. The user interface changes I think are really interesting and bring some distinctive benefits:

• Application indicators are more consistent – no more left and right-click inconsistency. Always left click to see the items.
• Scrubbing – you can click once on an app indicator and scrub left and right through other indicators with your mouse.
• More accessible – importantly, scrubbing also applies to the keyboard: this means you could bind a key to the indicator applet, hit that key and then use the arrow keys to navigate through all the indicators.
• Themable panel icons – you can set a specific icon to be a panel icon for an indicator: this should make it easier for creating single colour panel icons for light and dark themes.
• KDE/GNOME compatability – one thing that really excites me is that by using this spec, KDE applications running in GNOME will have their application notification menus rendered with GTK widgets and vice-versa.

I am really excited about the opportunities this brings to the desktop, and I am also really excited about us working with our friends in KDE on this spec.

I wanted to give this a roll in my more native Python tongue so I added the Karmic PPA and started playing with the module. I contributed my code as an example on the wiki. Here it is to show how it works:

import gobject
import gtk
import appindicator

if __name__ == "__main__":
    ind = appindicator.Indicator ("example-simple-client", "indicator-messages", appindicator.CATEGORY_APPLICATION_STATUS)
    ind.set_status (appindicator.STATUS_ACTIVE)
    ind.set_attention_icon ("indicator-messages-new")

    # create a menu
    menu = gtk.Menu()

    # create some labels
    for i in range(3):
        buf = "Test-undermenu - %d" % i

    menu_items = gtk.MenuItem(buf)

    menu.append(menu_items)

    # this is where you would connect your menu item up with a function:

    # menu_items.connect("activate", self.menuitem_response, buf)

    # show the items
    menu_items.show()

    ind.set_menu(menu)

    gtk.main()

I basically created an indicator object and threw a GTK menu into it and as if by magic my app appeared in the notification panel, properly spaced out and enjoying the benefits I mentioned above. Pretty simple.

Posted on August 11, 2009 - by jono

Old Face Rubbish. New Face Required.

Now for a matter of national security. I got an email today saying:

As I read your blog posts on planet.gnome.org, my view of your words is colored by your angry faced hackergotchi. I would love to see the happier side of the Ubuntu Community Manager.

I am a pretty happy fella, but you know what, that hackergotchi is indeed a little angry. Would any of you creative types be interested in having a go at creating a new hackergotchi for me?

If so, feel free to link to your hackergotchi in the comments. Thanks!

Posted on August 3, 2009 - by jono

Gran Canaria Desktop Summit Thoughts

A little while back I spent some time in beautiful Gran Canaria at the inaugural Gran Canaria Desktop Summit. This was the first event of its kind to bring together developers from the two major desktops, KDE and GNOME. As the event progressed I was asking how people felt the event went, whether it was useful, what worked and what didn’t. Generally the feedback was very positive but there were some areas in which people felt it could have seen some improvements and rough edges shaved off.

I think we need to ensure this discussion first emphasizes the great achievements that the organizers made. Whenever creating a new event, the first event is always going to get some things right and identify some areas of improvement, and it is tempting to dwell only on these areas on improvement. The organizers of the summit performed a wonderful job with this first incarnation of the event, and just getting all those KDE and GNOME folks in the same town was a great achievement in itself. I want to issue my thanks to everyone involved: I felt like it was really useful and a whole lot of fun, to boot.

I have have two primary recommendations to make to the organizers:

• Firstly, I heard a lot of feedback from people saying that they enjoyed the presentations but would have liked to have had more time in discussion sessions about specific technologies. As such I would recommend that for next year, Monday to Wednesday is a traditional GUADEC/aKademy like summit in which each project has these discussions, and preferably lots of cross-desktop discussions too. These three days would also be great opportunities for hack-fests. Then on the Thursday and Friday there would be two days of presentations, similar to what we had this year at the Gran Canaria Desktop Summit. This combination of summit time and presentation time would ensure each project gets their own face time, time to show of their work and share best practise later in the week, and the evening events throughout the week should encourage cross-desktop mingling and getting-to-know-each-other time.
• Secondly, instead of having the GUADEC and aKademy tracks as there were this year, let’s have general tracks with mixed KDE, GNOME and other desktop sessions. As an example, it would be awesome to have a Multimedia track which could have presentations on GStreamer, Phonon, PiTiVi, AmaroK etc.

All in all I thought the Gran Canaria Desktop Summit was a stonking event, and I hope some of this feedback is useful.