The Raving Rick

Bit of fun with JQuery and CSS

2012-01-12T04:02:00.001-08:00

I stole some time to play a bit more with veritas and JQuery today. Instead of the ugly list that I had before, I wanted some interactivity. So I got started by adding a little css to make a "card" for each bottle.

 .bottle
{
width:300px;
background-color:rgba(0,0,0,.5);
}

Then I wrote a bit of javascript to make each div that I pass into the html into a JQuery "draggable", and do a bit of cheap layout.

    else if(signal == "add_bottle")
  {
   div = jQuery(data,{}).draggable();
   div.css('position','absolute');
   div.css('left', lft);
   div.css('top',tp);
   lft += 10;
   tp += 10;
   $( "#bottle_div" ).append(div);
  }

Next I'll add some nicer layout. Then I'll start adding filters and dropdowns so I can sort and do other fun stuff.

In Vino JQuery, not a Socratic, dialogs

2011-12-30T05:20:00.000-08:00

I spent a bit of today adding the capability to Veratas to collect user input in the form of a "dialog". I put "dialog" in quotes, because I used a JQuery dialog within the HTML, rather than a Gtk dialog window.

Before settling on JQuery for this project, I looked at it and YUI in some depth. I was attracted to YUI because it seems very very complete. In fact, it has a filterable and sortable data grid, which is very important to me, as most applications, when you get down to it, are really just CRUD apps.

However, I went with JQuery for Veritas because the samples and tutorials made it seem very easy to get things done, and Veritas has simple needs.

JQuery has a cool page where you can create just the javascript that you need, as well as a theme generator. Note the "grapey" dialog bar in the screenshot, I set that color in the theme generator.

What the Dialog Does

First thing was to lay out the dialog in the normal HTML way. Note that I set it to be display:none, by default.

  <div id="dialog" title="Enter New Bottle" style="display:none;width=00px">
<fieldset>
<p>
<label for="country">Country</label>
<input type="text" name="country" id="country" value="" placeholder="">
</p>
<p>
<label for="region">Region</label>
<input type="text" name="region" id="region" value="" placeholder="">
</p>
<p>
<label for="domain">Domain</label>
<input type="text" name="domain" id="domain" value="" placeholder="">
</p>
<p>
<label for="grapes">Grape(s)</label>
<input type="text" name="grapes" id="grapes" value="" placeholder="">
</p>
<p>
<label for="price">Price</label>
<input type="number" name="price" id="price" value="" placeholder="$">
</p>
<p>
<label for="rating">Rating</label>
<select name="rating" id="rating" value="" placeholder="">
 <option value="1">1</option>
 <option value="2">2</option>
 <option value="3">3</option>
 <option value="4">4</option>
 <option value="5">5</option>
 <option value="6">6</option>
 <option value="7">7</option>
 <option value="8">8</option>
 <option value="9">9</option>
 <option value="10">10</option>
</select>
</p>
<p>
<label for="taste">Taste</label>
<input type="text" name="taste" id="taste" value="" placeholder="">
</p>
<p>
<label for="image">Label Picture</label>
<input type="text" name="image" id="image" value="" placeholder="">
<button id="preview_button">Preview</button>
<img id="preview_image" src=""/>
</p>
<p>
<button id="submit_new">OK</button>
</P>
</fieldset>
</div>

Then, I created a "New" button, and wired it up to some code that I was able to get from the excellent JQuery demo pages to display the dialog. Note that the documentation made it really easy to copy and paste my way to success here, including figuring out how to choose different reveal effects and such.

        $( "#dialog" ).dialog({
      autoOpen: false,
      width: 600,
      show: "blind",
      hide: "blind"
  });
  $( "#new_button" ).click(function() {
      $( "#dialog" ).dialog( "open" );
      return false;
  });

The dialog includes a submit button. I wired this up to create a JSON object and send a signal with all this data to the backend using the "send_message" javascript function.

        $( "#submit_new" ).click(function() {
       bottle = {"country": + $( "#country" ).val(),
       "region": $( "#region" ).val(),
       "domain": $( "#domain" ).val(),
       "grapes": $( "#grapes" ).val(),
       "price": $( "#price" ).val(),
       "rating": $( "#rating" ).val(),
       "taste": $( "#taste" ).val(),
       "image": $( "#image" ).val()};
       send_message("new_wine", bottle);
       $( "#dialog" ).dialog( "close" );
       return false;
   });

Yesterday, send_signal took 2 strings: the name of the signal and some other data. Today I changed it to take the name of the signal, and any javascript object. The function uses a popular JSON parcer to stringify the javascript object before using the "set title hack" to pass the data tot he back end.

function send_message(signal_name, data)
{
title = document.getElementsByTagName("title")[0];
message = {"signal": signal_name,"data":data};
title.innerHTML = JSON.stringify(message);
}

Now that I have written that part, I don't have to worry about formatting my data, I can just pass it over.

Similarly, on the back end, I made the HTMLWindow class decode the json and pass it along:


def _on_html_message(self, view, frame, title):
   if title != "null":
       try:
           message = json.loads(title)
       except Exception, inst:
           print inst
           message = {"signal":"error","data":"signal not parsed"}
   else:
       message = None
   self.on_html_message(message["signal"],message["data"])

def on_html_message(self,message):
   pass

As a result, subclasses like VeritasWidnow can just use the data without worrying about the implementation. It doesn't do anything with the data yet.

2 Way Communication

I did add one bit of round tripping. It turns out that as a security precaution, the "file" input type does not let the javascript see the full path selected, it only allows the selected file to be uploaded to the server. I hope that I can figure out how to let the user grant Veritas permissions to pass the selected file to the javascript, but I can hack around it if it doesn't turn out to be easy or possible.

Meantime, I let the user type in a full path to the file, and then click "Preview". This takes the entered string, and sends it to the back end.


    $( "#preview_button" ).click(function() {
        send_message("image_preview", $( "#image" ).val() );
        return false;
    });

The back end then uses the awesome PIL libary to make a thumbnail, and then passes the path of the thumbnail back. I actully suspect that I will be able to skip the step of saving the file and just use the string data, possible with the Canvas element.


def on_html_message(self, signal_name, data):
    if signal_name == "image_preview":
        try:
            img = Image.open(data)
            img.thumbnail((128,128), Image.ANTIALIAS)
            path = """/home/rick/.tmp/thumbnail.jpg"""
            img.save(path,"JPEG")
            path = "file://" + path
            self.view.execute_script("receive_signal('set_preview','" + path + "');")
        except Exception, inst:
            print inst.message
            self.view.execute_script("""receive_signal('set_preview_error','Could not find a valid image at %s');""" % data)

Debugging HTML/javascript

Another handy think I found today is that I can load the HTML page into Firefox, and use a web console to poke at it. Very handy. Of course, this works now because I am not doing string replacement, but I think that I can actually make a similar thing work with a WebKit window.

So now that I can collect the info from the user, I'll start saving the data in a sqlite database, and then work on presenting the data to the user.

I pushed a separate branch with the JQuery code here.

In Vino Veritas and HTML5 Client Apps

2011-12-29T09:00:00.000-08:00

So, basically, not to put to fine a point on it, I've started to write apps for Ubuntu in a different way, essentially, replacing Gtk (or really PyGtk) with HTML5. This is my first post about how am I doing it. I've just started a project called "Veritas" which will be a wine tasting database for my wife and I. We'll be able to enter information about each bottle that we drink, and then look at trends over time, perhaps helping us pick nicer and nicer bottles as we go.

First, though, what happened, I thought you got along great with Gtk?

Well, I do still have a soft spot in my heart for pygtk. Believe me, I've written plenty of code in it. I know the ins and outs pretty well, and I'm able to do things with it like write a response UI that doesn't block to much during run longing processes and such. PyGtk is great for building "boxy" apps, but I think a lot of people want to build slicker apps than Gtk is really designed for, or at least design them in different ways thatn Gtk supports well.

Why not Qt and QML?

This app, in fact, would be well suited for a QML app. However, I have other apps in mind, and I found QML/Qt to not be quite up to the job. For instance, I want to write a communication app to combine OpenLDAP and IRC functionality. Currently, there are no Qt libraries for LDAP or IRC, so to write such an app with QML, I'd have to write C++ Qt code to wrap whatever C libraries, and then write code to export models from that C++ code to expose it the right way in QML. That is a lot of overhead, especially considering that there are good Python libraries for LDAP, IRC, and pretty much anything desired. So, I designed myself a system that let me stick with Python for the back end code.

Also, QML lacks a widget toolkit at the moment, so there would be a lot of manual coding of things like buttons and such.

Why HTML5?

I chose HTML 5 for the widget toolkit for a few reasons.

I already know HTML/CSS/Javascript pretty well, and I know that cool things can be done with it. I bet a lot you all know it pretty well too.
Webkit is very well supported Open Source used and maintained by many large companies.
There are lots of cool widget toolkits to choose from, I'm currently looking at YUI since I think it's in pretty heavy use by some of the web teams at Canonical.
Because I wanted to try out HTML for client programming.

My Application Architecture

First, I laid everything out total flat to start with. This is because I wanted to come to grips with making the view code talk to the model/controller code without mucking with any extra complexity. Of course, I will need to modify the layout as the actual code grows.

Currently, I am only focused on makinga client application programming system, though I may, in the future, extend the system so the model/controller back end could be on a server, and the view available via a browser. But this is firmly out of scope right now. I am, however, trying to be cognizant of making the system essentially portable by sequestering the Gtk specific code into specific files that can be replaced if I want to run it without Gtk at some point.

Therefore, there are some important differences to note if you are used to web programming.

The back and and view code communicate via signals to each other. This is much different than web programming, where the view makes a request and waits for the server to respond with a string (for Ajax apps) or redirects to another view passing some state along with it.
This means that the back end can send signals to the view. The view does not need to pole to see if the back end is ready, for example, the back end can just send a signal when it is.
This also means that long running processes can block the GUI, since they are running in the same thread. I shall most likely put the Gtk main loop in it's own thread so I can run run-longing processes in seperate threads, and then communicate between them.
The view cannot call a function on the back end, and wait for a response (for example with XmlHttpRequest). Rather it can only send the back end a signal.
The back end is not stateless. This is greatly simplifying. Most web programming frameworks have a lot of code to maintain state by storing it and accessing it on future requests by reading cookies stored on the client.
Currently, I have nothing like server side tags that are the bread and butter of most web programming frameworks. This typically works via string replacement, so I could either find a library to add this functionality, or make it easier to do string replacement with the HTML. This is typically desirable for a web app since you want to configure the HTML before it is sent from the server. Less important in a client app, but still, some string replacement of HTML may save some effort in writing complex javascript against the browser DOM.

The Code

Ok, let's get to the good stuff. To bin file is called "veritas". Running this file creates a VeritasWindow and then starts the Gtk main loop. The Gtk main loop is there because the Webkit window has to run inside something, and I chose a Gtk Window for this because of the simple integration with Ubuntu.

A VeritasWindow only does 2 things so far. It tells it's baseclass "HTMLWindow" what html file to load, and it listens for signals from that view. Later, it will create new HTML5 Windows and do other stuff in response to signals from the HTML view.

HTMLWindow is meant to be used only as a base class. First, it creates a top level menu so you can quit the app, and also, I think that apps should have menus (I haven't really thought through how menus will work in this system yet, but I'm hoping that DBUS Menu helps me out). Then it loads the HTML that the subclass told it to load. It also listens for signals from the view, parses the signals and has what is essentially a virtual function called "on_html_message" for subclasses to override. You should be able to receive messages from the view without looking at the internals of how it works. Among other things, this is platform specific.

main.html is the HTML5 code for the main window. All it does now is send a signal that it is loaded, and you can see that I added a heading. When paired with main.css the layout and look and feel of the UI will be controlled completely in the view code.

helpers.js is a file that I think I may need to handle platform specific signals sent to the view. Of course, you can always call "execute_script" and send whatever you want from the backend, but I think it's cleaner to expect well formatted signals from the back end instead.

Conclusion

So, that's basically all the boiler plate for making an HTML5 client app for Ubuntu. This represents a few hours of work on my part to make a re-usable and extensible system.

My next steps will be to do some database programming with sqlite, then I'll probably build a data input window for it. This certainly calls to mind Rails-like thinking (hmmm, I have the model, why can't I generate the view from that on the fly?), but, I don't think I want anything that complex. After I finish Veritas, I'll then extract the base classes and such, and perhaps create a Quickly template, then go ahead and work on my certain to be more complex communication application.

Smoke Tests

2011-11-28T08:52:00.000-08:00

The QA team has started a page for getting up the minute automated results from smoke testing of daily images. Check it out! They still have more smoke tests to set up, but everything is running automatically from daily builds. You can check to see if the latest build installs and if basic tests run. If they do, it's probably worth testing with that build. If it's not, then the team should be busy at work at making it work testing!

Also, this page is just on small step in the blueprint for smoke tests results page.

12.04 Quality Initiatives Update

2011-11-18T00:09:00.001-08:00

It's been 2 weeks since UDS. We left UDS with a lot of big plans about developing 12.04 in a precise way. So, in 2 weeks, we've gotten a good start. Here's a slapdash update before I leave for the weekend.

+1 Maintenance and Daily Quality
For the last week, we've had an installable and usable image every day! Colin is keeping a wiki until we have a proper dashboard set up.

Upstream Testing
A lot has gone on in this area. The QA team spent this week getting a QA lab set up, so we have a place to run automated tests. The Desktop team is working with the Dx team to get automated compiz testing set up, hopefully as early as next week. I need to circle back with other upstream projects, especially the ones that Ubuntu Engineering make, to check on their progress.

Distro Acceptance Testing
Didier Roche has started documenting tests to be run before uploads of Unity and working with the QA team to figure out how best to track them. You can check out his progress here.

QA Lab
Like, I said, the QA team has been working on the QA lab. We have trunk tests and distro acceptance tests to run. We need hardware! Here's a shot that Pete Graner took of the new rack for Open Stack testing:
Lots going on to make a 12.04 in a precise way! You can see the QA team's current work items here.

Some Rock Solid things are Quite Beautiful

2011-11-08T06:02:00.001-08:00

I mentioned at the closing session of UDS last week, that it was remarkable UDS due to the amount of time spent discussing how we build Ubuntu, not just what we will build. As a community, we have blazed many new trails in software development and delivery, and I feel strongly that we are standing at a nexus where we will be able to collect the wisdom of the past seven years of developing an Open Source Community Distro and apply that wisdom in the future in a way that introduces a step function in our adoption curve as we pursue our goal of a mainstream free desktop.

Most of these "how should we build it" discussions circled around building and maintaining development velocity in 12.04 so that we could add new features that users need while maintaining and delivering the quality they also need. Fortunately, we laid some ground work in the 11.10 cycle. Pete Graner led the QA team in 11.10. Along with some new QA staff, they instituted some important practices, like automatically testing the daily ISO each day, and they set up a QA lab for running tests automatically, along with reporting of those test results.

Acceptance Criteria
How we assess and accept code from upsreams within Canonical was an area ripe for discussion. We arrived at UDS with a strong view about how we should be doing this, and we had three discussions about it at UDS. Jason Warner this area of collective effort "Acceptance Criteria". Please note that for 12.04 and the foreseeable future, this applies ONLY to code developed by Canonical, or was call them "Canonical upstreams". There are two main goals of this effort:

Ensure that landing code from Canonical upstreams does not introduce issues that make the development release too hard to use and develop on, thus slowing down velocity for everyone.
Encourage Canonical upstreams to fix bugs throughout the cycle, and not to wait until after Feature Freeze to focus all efforts on bug fixing.

As a result, we should see faster development, and a higher quality final product.

Acceptance Criteria means that upstreams have some responsibilities, and Ubuntu has some responsibilities. For upstreams, it boils down to "treat your trunk as sacred". Practically, it requires:

There is a trunk of code bound for Ubuntu.
This trunk always builds automatically.
This trunk has tests that are always passing automatically.
All branches are properly reviewed for having both good tests and good implementation before merged into trunk.
Any branch that breaks trunk by causing automated tests to fail or causes trunk to stop building, are immediately reverted.

For Ubuntu Engineering, the responsibilities include:

Every maintainer in Ubuntu must have a test plan for upstream trunks that are run before uploading to the development release.
Tests in the test plan that are automated can be run with the help of the QA team.
Tests in the test plan that are manual can be run with the help of the community team, (and the community QA Lead that is to be hired)
Refrain from uploading a trunk into Ubuntu if there are serious bugs found in testing that will slow down people using the development release for testing and development.
Revert uploads that break Ubuntu, as there is no point in having the latest of a trunk in Ubuntu if it's broken and just slowing everyone down.
Add tests to upstream projects for the Ubuntu test plan if serious bugs do get through that cause a revert.

ISO integration testing
Every day the QA team automatically runs tests on the ISO produced that day, if any. This was set up in 11.10. For 12.04, we will expand on this effort substantially. First, by growing the body of tests run. Secondly, by automatically reporting on the quality of the ISO each day. Finally, by responding to the results of the tests immediately, see the next section.

Daily Quality
We will strive to ensure that we have a new daily ISO each day. If the QA team finds an ISO to be "untestable" or failing critical tests that will hamper development velocity that day, we will respond by trying to fix the issues. For issues that cannot be foreseeably fixed within 3 hours, we will typically back out those changes. After the issue is addressed by being fixed or backed out, we *will spin another ISO*. We will collect metrics on what percentage of days we have a working and testable ISO.

Pre-archive Testing
Of course, catching problems in ISO testing and fixing them everyday is nice, but stopping the problems from reaching Ubuntu in the first place is even better. With that end in mind, Evan Dandrea ran a very interesting session about testing library and other changes before uploading them to the archive for the development release.

This will start out simple. The QA team will be able to install the latest ISO in their test environment, then pull an updated package from a PPA. A tool that I lovingly named "tool 2" will be created that will use rdepends to find packages that both depend on the newly upagraded package and also have tests worth running. Tool 2 will then run those tests and report the results. In this way, issues with libraries and other transitions can be fixed before they get into the development release and slow everyone down.

The next step, which I sincerely hope we get to during 12.04 development is to make tool 1. Tool 1 takes the output of tool 2, and judges if it should copy the newly updated package, or some set of packages, into the release archive. If we get tool 2 set up, then uploads to the development release would first go into the proposed archive for the development release, tested there, and only added to the release archive when found to be "ok" by the tests.

+1 Maintenance Team
Colin Watson is leading an experiment for 12.04 development. He will be leading a small staff of rotating engineers who are focused soley on the stability of the development release. We plan to learn from this effort, and see if we should repeat it, tweak it, or drop it for future versions. In any case, these efforts are meant to enhance, not replace, the generally diffused responsibilities for quality of the ISO and the archive. Colin led a good UDS session on the topic. The priorities defined there being:

Deal with ISO smoke test issues, includes install images being buildable
Upgrades through development releases work day to day, look at conflict checker
All packages in main are installable
All packages in main are buildable
Component-mismatches / MIRs / etc.
Finishing library/NBS transitions through archive (beyond main)
All packages in the archive are buildable

Summary
All in all, these are a lot of structural changes to how we approach building Ubuntu and ensuring the quality of it. Here is a table to highlight some of the key changes.

Practice	11.10	12.04
Canonical upstream automated tests	prevelant in some projects, not others	all projects will have automated tests
Canonical upstream automated builds	prevelant in some projets, not others	all projects will ahve automated tests
Canonical upstream branch reviews	all projects	all projects
Canonical upstreams reverting branches that "break" trunk	occurs in some projects, not others, not always	all projects will revert branches that break trunk
testing of Canonical upstream code before uploading to development release	not common or systematic	all Canonical upstream projects will have a test plan that is executed before each upload
reverting Canonical upstream code from the development release	development release waits for an upload with "fixes"	uploads that slow velocity for others are backed out
Daily ISO testing	Limited test coverage, test failures not immediately responded to	more test coverage, fix issues and respin within the same day
Daily ISO	Can go for days or longer wihtout a working daily	A broken daily ISO becomes the #1 priority for whoever broke it
Pre-archive testing	"Call for testing", not totally systematic, no way to know what tests were run	Add ability to run tests for rdpends before release, potentially test in proposed for the development release
Archive Maintenance	Responibility diffused throughout team	Responibility diffused throughout team, complimented by a small dedicated crew

Stealthy, An App to Pause Desktop Logging

2011-10-23T04:37:00.001-07:00

Here's a quick preview of an app I'm working on. It's called "Stealthy" because it provides a kind of "Stealth" mode by pausing Zeitgeist from logging while it's running. The upshot is that when you see the indocator, your activities during that time won't show up in Unity. Quitting Stealthy starts the logging again.

It's also got a "Delete History" function, that just clears all Zeitgeist and GNOME most recently used history, giving you a clean slate.

Here's a video demo:

D'oh ... I just realized I searched for the wrong things to demonstrate that Delete History command worked. Anyway, trust me, it would have looked like it worked if I searched for the right thing! :)

You can try it by running from the branch( bzr branch lp:~rick-rickspencer3/+junk/stealthy ). However, I plan to add a little ninja icon instead of the stock inidcator icon, and also a warning dialog for the Delete History function. Then I'll put it in my PPA, and also probably sell it in the Software Center for the minimum price.

Using PyGame in a PyGtk App

2011-08-25T05:04:00.000-07:00

I've written a few games in pygame, but never quite finished them. Generally because the complexity of adding user interactivity for things outside the essential game play. While pygame is a sweet sprite library, it has no widget toolkit, so things like collection a string from the user, having menus, etc... are all incredibly tedious to program. Adding something like a high score screen is as much effort as game programming itself.

Pygtk, however, has a rich widget toolkit, but it's hard to use it from within a pygame app. This is difficult in part because Gtk needs a gtk.main loop, but a typical pygame app is using it's own loop with clock.tick(). As a result, there are threads locking each other out, and generally craziness ensues.

But, it turns out, you can embed a pygame surface within a pygtk app, and it's actually pretty easy. So you can use just the one gtk.main loop, all interupt programming, access to the whole Gtk toolkit, and also all the easy loading of images, playing of sounds, collision detection, and other sprite functionality of pygame. It's really the best of all possible worlds.

I wrote a minimal demo script to show how to do this. The "game" is just a single sprite that you can move with the keyboard. You can see the screen in the screenshot at the top of this post that there is a gtk menu being activated!

I didn't intend this to be a tutorail on pygame, but rather integrating pygame in pygtk, so all the "game" does is let you move a sprite around.

It's probably easiest to look at the whole script, but let me point out some of the steps involved. I'll assume that you've already set up a gtk.Window with your menus and such. So, the first step is to set up a gtk.DrawingArea that will become the pygame surface. It's normal code to add it to your window:

      da = gtk.DrawingArea()

    da.set_size_request(300,300)

    da.show()

    vbox.pack_end(da)

    da.connect("realize",self._realized)

This last line, connecting to the realize signal, is important. It's important because you use the gtk.gdk.window.id to associate the drawing area with pygame. The drawing area's window won't have an id until it's been rendered by gtk. So the then in the handler for the realize event, we set up the association with the drawing area, and also start actually drawing the game:



def _realized(self, widget, data=None):

    os.putenv('SDL_WINDOWID', str(widget.window.xid))   

    pygame.init()

    pygame.display.set_mode((300, 300), 0, 0)

    self.screen = pygame.display.get_surface()

    gobject.timeout_add(200, self.draw)

The first three lines essentially set up the drawing area as the pygame surface. The fourth line creates a global object for a pygame.screen object that will be used in the draw function. Finally, the draw function gets caslled every 200 milliseconds via a gobject timeout. This is as much easier way of setting up the game loop than the normal pygtk way of blocking the clock for a certain number of ticks, as gobject.timeout_add plays nicely with the gtk.main loop.

In a real game, you'd probably put an "update" function on the timeout to do things like check for collisions, random events, and etc... (You'd also probably use a much smaller time out period than 200 milliseconds). However, our game only has one sprite, and it doesn't do anything but move so we don't need that functionality. But how do we tell it move? In pygame, every time through the main loop you pull all the events off the event stack. With pygtk, you use signals to handle the input when it occurs.

To do this, in the __init__ function for the window, we set up our pygame objects, and then connect to the key-press signal:

      #set up the pygame objects

    self.image = pygame.image.load("sprite.png")

    self.background = pygame.image.load("background.png")

    self.x = 150

    self.y = 150



    #collect key press events

    self.connect("key-press-event", self.key_pressed)

Then in the signal handler, we manipulate those objects. Typically, you'd be storing the x and y coordinates in a sprite object, but since there is only one sprite to track in this "game" we can handle it more simply. So in the key_press handler, we just detect if an arrow key was pressed, and we adjust the game data appropriately:



def key_pressed(self, widget, event, data=None):

    if event.keyval == 65361:

        self.x -= 5

    elif event.keyval == 65362:

        self.y -= 5

    elif event.keyval == 65363:

        self.x += 5

    elif event.keyval == 65364:

        self.y += 5

Then, every 200 milliseconds, the timeout comes buy and tells pygame to draw everything using normal pygame functions:



def draw(self):

    self.screen.blit(self.background,[0,0])

    rect = self.image.get_rect()

    rect.x = self.x

    rect.y = self.y

    self.screen.blit(self.image, rect)

    pygame.display.flip()



    return True

Since pygame is getting update in gobject timeout and normal Gtk signal handlers, and not in it's own gameloop, gtk.main is free to run and handle menus, and even display dialogs:

A Photobomb Sale!

2011-08-23T22:31:00.001-07:00

Photobomb showed up in the Software Center yesterday. As I prepare a space in my garage for the Rolls Royce I intend to buy from the proceeds, I took a moment to check in on sales, and, in fact, someone bought it! The MyApps portal has a really nice overview screen for managing multiple apps for sale.

Now, I strongly suspect that a friend bought it to make me feel better, but still, it gave me a chance to check out the nice graphs that myapps makes for developers. Of course, I expect Photobomb sales to stress test their math and charting capabilities due to an overwhelming crush of sales, but it's nice to see what they are shooting for.

I'm really impressed with the work that Canonical ISD has done here. I'd love to see this work made available to people who want to land non-commercial apps on a stable release of Ubuntu soon. Currently, it only supports commercial apps.

Speaking of which, while I am selling Photobomb, please keep in mind that it is still Free. That means that anyone who buys it gets all the software freedoms (it is GPL3, afterall). Furthermore, if you don't want to buy it, you can get Photobomb for free my PPA. Seriously, it you want to use it, but don't want to buy it, no worries, running it from my PPA is no problem for me.

Cha-ching!

2011-08-17T10:41:00.000-07:00

So, today I uploaded a special version of Photobomb to my PPA. It's special because I consider this my first *complete* release. There are some things that I would like to be better in it. For example:

I wish you could drag into from the desktop or other apps.
I wish that the app didn't block the UI when you click on the Gwibber tab when Gwibber isn't working.
I wish the local files view had a watch on the current directory so that it refreshed automatically.
I wish inking was smoother.
I wish you could choose the size of the image that you are making.
I wish that you could multi-select in it.

But alas, if I wait until it has everything and no bugs, I'll never release.

So, I am releasing Photobomb in my PPA. It is a free app. You can use it for free, and it's Free software. So, enjoy.

However, I am *also* releasing it commercially into the software center. That means that you can choose to install from my PPA for free, or you can buy it from the Software Center. I guess the only real difference will be that I could break it in my PPA, and I won't generally plan to provide lots of support, but if you bought it, I'd feel a bit more like I should strive to fix your bugs and stuff.

The code is GPL v3, so people can enhance it, or generally do whatever they think is useful for them (including giving it a way, or using it to make money).

I found it remarkably easy to submit photobomb to the Software Center. I just used the myapps.ubuntu portal, and it all went very smoothly. Really just a matter of filling in some forms. Of course, since I used Quickly to build Photobomb, Quickly took care of the packaging for me, so that simplified it loads.

I'll keep everyone posted on how it goes!

The End of an Era?

2011-08-06T02:38:00.000-07:00

Today I committed and pushed a change to Photobomb to remove functionality! The web tab used to allow users to search the web for images. So you could search for "cat" and get the most popular kitteh pix ready to mix into our images. No longer. You can still plug in a web address, and Photobomb will it's best to find an image there, but no more web searches.

A couple of weeks ago, Google retired the Google API I was using, so I switched to Yahoo!, only to find that the Yahoo! one got retired a week or so ago.

Both services switched to newer APIs. The thing is, both Google and Yahoo! now charge an application for using those APIs. Yup, I would have to pay actual money to use the services.

I really don't have a problem with them doing that. I mean, someone has to pay to keep those services running. And I suppose if I charged a bit for Photobomb, I could use that to fund paying for the services. However, at the moment, I don't really feel like dealing with setting up an account and dealing with all that, in addition to recoding to the new APIs.

So, I guess the era of the web giants competing to get me to use their "free" services has drawn to a close. I suppose it's a bit like a bursting bubble. Goodbye free web-services :/

Coding Copy and Paste Functionality

2011-08-01T02:58:00.000-07:00

Copy and Paste Features
A well designed application should probably support Copy and Paste. While it sounds simple, it actually entails a few features.

Copying from Your Application to Other Applications
This means that your application should offer up data formats that other applications can read. So a user should be able to copy in your application, and paste into another one. This may entail converting your internal data format into a new one that other programs will expect.

Copying from Other Applications into Your Application
This means reading other applications data formats and converting it your applications internal representation.

Copying and Pasting within Your Application or between Instances of Your Application
This entails marshaling all the data that your application needs. If a user can run multiple instances of your Application, it won't be sufficient to simply copy an instance of an object, since one instance won't have access to what is in the memory of another instances.

How Does Copy and Paste Work?
You start out by accessing the desktop's clipboard. Then, you tell that clipboard what kind of data your app can put on the clipboard, and then what kind of data your app can take off of the clipboard. Then, you right some functions to handle the following situations:

If the user selects a Copy command in your application, you tell the clipboard that data is available (but you don't actually put the data on the clipboard until the user selects paste).
If the user selects Paste in your application, you ask the clipboard for the data, and the application with the data then supplies it to the clipboard. Sometimes the application supplying the data is your application, and sometimes it is a different application.
If the user selects Paste in a different application, then the clipboard might ask your application to supply the data.

Set Up Variables
So, let's get to the code. First thing, we need to create a reference to desktop's clipboard, and also create a variable to store a reference to whatever item may be copied.

     self.clipboard = gtk.Clipboard()
self.clipboard_item = None

I put this in finish_initializing.

Handling the Copy Command
Then I wrote a function called "copy_menu" which is called when the user selects "Copy" fromt he menu. the first thing this function does is tells the clipboard what kinds of data is supported by passing in a list of tuples. Each tuple has a string that specifies the type, info regarding drag and drop, and a number that you can make up to specify what the type again. For Photobomb, only the strings are important. You need to use types that are commonly understood on the Linux desktop so that apps know that you can give them data they care about. I chose "UTF8_STRING" for putting strings on the clipboard, and the mime type "image/png" for images. For example, Gedit recongizes UTF8_STRING, and Gimp recognizes image/png, so Photobomb can copy data into both of those apps. Only Photobomb recognizes "PhotobombItem", of course. These strings are called "targets" in Gtk.

After specifying what data types you will support, you then tell the clipboard about those data types, along with what function to call if the user tries to paste, and what function to call when the clipboard gets cleared. Finally, the function stores a reference to the currently selected item. It's important to store this reference seperately, as the selection could change before the user pastes.

   def copy_menu(self, widget, data=None):
paste_data = [("UTF8_STRING", 0, 0),
        ("image/png", 0, 1),
        ("PhotobombItem", 0, 2)]
self.clipboard.set_with_data(paste_data, self.format_for_clipboard, clipboard_cleared)
self.clipboard_item = self.selected_item

Handling Programs Pasting from Photobomb
After telling the clipboard what kind of data you can put on it, the user may try to actually Paste! If this happens, you have to figure out what kind of data they are asking for, and then put the correct kind of data onto the clipboard. To figure out what is being asked for, you check the target. This info is stored in the selectiondata argument, that gets passed in.

Putting Text on the Clipboard
When an application is asking for a string, life is really simple. Every PhotobombItem has a text property, so it's simple to simply set the text of the clipboard with this data.

   def format_for_clipboard(self, clipboard, selectiondata, info, data=None):
if selectiondata.get_target() == "UTF8_STRING":
self.clipboard.set_text(self.clipboard_item.text)

Putting an Image on the Clipboard
But what about when the app has asked to paste an image? The clipboard only supports text, so you can't paste an image, right? Actually, the contents of any binary stream or file can be converted to text, and that text can be put on the clipboard. However, you don't want to simply set the text for the clipboard, as binary data can have characters in it that will confuse a program that thinks it's a normal string. For example, when you read in a file of binary data, you can set that to a string in Python, but other programs not written in Python will probably get have errors if they try to treat it as a string type.

In fact, the clipboard will reject text that is binary data. So, if you have binary data, you need to:

convert it into text
set the selectiondata with the proper target

Photobomb has a function called "image_for_item" that returns image data as binary text, so Phothobomb can just call that function and put the resulting text into the selection data. The "8" in the second parameter tells the selectiondata object essentially boils down to text.

     if selectiondata.get_target() == "image/png":
  selectiondata.set("image/png", 8, self.image_for_item(self.clipboard_item))

Putting a PhotobombItem on the Clipboard
If an instance of Photobomb wants to paste, we need to provide enough information to create a proper PhotobombItem. A PhotobombItem knows a lot about itself, for example, it's clipping path, it's rotation, it's scale, etc... When copyng and pasting within Photobbomb or between instances of Photobomb, we don't want to lose all of that data.

So how do we paste a PhotobombItem if we can only put text on the clipboard? Python has built in support for turning objects into strings. This is called "pickling". So, in the simplest case, we could just convert the Python object to a string, put that string onto the clipboard, and then when convert it from the string back to a Python object.

So, first, import the pickle module:
import pickle

Then you can use "dumps" to dump the object to string:

   if selectiondata.get_target() == "PhotobombItem":
 s = pickle.dumps(self.clipboard_item)
 self.clipboard.set_text(s)

Sadly, this doesn't work for Photobomb because the GooCanvas classes that PhotobombItems derive from don't support pickling. So we can't do this in the simple way. However, what we *can* do, is create a dictionary with enough information to create identical PhotobombItems, and then pickle that dictionary. For photobomb, this gets a bit annoying complex and is not relevant to the blog posting, so I snipped out most of the code. You can always look at the full code on launchpad, of course.

This is, unfortunately, a lot more involved. However, it works just fine:

   if selectiondata.get_target() == "PhotobombItem":
 d = {"type":type(self.clipboard_item)}
 d["clip"] = self.clipboard_item._clip_path
 #snipped out all the other properties that need to be addeed to the dicitonary
 s = pickle.dumps(d)
 self.clipboard.set_text(s)

You don't have to use pickling. For example, you could represent this dictionary in JSON instead. However, pickling is the native serialization formatting for Python, so it's easiest to use it when you can.

Now Photobomb can support copying and pasting into text editors, like Gedit, and image editors, such as the Gimp, as well as into Photobomb itself.

Handling Pasting in Photobomb
The essential paste function is run when the Photobomb user uses Photobomb's Paste command. This function tries to figure out if there are any interesting data types on the clipboard, and then uses them. Typically, such a function should ask for the richest and most intersting data it can handle first, and then less rich data types in order. For Photobomb, the richest data is a PhotobombItem, or course. Then an image, and then finally text. You may have noticed above that when a user pastes from a clipboard, it runs a function in some application. There is no gauruntee that these functions will be fast. For this reason, it's best to use the asyncronous "request" methods on the clipboard.

So, the paste function simply tries to figure out which is the best data type to paste, if any, and then asks the clipboard to call the correct function when the data is ready.

 def paste_menu(self, widget, data=None):
targets = self.clipboard.wait_for_targets()
if "PhotobombItem" in targets:
  self.clipboard.request_contents("PhotobombItem", self.paste_photobomb_item)
  return
for t in targets:
  if t.lower().find("image") &gt; -1:
    self.clipboard.request_image(self.paste_image)
    return
for t in targets:
  if t.lower().find("string") &gt; -1 or t.lower().find("text") &gt; -1:
    self.clipboard.request_text(self.paste_text)
    return

In the cases where another applications has put an image or text onto the clipboard, it's easy to use functions already built into Photobomb to paste those data types. Notice that the return functions already have all the data ready in the form of text or the pixbuf.

   def paste_text(self, clipboard, text, data=None):
  self.add_new_text(text)
def paste_image(self, clipboard, pixbuf, data=None):
  self.add_image_from_pixbuf(self, pixbuf)

When an instance of Photobomb has put the data on the clipboard, it's a bit more complex, because Photobomb has to de-serialize the dictionary, and then create the proper item. Again, I snipped out most of the code for using the de-serialized dictionary, because it just unnecessarily complicated the sample:

   def paste_photobomb_item(self, clipboard, selectiondata, data=None):
  item_dict = pickle.loads(clipboard.wait_for_text())
  if item_dict["type"] is PhotobombPath:
    new_item = PhotobombPath(self.__goo_canvas,
                item_dict["path"],
                item_dict["width"], None)
  #snip out all the code to handle all of the other properties
  new_item.set_clip_path(item_dict["clip"])
  new_item.translate(10,10)
  new_item.set_property("parent", self.__root)
  self.z_order.append(new_item)
  self.add_undo(new_item, None)

Persisting the Clipboard Item
You may have noticed that an item isn't actually put on the clipboard until the user tries to paste. This is a great optimization, because pasting complex or big things can take a lot of time, and there is no point on the user waiting for a copy command to finish if they are never going to actually paste with it. However, what if the user selects "Copy" in your app, and then quits your app? How is the item going to get pasted?

Gtk handles this by letting you "store" data on the clipboard. This can actually be used at any time in your application, but to handle this particular situation, Photobomb just includes a few lines in it's on_destroy function. This causes the desktop's clipboard to store all of the data types, so all the functions for servicing a paste command get called, and the desktop's clipboard holds onto the data as long as it needs.

   def on_destroy(self, widget, data=None):
   """on_destroy - called when the PhotobombWindow is close. """
   #clean up code for saving application state should be added here
   paste_data = [("UTF8_STRING", 0, 0),
      ("image/png", 0, 1),
      ("PhotobombItem", 0, 2)]
   self.clipboard.set_can_store(paste_data)
   self.clipboard.store()
gtk.main_quit()

Coding an Undo/Redo Stack

2011-06-18T11:17:00.000-07:00

The other night I put (what I think are) the finishing touches of an Undo/Redo stack for Photobomb. This is the second time I've written an Undo/Redo stack, the first time being for the TextEditor Quidget. Neither time was I able to find much guidance for how to approach the problem. I handled it slightly differently each time. I thought I'd write up a blog post about how I approached Undo/Redo for Photobomb, in case it helps someone else out.

Generally, the way I conceived the problem was to keep a list of actions that needed to be undone. When an action is undone, then that action needs to be added to a list of actions that can be redone. But what does it mean to store an action in code? I thought of 2 approaches:

Keep a list of actions as functions along arguments to pass to those functions.
Keep a list of "backups" for every change made to an object, and on redo swap out the backup for the actual object.

List of Actions Approach
I took the first approach back when I wrote TextEditor. It was easy to do because the only actions supported by Undo and Redo was that something could be added to the TextBuffer, or something could have been removed. So I very literally stored a list of functions and elements. So on a change, such as when text has been inserted, I store point at which the text was inserted, along with the inserted text:

     cmd = {"action":"delete","offset":iter.get_offset(),"text":text}
  self._add_undo(cmd)

The _add_undo function merely ensures that the list does not grow beyond a defined maximum, and adds it to the undo list:

   def _add_undo(self, cmd):
  if self.undo_max is not None and len(self.undos) >= self.undo_max:
    del(self.undos[0])
  self.undos.append(cmd)

The heart of the __add_undo command was to extract the command to undo, and pass it along to _do_action(), and then add the return value of undo to redo stack.

     undo = self.undos[-1]
  redo = self._do_action(undo)
  self.redos.append(redo)
  del(self.undos[-1])

do_action, in turn read the type of action, did the specified action, and returned the opposite action so it could be used for redo.

     if action["action"] == "delete":
    self.get_buffer().delete(start_iter, end_iter)
    action["action"] = "insert"
  elif action["action"] == "insert":
    self.get_buffer().insert(start_iter, action["text"])
    action["action"] = "delete"
  return action

So by keeping a mapping of actions and their opposites, and by using a dictionary to store the information needed to undo or redo the action, this system worked well for simple case of simple text editor.

List of Backup Approach
Not surprisingly, when I approach this problem in Photobomb, I followed the same basic solution path. For example, I set up a list to store undo actions in. I then started storing a code for actions like I used for delete and insert in the text editor. However, I quickly ran into some problems. Photobomb is more complex then TextEditor, and GooCanvas is more complex than TextView/TextBuffer. For example, storing all the info needed for undoing and redoing a clipping path on an object required some more complex code than seemed right for the problem. So, I switched to the second approach.

Here, I store a list of undos, but what I store in the list is objects. A "new" object, as in the object after the change, and the "old" object. Kind of like the backup.

To store an undo in this system, I make a back up of the object, change it, and then add the undo:

       saved_item = self.back_up_item()
    self.selected_item.move(delta_x,delta_y)
    self.add_undo(self.selected_item, saved_item)

Making the backup entailed duplicating the entailed not just making a copy, but removing the copy from the goocanvas, and storing the z-order. GooCanvas doesn't track z-order for you, so I had to track it myself. Every object on the GooCanvas suface derives from a subclass of the custom PhotobombItem and one of the built in GooCanvas types, such as goocanvas.Image). PhotobombItems have a duplicate function witch return a copy, and a remove function. So getting a copy was easy.

   def back_up_item(self, item=None):
  if item is None:
    item = self.selected_item
  copy = item.duplicate(True, False)
  copy.remove()
  index = self.z_order.index(item)
  self.z_order.insert(index+1,copy) 
  return copy

I quickly found that it is insufficient to simply store a pair of old and new objects for each undo. This is because an object can be modified twice in a row. And if you store the object itself, rather than a copy of the object, the undo stack will reference the object in whatever is it's current state, so undo can appear to weirdly go backward.

For example if I make an item, call it O1 bigger, I'll store a copy of O1, call the copy O1.1, and O1 as the old and new items, respectively. Then if I make it bigger again, I store another copy of O1, call it O1.2, and O1 *again*. So undoing will go O1 is replaced by O1.2, which looks right, but then undo again and O1 will be replaced by O1.1. But oops, O1 was already replaced, so O1.1 appears, but O1.2 was never replaced.

To guard against this, I looked backward through the undo stack to see where in the current undo stack the object appears last, and I take the current backup of the "old_item" and make that the "new_item" for the previous undo. So, for then making something bigger would store O1.1 and O1 again, but then making it bigger again, it would replace O1 with O1.2 as the "new_item" and then store O1.2 and O1 as the new_item at the top of the undo stack. So undo would replace O1 with O1.2, and then O1.2 with O1.1, and everything seems to work.

That was a pretty long winded explanation for not that much code. Basically, I loop back through the undo stack and update the last occurrence of the object being added with the copy before going ahead and adding the objects to the stack.

   def add_undo(self, new_item, old_item):
  #ensure proper undos for multiple edits of the same object
  if len(self.undos) > 0:
    for item in self.undos[::-1]:
      if item["new_item"] is new_item:
        item["new_item"] = old_item
        break
  self.undos.append({"new_item":new_item,
              "old_item":old_item})
  self.redos = []

Note that I also reset the redo stack whenever the undo stack is modified.

So what does undo and redo do? They function in a very similar manner to the undo/redo functions in the text editor. First, they get they item from the top of the stack and stick it on the other stack. So for undo:

     undo = self.undos[-1]
  self.redos.append(undo)
  del(self.undos[-1])

Then they remove the new item, and restore the backup (assuming they both exist). If there is no backup, that means the item was just created, so removing the item is sufficient. Conversely, if there is no new item, then it means the item was deleted, so adding it back to the canvas is sufficient. Finally, the function has to position the new item in the z-order and then select the new item.

     if undo["new_item"] is not None:
    undo["new_item"].remove()
  if undo["old_item"] is not None:
    undo["old_item"].set_property("parent",self.__root)
    next_item = self._find_item_above(undo["old_item"])
    if next_item is not None:
      #position in z-order
      undo["old_item"].lower(next_item)
  self.selected_item = undo["old_item"]
  self.__reset_selection()

Redo does essentially the same thing, only removes old_items and restores new_items. There was about 100% code duplication between the undo and redo functions. However, I decided to keep the duplicate code in place because I was worried that if I have to go back and fix bugs in a year or so, I'd need the code to be crystal clear about what it did. I can always refactor into a common function later, but for now, I felt that the duplicated code was just easier to read and understand.

Now, calling these functions is easy in cases where a menu item was used to change on object, as there was one and only one change to store in the undo stack. But sometimes it's not so easy. For example, Photobomb has what I call "Press and Hold Buttons". To make an item bigger, for example, you can use the Bigger menu item, or you can hold down the Bigger button until the selected object is the size that you want and release the button. The button emits a signal called "tick" every 100 milliseconds, which is bound to an action, in the case, the "self.bigger" function. This causes the item to get bigger many many times (about 10 times per second, in fact) but the user is going to think of it as one action to be undone.

In order to handle this case, I created two signal handlers, one for the press event and one for the released signal of a button. All the Press and Hold buttons use these handlers. The press signal handler creates an immediate copy of the item, and then connects the tick and the released signals. Occasionally, the released handler gets called twice, which causes some confusion, so I track the tick signal to make sure that the released signal is only handled once.

   def pah_button_pressed(self, button, action):
  old_item = self.back_up_item()
  tick_signal_id = button.connect("tick",action)
  button.connect("released",self.pah_button_released, (tick_signal_id, old_item))

Then in the released signal, I add the new item and the old_item to the undo stack, assuming it hasn't been already.

   def pah_button_released(self, button, args):
  tick_signal_id, old_item = args
  #work around released signals being called multiple times
  if tick_signal_id in self.__disconnected_tick_signals:
    return
  self.__disconnected_tick_signals.append(tick_signal_id)
  button.disconnect(tick_signal_id)
  if self.selected_item is not None:
    self.add_undo(self.selected_item, old_item)

Now only 1 undo is added when a Press and Hold Button is used.

Another challenge to overcome in this system was handling the user changing selection by clicking on an item versus when the user clicked and dragged an item. The latter should be added to the undo stack, but not the former.

Fortunately, this can be handled with a similar pattern. The mouse_down signal handler creates a copy of the item, and passes it to the mouse_up signal handler.

           old_item = self.back_up_item(clicked_item)
        self.__mouse_up_handler = self.__goo_canvas.connect("button_release_event",self.drag_stop, old_item)

Then the drag_stop function checks if the item was actually moved before adding to the undo stack. If the item hasn't been moved, then the selection has simply changed.

Finishing Touch
One last finishing touch is to ensure that the undo and redo menu items are only sensitive if there is anything in the undo and/or redo stacks. Photobomb handles this by connecting to the activate signal of the edit menu, and then checking if there is anything in the undo and redo lists, and setting the sensitivity accordingly.

   def edit_menu_reveal(self, widget, data=None):
  active_undos = len(self.undos) > 0
  active_redos = len(self.redos) > 0
  self.builder.get_object("menuitem_undo").set_sensitive(active_undos)
  self.builder.get_object("menuitem_redo").set_sensitive(active_redos)

There is a lot of ineractivity in photobomb, and this creates a bit of complexity in handling undo/redo. You can see all the code in context in the photobomb trunk.

My Effort at Writing Help for Unity

2011-04-19T16:23:00.001-07:00

I told the kind folks in #ubuntu-doc that I'd give it go, writing up some documentation for Unity. Here's a first draft of my best effort. I'm hopeful that the real pros at this can mine this material for making nice official documentation. I'm hoping that thay can cut and paste from here into their docs, or at least can edit the content to something they like, but maybe get going a little faster since there is something to change, rather than having to start fresh.

I don't believe myself to be a particularly good writer, but, here without further a do ...

Overview

The Unity environment has four areas that, combined, allow full operation of Ubuntu.
These areas are:

The Application Area. This is the main area of the screen for applications and documents.
Indicators. Indicators run along the panel at the top of the screen, off to the right Indicators are persistent widgets that are always available for reference and Controlling Ubuntu. Indicators include functionality for things like networking, power, messaging, time, and managing a session.
The Launcher. This provides access to favorite applications and running applications.
The Dash (not shown). The Dash provides very fast access to applications and files via searching or browsing. The Dash can also be customized with new "lenses" to allow other types of searching.

How to Activate Applications via the Launcher

If the icon for the desired application is on the launcher, you can simply click on the icon, and it will launch the application. If the application is already running, clicking on the icon will activate the running application and bring it to the front. For example, if you click the Firefox icon on the launcher, this will launch Firefox, unless a Firefox window is already open, in which case Firefox will be brought to the front.

After launching an application, The Launcher, my "autohide" by sliding off the screen to the left. If this happens, it can be easily accessed by pointing the mouse all the way to the of the screen and waiting for the launcher to appear, or pointing to the top left corner of a screen will cause the launcher to appear instantly.

Running applications will have one tickmark to the left of the icon for each Window that is open. In this way, it is possible to see how many windows are open for an application.

Clicking on an icon with the middle mouse button will open a new window for a running application. Some applications also support open a new window via a "Quick List". Right clicking on an icon will reveal the Quick List for the application. For example, Firefox has a "Open New Window" option in the Firefox Quick List.

The Launcher can also be used via the keyboard, without the mouse. In order to activate an icon on The Launcher, press and hold the meta key on the keyboard (for example, on computers that came with Windows installed, there may be a Windows logo to mark the meta key). Pressing and holding the meta key will cause The Launcher to open, and each icon on The Launcher will be marked with a number or letter.

Clicking the keyboard key with the number or letter that corresponds to the desired icon while still holding down the meta key will activate that icon. Holding down the shift key as well while doing so will launch another instance of the application, similar in function to middle clicking with the mouse.

How to Activate Applications from the Dash

The Dash is activated by clicking on the Ubuntu logo in the top left of the screen, or by tapping on the meta key. When The Dash is activated in this way, it defaults to the Global Search lens. Commonly used applications and application categories are available by default.
The Global Search lens searches files as well as applications, so files can be quickly accessed in the same manner.

To quickly activate an application, typing the first few letters of an application will show the application's icon, which can then be clicked to activate. Alternatively, typing the Enter key on the keyboard will cause the first item in the list to be activated. In this way, an application can be run very quickly by tapping the meta key, typing the first few letters of the applications name, and pressing Enter.
The More Apps icon allows browsing of all installed applications. This view can also be activated by the Applications Lens icon on The Launcher. Applications are grouped into three categories, most frequently used, all installed applications, and applications that are available to be installed via Software Center. Note that if

Any of these section can be expanded by clicking the "See more results" link. For example, clicking "See more results" on installed applications will show all installed applications.
To limit the displayed applications to a category of applications, a category can be selected via the category selection dropdown.
The Quick List for the Application Lens allowss fast access to an application category.
Choosing one, will open The Dash and disply the selected category.

Adding an Application to The Launcher

An application can be added to the launcher by dragging the application's icon from The Dash onto the launcher. Alternatively, when an application is running, the Keep in Launcher item in the application's Quick List will permamently add the application to The Launcher.

Once on The Laucher, an icon's position on The Launcher can be changed by dragging it first off of The Launcher, and then back onto it in the desired location.

Finding and Opening Files

Files can be quickly searched and opened from The Dash. The Dash is activated by clicking on the Ubuntu logo in the top left of the screen, or by tapping on the meta key. When The Dash is activated in this way, it defaults to the Global Search lens. Commonly used applications and application categories are available by default.

The Global Search lens searches applications as well as files, so applications can be quickly accessed in the same manner.

To quickly open a file, typing the first few letters of the file name will show the file's icon, which can then be clicked to open. Alternatively, the icons can be navigated with the arrow keys, and typing the Enter key on the keyboard to open the selected file.

The Files and Folders Lens supports browing for files. The Files and Folders Lens can be activated via the Find Files icon in the Global Lens, or by clicking on the Files and Folders Lens icon on The Launcher. This lens presents recently used files, and commonly used folders.

Any of these views can be expaned using the "See more results link".

Searching file title and contents is supported in the search field, producing a list of results if any matching files are found.

The Files and Folders Lens also supports browsing for files by type, by choosing a type of file from the file type dropdown.

Selecting a file type will produce a list of files ordered by time.

While a file type is selected, search results will be limited to that file type.

The Quick List for the Files and Folders Lens icon on The Launcher allows fast navigation to a file type filter in The Dash.

Running Applications in Unity

With a few exceptions (notably Libre Office) menus for an active application window will be availble on the long top panel of Unity, in the Menu Indicator. When the menus are not active, the window title will be display there.

To see the menus that are available, simply hover your mouse over or near the window title, and the menus will be revealed, and you can then click on them.

Alteranatively, pressing the Alt key will also review the menu for the active window, along with any available keyboard accelerators.

Running applications will have one tickmark to the left of the icon for each Window that is open. In this way, it is possible to see how many windows are open for an application. Clicking on the application's icon in The Launcher will bring the application to the foreground.

Clicking on an icon with the middle mouse button will open a new window for a running application. Some applications also support open a new window via a "Quick List". Right clicking on an icon will reveal the Quick List for the application. For example, Firefox has a "Open New Window" option in it's Quick List.

Managing Windows

Switching Between Active Windows

Ubuntu offers many methods for managing and switching between mulitple windows. The fastest way to switch between a window on top, and a window directly below it to hold down the Alt key, and quickly pres the Tab key. This will cause the top window to switch places with the second window. Quickly tapping Alt and Tab again will switch them back. Two windows can be alternated very quickly in this manner.

Alt and Tab can also be used to switch to a window that is not the second window. Pressing the Alt key and holding down the Tab key will quickly bring up a list of open windows. Pressing Tab will select each window in turn. Release Alt and Tab will cause the currently selected window to come to the front.

If there are mulitple windows open for a particular application, clicking on The Launcher icon for the desired application will reveal of all the windows. Clicking on the desired window will bring that window to the front.

Pressing the Meta key and W will cause all open windows to be revealed, no matter the application with which they are associated. This faciliates quickly finding any application that is open, no matter the Workspace the window is on.

Window Size and Positioning

Document and application windows typically have the following three buttons for controling the size and visibility of the window:

close
minimize
maximize

Clicking the close button will close the current window and potentially quit the application as well.

Minimize will hide the window altogether. A minimized window can be accessed by clicking on the application's icon in The Launcher, or by navigating to the window by holding down the Alt key and holding down the Tab key and then tapping the Tab key until the minimized window is selected.

A window that takes up the whole screen is "maximized". For an unmaximized application, clicking on the maximize button will cause the window to maximize. Clicking on the maximize button for a maximized will cause the window to unmaximize.

A window can also be toggled between maximized and unmaximized by double clicking on the applications titlebar.

Dragging an unmaximized window's title bar to the top of the screen will maximize the windw. Dragging a maximized windows title bar to the center of the screen will unmaximize it. Dragging a window by the titlebar to the the right or the left of the screen untl the mouse pointer touches the edge, will resize the window to take up half of the screen. This can be useful for sizing windows and using them side by side.

Workspaces

Workspaces provide a means for organizing windows into groups, and quickly switching between those groups. For example, windows associated with work could be grouped onto workspace 1 while windows associated with chatting with friends could be groupled onto workspace 2. By default, all applications are opened onto Workspace 1. There are four available workspaces.
Clickng The Workspace Switcher on The Launcher provides an overview of the four workspaces, arranged in a grid.
Clicking on a workspace, and then clicking on The Workspace Switcher will make that workspace the active workspace. Applications launched from The Launcher or The Dash will be open on the active workspace.
Note that clicking on an icon in The Launcher for an active application, will navigate to that application. If the application is on a different workspace, that workspace will become active. A new window for an application can be open by middle clicking on the application's icon in The Launcher, or using the Quick List for some applications.
Holding down the Meta key and Clicking S is a short cut for activating The Workspace Swithcer. Holding down the Control and Alt keys, and clicking on the arrow keys very quickly navigates between workspaces.
Window can be moved between workspaces while the Workspace Switcher is active by simply dragging windows between the workspaces.

Settings

System Settings can be accessed via the Control Center dialog. To activate the Control Center, select System Settings from the Power Menu.
You can then choose the specific settings you are interested from the list.
Alternatively, you can navigate directly to the settings that you are interested from The Dash.

Congrats to GNOME!

2011-04-07T05:45:00.000-07:00

Today you'll see the above banner on http://www.ubuntu.com/, as the 2nd banner linking through to the Gnome web site. That's because yesterday was a big day for the GNOME team, they delivered GNOME 3.0. Yesterday the GNOME community got the ball over the goal line, and delivered GNOME 3.0! An exciting time, indeed.

I know from my own experiences how difficult it is to do what they did. Delivering GNOME 3.0 with all it's platform improvements and it's slick new experience is a momumental achievement of teamwork and leadership. GNOME 3.0 is a major contribution to Free Software, and it continues the GNOME tradition of user-centered design, and community-centered development. GNOME 3.0 will be instrumental in powering Ubuntu for years to come, as well as countless other distros and projects.

The release itself seems flawless, from the product they delivered to the roll out on the website.

Congrats and also a heartfelt "Thanks" to all my friends in GNOME.

Unity Almost There

2011-04-05T09:42:00.000-07:00

So, I'm a bit surprised how much people liked my spider diagrams to update folks on my perception of the state of Unity. It's been hard to update that last few months, just because Unity has been changing so fast. However, those changes have slowed down, and I've gotten some requests, so here is my post-beta 1 spider diagram for Unity.

As you can see, the orange line, Unity, almost overlaps the yellow line, our target for Natty. Obviously, this is a major accomplish for many teams involved in this project. I've been using Unity and my netbook and on my desktop for months now. Over the last few weeks it has crisped up into a very tight experience. Of all the desktop environments I have ever used, Unity is by far my favorite.

Here are some notes on the remaining gaps:

Crashers
One thing not reflected in the graph is the number of crashers, particularly in compiz, that have been reported. The crash reports have slowed down, and the crashes are getting fixed. If we stay focused, I believe that we will fix all of the common, and most of the not so common crashers.

Accessability
The only very painful gap is in accessability. Unity is very keyboard friendly, so that's good. The Launcher is completely exposed to screenreaders, so that's good. However, the dash is not completely exposed to screen readers. This means that blind users won't be able to use Unity without some modifications. This is unfortunate, indeed. Fortunately, the "classic" desktop is still as accessible as it has always been. Work continues on making the dash accessible, but it won't make it into Natty by release. I'd love to see a PPA or even an SRU to close this gap after release.

Search
Search is good, however, there are certain substring searches which maddenly don't work yet. For example, if I search for "Torrent" I don't get Transmission in the list, because it's a "BitTorrent" client.

Find and Launch Apps
I think the category view is good, but could be a bit easier to find and activate.

Dash Performance
Sometimes when I do a search in the Dash, it thinks for a bit before it responds to my enter key. This slows me down a bit when I am trying to launch something quickly.

Video Demonstraton of a Few Things I Like in Unity

2011-04-04T14:59:00.000-07:00

Here are a couple of quick videos I made this morning demonstrating some things that I think are cool in Unity.

EDIT: Please note that Unity actually goes much faster than it appears to in these videos. There are certain points where the video didn't really seem to keep up with Unity for some reason.

Dash
This demo shows using categories in the dash, and also being able to use the dash to quickly open apps without using the mouse.

Launcher
This demo shows using the meta-key to use the launcher to switch to apps and launch apps. It also shows a little trick that you can use to put any command you want onto the launcher.

Easily Support the Sound Menu in Python

2011-02-21T19:34:00.000-08:00

An important part of integrating with the Ubuntu desktop is ensuring that your application is using all of the appropriate indicators. In this entry, I explain how I added support for the Ubuntu Sound Menu to the sample application "Simple Player."

Ubuntu's Sound Menu allows users to access some of a media players functions without the user having to find the application window and use the applications controls. To add support for the Sound Menu controls, which allow the user to Play, Pause, and use Next, and Previous functions, takes 4 basic steps:

Create a Desktop File so the Sound Menu knows that it should display your application.
Add sound_menu.py to your application, instantiate a SoundMenuControls object, and start a dbus main loop.
Implement functions from the SoundMenuControls so that the Sound Menu can control your application.
Call functions on the SoundMenuControls objet so that the Sound Menu knows about changes that your applications makes.

Creating the Desktop File
If you are developing an application, and have not installed it, most likely you do not have a desktop file installed. Desktop files are used in Linux desktops to describe your application to the system. Many parts of the desktop refer to desktop files for things like creating application launchers and menus, file handling support, etc... The Ubuntu Sound Menu uses desktopfiles to determine which applications it should launch and handle. In a default Natty install, only Banshee will have a desktop file that the Sound Menu will detect and want to handle.

Desktop files all live in /usr/share/applications/. A quickly project has a file called app-name.desktop.in. This file will be turned into a real desktop file by the packaging and installation system. But it won't work for development, so you'll want to create a new one and copy it into /usr/share/applications/.

For simple-player, I created a desktop file with the following contents:

[Desktop Entry]
Name=Simple Player
Comment=SimplePlayer application
Categories=GNOME;Audio;Music;Player;AudioVideo;
Exec=simple-player
Icon=simple-player
Terminal=false
Type=Application
MimeType=application/x-ogg;application/ogg;audio/x-vorbis+ogg;audio/x-scpls;audio/x-mp3;audio/x-mpeg;audio/mpeg;audio/x-mpegurl;audio/x-flac;

When I named it, I made sure to name "simple-player.desktop". Then I used:
$sudo cp simple-player.desktop /usr/share/applications/
to copy it into the applications directory where the Sound Menu could find it. Then I logged out and logged in again so that the Sound Menu could discover it.

Now Simple Player shows up as an option in the Sound Menu!

There is no icon, because I have not installed the icon for Sound Menu. Also, clicking the Simple Player menu item won't launch Simple Player because the application is not actually installed. Both of those problems will be fixed when the application is properly packaged and installed.

Get sound_menu.py
The Sound Menu communicates with applications via the MPRIS2 DBUS API. This was a good choice by the Sound Menu developers because many applications already support MPRIS2. However, doing DBUS programming, especially with Python, can be a tad complex. Since I didn't want application programmers to have to rewrite all the DBUS code every time someone wants to integrate a Python application with the Sound Menu, I create a module called sound_menu.py to encapsulate all the DBUS goo. Note that sound_menu.py does not implement all of the MPRIS2 specification, only the parts that the Sound Menu needs.

To get sound_menu.py, it's probably easiest to check it out from launchpad account:
$bzr branch lp:~rick-rickspencer3/+junk/sound_menu

This will create a directory called sound_menu, with a single file sound_menu.py. If you want to, you can look at sound_menu.py and copy and paste the code into your program to make it work. However, sound_menu.py is designed so that you can easily mix it into your application without having to modify it, or work with the DBUS calls directly. We'll go that route for Simple Player.

So the first step is to copy the sound_menu.py file into the library for Simple Player. For example:
$cp sound_menu/sound_menu.py simple-player/simple_player/

Setting Up sound_menu in Your Code
Now that the sound_menu module is copied into the applications library, there are a few steps to take before you can really start programming it.

First, you need to import the SoundMenuControls class from the sound_menu module. I did this in the simple-player file with the other simple_player imports, right above the class deceleration section. So I added the bottom line:

from simple_player import (BaseSimplePlayerWindow)
import simple_player.helpers as helpers
from simple_player.preferences import preferences
from simple_player.sound_menu import SoundMenuControls

The is one other really important piece of book keeping required before you can create a SoundMenuControls object. It is necessary to start up a DBUS main loop. For simple-player, the easiest place for this is in the __main__ function, so I added the following lines:


  #turn on the dbus mainloop
  from dbus.mainloop.glib import DBusGMainLoop
  DBusGMainLoop(set_as_default=True)

Making the whole main function look like this:


if __name__ == "__main__":
  # Support for command line options.  See helpers.py to add more.
  helpers.parse_options()

  #turn on the dbus mainloop
  from dbus.mainloop.glib import DBusGMainLoop
  DBusGMainLoop(set_as_default=True)

  # Run the application.
  preferences.db_connect()
  preferences.load()
  window = SimplePlayerWindow()
  window.show()
  gtk.main()
  preferences.save()

Create an Instance of SoundMenuControls
Now that we've done the booking keeping to import the SoundMenuControls class, and also to start a DBUS loop, it's possible to intantiate a SoundMenuControls object. To create a SoundMenuControls object, you need to tell it the name of the desktop file to look for. So, I added this line to the bottom of the finish_initializing function in simple-player:
self.sound_menu_controls = SoundMenuControls('simple-player')

Using "$quickly run" to start simple-player, notice that the Sound Menu now knows that it is running, and presents the Controls for it.

Implement the _sound_menu_* Functions
If you click on the different buttons and such, though, you'll notice that sadly they don't work. Well, why would they? The Sound Menu doesn't know how to make Simple Player do what it wants. In order to do that, we need to implement a few functions, and tell the SoundMenuControls object to use those functions. Then we'll need to add a little bit of code to inform the Sound Menu when changes occur in Simple Player too.

All of the functions that you need to implement start with "_sound_menu_*". I named them this way so that it was obvious what the functions were for, and also so that they weren't likely to conflict with any code that you already wrote.

There are 2 different approaches that you can take to implement SoundMenuControls's functionality in your application. You can inherit from it, typically by using multiple inheritance, or you can assign functions to the _sound_menu_* functions. This later method, though while not quite as clean, is a bit easier, so I went with that.

The first thing I did was create local implementations of the necessary functions. Note that I could have named them whatever I wanted, but I decided to just stick with the names from SoundMenuControls. There are 6 functions that must be implemented. I added te following functions directly below the finish_initializing function. I think between the names and the comments, they are pretty self-explanatory, so I won't cover each one.


      def _sound_menu_is_playing(self):
          """return True if the player is currently playing, otherwise, False"""
          return self.player.playbin.get_state()[1] == gst.STATE_PLAYING

      def _sound_menu_play(self):
          """start playing if ready"""
          if len(self.ui.scrolledwindow1.get_children()[0].selected_rows) > 0:
              self.player.play()

      def _sound_menu_pause(self):
          """pause if playing"""
          if self.player.playbin.get_state()[1] == gst.STATE_PLAYING:
              self.player.pause()

      def _sound_menu_next(self):
          """go to the next song in the list"""
          self.play_next_file(self, None)

      def _sound_menu_previous(self):
          """go to the previous song in the list"""
          self.play_previous_file()

      def _sound_menu_raise(self):
         """raise the window to the top of the z-order"""
         self.get_window().show()

Note that the _sound_menu_is_playing function and the _sound_menu_pause functions both work by checking the state of the player's playbin. This requires a comparison to an enum in gstreamer. This won't work unless you import gstreamers, so remember to add "import gst" to your import statements.

Note that the functions are actually quite simple. They provide a mapping from the actions that a user takes in a sound menu, to the functions in the simple-player file. Now I just need to tell my SoundMenuControls object to use those functions instead of the ones that it comes with. I do this by simply assignment, directly after the line where I created the object:


          self.sound_menu = SoundMenuControls("simple-player")
          self.sound_menu._sound_menu_next = self._sound_menu_next
          self.sound_menu._sound_menu_previous = self._sound_menu_previous
          self.sound_menu._sound_menu_is_playing = self._sound_menu_is_playing
          self.sound_menu._sound_menu_play = self._sound_menu_play
          self.sound_menu._sound_menu_pause = self._sound_menu_pause
          self.sound_menu._sound_menu_raise = self._sound_menu_raise

There is one problem though, while I implemented play_next_file() to make it so that when a song finishes, it can go on to the next song, I didn't need to implemented play_previous_file(). A little copy/paste and some tweeking, I added play_previous_file right below play_next_file. It looks like this:


  def play_previous_file(self):
     #get a reference to the current grid
     grid = self.ui.scrolledwindow1.get_children()[0]

     #get a gtk selection object from that grid
     selection = grid.get_selection()

     #get the selected row, and just return if none are selected
     model, rows = selection.get_selected_rows()
     if len(rows) == 0:
         return

     #calculate the next row to be selected by finding
     #the last selected row in the list of selected rows
     #and decrementing by 1
     prev_to_select = rows[-1][0] -1

     #if this is not the last row in the last
     #unselect all rows, select the next row, and call the
     #play_file handle, passing in the now selected row
     if prev_to_select != 0:
          selection.unselect_all()
          selection.select_path(prev_to_select)
          self.play_file(self,grid.selected_rows)

At this point, the Previous and Next buttons work in the Sound Menu, but the Play button doesn't, and no song information is displayed. This is because we've only implemented the part where the Sound Menu tells Simple Player what to do. We have to add a few lines of code so that Simple Player can tell the sound menu things like when it is starting a song, has been paused, etc...

We'll start by telling the Sound Menu about new songs. The logical place to do this is at the end of a the play_file function, as this typically means that Simple Player has started a new song, we use the SoundMenuControls object's song_changed() function to let the Sound Menu know there is a new song playing. You can tell the Sound Menu about the song's artist, album, and title. These are all named arguments of song_changed. Simple Player isn't too smart, so only knows the file name of the current song playing, so we'll use that for the title. You'll also need to alert the Sound Menu that the song is playing, using the signal_playing function. Adding the following lines to end of play_file takes take of keeping the Sound Menu up to date:

            self.sound_menu.song_changed(title = selected_rows[-1]["File"])
          self.sound_menu.signal_playing()

Now the Play/Pause button works, and the song title stays in sync as we make changes. But it's still possible for Simple Player and the Sound Menu to get out of sync. If I pause the song in Simple Player, and then use the Sound Menu, notice that the Sound Menu still thinks the song is playing because Simple Player never told the Sound Menu that the user paused it.

You may recall when building Simple Player that it was easy to get access the controls for the MediaPlayerBox. So, to finish off the integration, we'll connect to the signal handler for that button, and then tell the Sound Menu when it's been used.

First, connect to the "toggled" signal for the play button. I added this line to the end of the finish_initializing function:


          self.player.play_button.connect("toggled",self.play_button_toggled)

Then, directly under that, I implemented the play_button_toggled function. This function tests if the widget is active, and informs the Sound Menu of the changed state, as appropriate:


  def play_button_toggled(self, widget, data=None):
      if widget.get_active():
          self.sound_menu.signal_playing()
      else:
          self.sound_menu.signal_paused()

Now the Sound Menu and Simple Player stay in perfect sync!

New in Natty, the Sound Menu also includes support for playlists. I'm planning to add SoundMenuPlaylists as another class i the sound_menu module. In this way, applicatins such as Simple Player that don't have playlists can just implement the controls part. But other applications could implement the Playlist functionality.

Python Sound Menu Integration or GDBUS Can't Come Soon Enough

2011-02-04T10:54:00.001-08:00

So I'm still digging Pithos. Having native access to my Pandora channel on my desktop is a blast. I thought a great enhancement would be Sound Menu integration. So I figured I would spend an hour or two implementing an the mpris2 dbus interface to make this work for Pithos.

Well, the platform had this to say to me: "Ha ha ha ha ha"

It seems simple enough, if you implement the Impres2 interface, you get Sound Menu integration, along with other benefits. Well, it turns out that implementing such an interface in Python is an exercise in frustration.

There is little documentation on how to implement a dbus interface in Python.
So far as I can tell, there is no way to decorate a property to make it a dbus property, and there is not documentation on how to work around this.
After working around how to make properties, one is exposed to all kinds of weird dbus internals. For example, you can't just return a dictionary, you have to send a dbus.Dictionary object.

Fortunately, I know people who could help and get me unstuck. So, as of today, I have some stub code that makes something useful show up in the Sound Menu.

So what's next? Well, I intend to turn this code into a Python API for the Sound Menu. I'm not going to try to handle the whole mpris2 integration at this point, just implement what is needed for the sound menu to work. The API should not expose any DBUS or MPRIS concepts.

Then I'll see if I can use my API to add Sound Menu integration to Pithos. Also, I should be able to use simple-player as a demo for it.

So, if you are a Python hacker, and you want to get something into the Sound Menu, stay tuned, I should be able to help you out soonish. The code is still all stub code, but if you absolutely must look, I pushed a branch.

Pithos of Rain

2011-01-23T09:25:00.000-08:00

During my normal Sunday morning chill out with a cup of coffee this morning, I saw a tweet from Ken VanDine go by about Pithos, a native Pandora client for Ubuntu. I have a Pandora account, and love to use it on my phone, but on Ubuntu I had to go through the Pandora web interface, so I didn't use it as much.

I'm using it right now, and I'm chuffed. I'd love to see this app go through the ARB process so maverick users can more easily access it. And ~~I'd love to see it~~ I'm psyched to hear that it is in Universe or and even Debian for Natty.

The Dash Has Landed

2011-01-21T15:27:00.000-08:00

User visible changes to Unity have slowed down quite a bit until this week. There have been things like bug fixes landing, and the nm-applet getting indicatorized, and then that getting fixed up. But essentially, Unity has been just the launcher and the panel with indicators for weeks.

Then this week, 2 important new things landed. First, the beginning of accessibility support. I don't use accessibility support myself, so this dimension is hard for me to assess, but as you can see from this screenshot, Unity is now announcing itself.
It isn't reporting it's objects sufficiently to actually use yet, but I'm bumping up the accessability dimension a tad from zero to account for this project. Also, alt-keys work in application menus now!

The other thing that landed is the dash. Now you, can see from the above screenshot that it's a crude first cut at the dash, only let's you click a few buttons. However, there is a lot of work underhood to make that show up. So, I expect we'll see search showing up soon! Than after that, there won't be too much work to get the dash up to functional parity with Maverick!

So, the updated spider diagram shows that Unity is almost covering it's shape from Maverick.
Hopefully with the introduction of the the dash, the left hand side of the graph should start filling in very quickly.

Some other notes ...

Launcher

I bumped up launcher quality because crashers have gone down, but I[m still getting menus out of z-order, which makes them show up behind other windows. This effects all of the system, so it's probably really compiz not the launcher, but it makes the launcher unusable at times. This may be fixed today, but sicne it's intermitent, it's hard to say.
New animations and new backgrounds make the launcher look nicer
The addition of “open new window” and the autohide functions make this close to complete, in fact, I'm wondering what users are really missing now. I guess quick lists and the ability to display status on an icon in the launcher will make it feature complete.

Dash

As of today, a panel comes up allowing you to click some big buttons.
There is not yet any search.
There isn't any animation or mouse over effects and such.
The look of the panel so far is "ok", a bit blocky and such. I expect that the look and feel will be refined quickly.
The panel appears instanty. That's very nice and I hope that doesn't change.

Indicators

With the introduction of the nm-applet in indicator form, the indicators seem feature complete.
The indicators also suffer badly from the z-ordering bug I mentioned above.
I'm not sure about the whole thing of hiding menus when the mouse is not over them. It seems like it should bother me, but it really doesn't.

Quickly Tutorial for Natty: DIY Media Player

2011-01-09T14:34:00.001-08:00

I started working on a chapter for the Ubuntu Developers' Manual. The chapter will be on how to use media in your apps. That chapter will cover:

Playing a system sound
Showing an picture
Playing a sound file
Playing a video
Playing from a web cam
Composing media

I created an app for demonstrating some of these things in that chapter. After I wrote the app, I realized that it shows a lot of different parts of app writing for Ubuntu:

Using Quickly to get it all started
Using Glade to get the UI laid out
Using quickly.prompts.choose_directory() to prompt the user
Using os.walk for iterating through a directory
Using a dictionary
Using DictionaryGrid to display a list
Using MediaPlayerBox to play videos or Sounds
Using GooCanvas to compose a singe image out of images and text
Using some PyGtk trickery to push some UI around

A pretty decent amount of overlap with the chapter, but not a subset or superset. So I am writing a more full tutorial to post here, and then I can pull out the media specific parts for the chapter later. Certain things will change as we progress with Natty, so I will make edits to this posting as those occur. So without Further Ado ...

Simple Player Tutorial
Introduction
In this tutorial you will build a simple media player. It will introduce how to start projects, edit UI, and write the code necessary to play videos and songs in Ubuntu.
The app works by letting the user choose a directory. Simple Player then puts all the media into a list. The user can choose media to play from that list.

This tutorial uses Quickly, which is an easy and fun way to manage application creation, editing, packaging, and distribution using simple commands from the terminal. Don't worry if you are used to using an IDE for writing applications, Quickly is super easy to use.

Requirements
This tutorial is for Ubuntu Natty Narwhal (11.04). There are some key differences between 10.10 and 11.04 versions of Quickly and other tools that will make it hard to do the tutorial if you are not on Natty. So, probably best to make sure you are running 11.04.

You also need Quickly. To install Quickly:

$sudo apt-get install quickly python-quickly.widgets

This tutorial also uses a yet to be merged branch of Quickly Widgets. In a few weeks, you can just install quickly-widgets, but for now, you'll need to get the branch:

$bzr branch lp:~rick-rickspencer3/quidgets/natty-trunk

Note that these are alpha versions, so there may be bugs.

Caution About Copy and Pasting Code
In Python, white space is very significant, especially in terms of indentions. In HTML, white space is not. As a result, Blog postings frequently mangle Python code, no matter how carefully a blogger might format it. So while you're following along, be careful about copying and pasting out of here.

If you're going to copy and paste, you might want to use the code for the tutorial project in launchpad, from this:
Link to Code File in the Launchpad Project

You can also look at the tutorial in text format this:
Link to this tutorial in text for in Launchpad

Creating the Application
You get started by creating a Quickly project using the ubuntu-application template. Run this command in the terminal:
$quickly create ubuntu-application simple-player

This will create and run your application for you.

Notice that the application knows it is called Simple Player, and the menus and everything work.

To edit and run the application, you need to use the terminal from within the simple-player directory that was created. So, change into that directory for running commands:

$cd simple-player

Edit the User Interface
We'll start by the User Interface with the Glade UI editor. We'll be adding a lot of things to the UI from code, so we can't build it all in Glade. But we can do some key things. We can:

Layout the HPaned that separates the list from the media playing area
Set up the toolbar

Get Started
To run Glade with a Quickly project, you have to use this command from within your project's directory:
$quickly design

If you just try to run Glade directly, it won't work with your project.
Now that Glade is open, we'll start out by deleting some of the stuff that Quickly put in there automatically. Delete items by selecting them and hitting the delete key. So, delete:

label1
image1
label2

This will leave you with a nice blank slate for your app:
Now, we want to make sure the window doesn't open too small when the app runs. Scroll to the top of the TreeView in the upper right of Glade, and select simple_player_window. Then in the editor below, click the common tab, and set the Width Request and Height Request.
There's also a small bug in the quickly-application template, but it's easy to fix. Select statusbar1, then on the packing tab, set "Pack type" to "End".

Save your changes or they won't show up when you try running the app! Then see how your changes worked by using the command:
$quickly run

A nice blank window, ready for us to party on!
Adding in Your Widgets
The main part of the user interface is going to have an area that divides between the list of media and the media when it is playing. There is widget for that called HPaned (Horizontal Paned). Find HPaned on the toolbox on the left, and click on it to active paint mode. Then click into the second open space in the main part of the window. This will put the HPaned in the window for you.

Make sure the HPaned starts out with an appropriate division of space. Do this by going to the General tab, and setting an appropriate number of pixels in Position property.
The user should be able to scroll through the list, so click on ScrolledWindow in the toolbar, and then click in the left hand part of the HPaned to place it in there.

Now add a toolbar. Find the toolbar icon in the toolbox, click on it and click in the top space open space. This will cause that space to collapse, because the toolbar is empty by default.
To add the open button click the edit button (looks like pencil) in Glade's toolbar. This will bring up the toolbar editing dialog. Switch to the Hierarchy tab, and click "Add". This will add a default toolbar button.

To turn this default button into an open button, first, rename the button to openbutton (this will make it easier to refer to in code). Then under Edit Image set Stock Id to "Open". That's all you need to do to make an open button in Glade.

Due to a bug in the current version of Glade, you might need to rename your tool bar button again. When you close the editor, look in the treeview. If the button is still called "toolbutton1", then select it, and use the general tab to change the Name property to "openbutton". Then save again.

Now if you use $quickly run again, you'll see that your toolbar button is there.

Coding the Media List
Making the Open Button Work
The open button will have an important job. It will respond to a click from the user, offer a directory chooser, and then build a list of media in that directory. So, it's time write some code.

You can use:
$quickly edit &

This will open your code Gedit, the default text and code editor for Ubuntu.

Switch to the file called "simple-player". This is the file for your main window, and the file that gets run when users run your app from Ubuntu.
First let's make sure that the open button is hooked up to the code. Create a function to handle the signal that looks like this (and don't forget about proper space indenting in Python!):


   def openbutton_clicked_event(self, widget, data=None):
       print "OPEN"

Put this function under "finish_initializing", but above "on_preferences_changed". Save the code, run the app, and when you click the button, you should see "OPEN" printed out to the terminal.

How did this work? Your Quickly project used the auto-signals feature to connect the button to the event. To use auto-sginals, simple follow this pattern when you create a signal handlder:


def widgetname_eventname_event(self, widget, data=None):

Sometimes a signal handler will require a different signature, but (self, widget, data=None) is the most common.

Getting the Directory from the User
We'll use a convenience function built into Quickly Widgets to get the directory info from the user. First, go to the import section of the simple-player file, and around line 11 add an import statement:


from quickly import prompts

Then add to your openbutton_clicked_event function the code to prompt the user so it looks like this:


def openbutton_clicked_event(self, widget, data=None):
#let the user choose a path with the directory chooser
response, path = prompts.choose_directory()

#make certain the user said ok before working
if response == gtk.RESPONSE_OK:
  #iterate through root directory
  for root, dirs, files in os.walk(path):
      #iterate through each file
      for f in files:
          #make a full path to the file
          print os.path.join(root,f)

Now when you run the app you can select a directory, and it will print a full path to each file encountered. Nice start, but what the function needs to do is build a list of files that are media files and display those to the user.

Defining Media Files
This app will use a simple system of looking at file extensions to determine if files are media files. Start by specifying what file types are supporting. Add this in finish_initializing to create 2 lists of supported media:


self.supported_video_formats = [".ogv",".avi"]
self.supported_audio_formats = [".ogg",".mp3"]

GStreamer supports a lot of media types so ,of course, you can add more supported types, but this is fine to start with.

Now change the openbutton handler to only look for these file types:


def openbutton_clicked_event(self, widget, data=None):
#let the user choose a path with the directory chooser
response, path = prompts.choose_directory()

#make certain the user said ok before working
if response == gtk.RESPONSE_OK:
   #make one list of support formats
   formats = self.supported_video_formats + self.supported_audio_formats
   #iterate through root directory
   for root, dirs, files in os.walk(path):
       #iterate through each file
       for f in files:
           #check if the file is a supported formats
           for format in formats:
               if f.lower().endswith(format):
                   #make a full path to the file
                   print os.path.join(root,f)

This will now only print out files of supported formats.

Build a List of Media Files
Simple Player will create a list of dictionaries. Each dictionary will have all the information that is needed to display and play the file. Simple Player will need to know the File name to display to the user, a URI to the file so that the file can be played, and the type of media. So, we'll create a list and add a dictionary to each support type to it.


def openbutton_clicked_event(self, widget, data=None):
#let the user choose a path with the directory chooser
response, path = prompts.choose_directory()

#make certain the user said ok before working
if response == gtk.RESPONSE_OK:
   #make one list of support formats
   formats = self.supported_video_formats + self.supported_audio_formats

   #make a list of the supported media files
   media_files = []
   #iterate through root directory
   for root, dirs, files in os.walk(path):
       #iterate through each file
       for f in files:
           #check if the file is a supported formats
           for format in formats:
               if f.lower().endswith(format):
                   #create a URI in a format gstreamer likes
                   file_uri = "file://" + os.path.join(root,f)

                   #add a dictionary to the list of media files
                   media_files.append({"File":f,"uri":file_uri, "format":format})
   print media_files

Display the List to the User
A DictionaryGrid is the easiest way to display the files, and to allow the user to click on them. So import DicationaryGrid at line 12, like this:


from quickly.widgets.dictionary_grid import DictionaryGrid

Starting in Natty, every window has a ui collection. You can use it to access all of the widgets that you have defined in Glade by their names. So, creating the list of media files, you can remove any old grids in the scrolled window like this:


   for c in self.ui.scrolledwindow1.get_children():
       self.ui.scrolledwindow1.remove(c)

Then create a new DictionaryGrid. We only want one column, to the view the files, so we'll set up the grid like this:


   #create the grid with list of dictionaries
   #only show the File column
   media_grid = DictionaryGrid(media_files, keys=["File"])

   #show the grid, and add it to the scrolled window
   media_grid.show()
   self.ui.scrolledwindow1.add(media_grid)

So now the whole function looks like this:


def openbutton_clicked_event(self, widget, data=None):
#let the user choose a path with the directory chooser
response, path = prompts.choose_directory()

#make certain the user said ok before working
if response == gtk.RESPONSE_OK:
   #make one list of support formats
   formats = self.supported_video_formats + self.supported_audio_formats

   #make a list of the supported media files
   media_files = []
   #iterate through root directory
   for root, dirs, files in os.walk(path):
       #iterate through each file
       for f in files:
           #check if the file is a supported formats
           for format in formats:
               if f.lower().endswith(format):
                   #create a URI in a format gstreamer likes
                   file_uri = "file://" + os.path.join(root,f)

                   #add a dictionary to the list of media files
                   media_files.append({"File":f,"uri":file_uri, "format":format})

   #remove any children in scrolled window
   for c in self.ui.scrolledwindow1.get_children():
       self.ui.scrolledwindow1.remove(c)

   #create the grid with list of dictionaries
   #only show the File column
   media_grid = DictionaryGrid(media_files, keys=["File"])

   #show the grid, and add it to the scrolled window
   media_grid.show()
   self.ui.scrolledwindow1.add(media_grid)

Now the list is displayed when the user picks the directory.

Playing the Media
Adding the MediaPlayer
So now that we have the list of media for the users to interact with, we will use MediaPlayerBox to actually play the media. MediaPlayerBox is not yet integrated into Glade, so we'll have to write code to add it in. As usually, start with an import:


from quickly.widgets.media_player_box import MediaPlayerBox

Then, we'll create and show a MediaPlayerBox in the finish_initializing function. By default, a MediaPlayerBox does not show it's own controls, so pass in True to set the "controls_visible" property to True. You can also do things like this:


player.controls_visible = False
player.controls_visible = True

to control the visibility of the controls.

Since we'll be accessing it a lot, we'll create as a member variable in the SimplePlayerWindow class. Then to put it in the right hand part of the HPaned, we use the add2 function (add1() would put it in the left hand part).


self.player = MediaPlayerBox(True)
self.player.show()
self.ui.hpaned1.add2(self.player)

Connecting to the DictionaryGrid Signals
Now we need to connect the dictionary_grid's "selection_changed" event, and play the selected media. So back in the openbutton_clicked_event function, after creating the grid, we can connect to this signal. We'll play a file when selection changes, so we'll connect to a play_file function (which we haven't created yet). This goes at the end of the function:


   #hook up to the selection_changed event
   media_grid.connect("selection_changed", self.play_file)

Now create that play_file function, it should look like this:


   def play_file(self, widget, selected_rows, data=None):
       print selected_rows[-1]["uri"]

Notice that the signature for the function is a little different than normal. When the DictionaryGrid fires this signal, it also passes the dictionaries for each row that is now selected. This greatly simplifies things, as typcially you just want to work with the data in the selected rows. If you need to know more about the DictionaryGrid, it passes itself in as the "widget" argument, so you can just work with that.

All the function does now is get the last item in the list of selected rows (in Python, you can use -1 as an index to get the last item in a list. Then it prints the URI for that row that we stored in the dictionary back in openbutton_clicked_event.
Setting the URI and calling play()
Now that we have the URI to play, it's a simple matter to play it. We simply set the uri property of our MediaPlayerBox, and then tell it to stop playing any file it may be playing, and then to play the selected file:


def play_file(self, widget, selected_rows, data=None):
 self.player.stop()
 self.player.uri = selected_rows[-1]["uri"]
 self.player.play()

Now users can click on Videos and movies, and they will play. Since we decided to show the MediaPlayerBox's controls when we created it, we don't need to do any work to enable pausing or stopping. However, if you were creating your own controls, you could use player.pause() and player.stop() to use those functions.

Connecting to the "end-of-file" Signal
When a media files ends, users will expect the next file played automatically. It's easy to find out when a media file ends using the MediaPlayerBox's "end-of-file" signal. Back in finish_initializing, after creating the MediaPlayerBox, connect to that signal:


self.player.connect("end-of-file",self.play_next_file)

Changing the Selection of the DictionaryGrid
Create the play_next_file function in order to respond when a file is done playing:


   def play_next_file(self, widget, file_uri):
       print file_uri

The file_uri argument is the URI for the file that just finished, so that's not much use in this case. There is no particularly easy way to select the next row in a DictionaryGrid. But every widget in Quickly Widgets is a subclass of another PyGtk class. Therefore, you always have access to full power of PyGtk. A DictionaryGrid is a TreeView, so you can write code to select the next item in a TreeView:


def play_next_file(self, widget, file_uri):
#get a reference to the current grid
grid = self.ui.scrolledwindow1.get_children()[0]

#get a gtk selection object from that grid
selection = grid.get_selection()

#get the selected row, and just return if none are selected
model, rows = selection.get_selected_rows()
if len(rows) == 0:
   return

#calculate the next row to be selected by finding
#the last selected row in the list of selected rows
#and incrementing by 1
next_to_select = rows[-1][0] + 1

#if this is not the last row in the last
#unselect all rows, select the next row, and call the
#play_file handle, passing in the now selected row
if next_to_select < len(grid.rows):
   selection.unselect_all()
   selection.select_path(next_to_select)
   self.play_file(self,grid.selected_rows)

Making an Audio File Screen
Notice that when playing a song instead of a video, the media player is blank, or a black box, depending on whether a video has been player before.
It would be nicer to show the user some kind of visualization when a song is playing. The easiest thing to do would be to create a gtk.Image object, and swap it when for the MediaPlayerBox when an audio file is playing. However, there are more powerful tools at our disposal that we can use to create a bit richer of a user experience.

This section will use a GooCanvas to show you how to compose images and text together. A GooCanvas is a very flexible surface on which you can compose and animate all kinds of 2D experiences for users. This tutorial will just scratch the surface, by combining 2 images and some text together. We'll show the Ubuntu logo image that is already built into your project, but a musical note on top of that for some style, and then put the current song playing as some text.

Create a Goo Canvas
Naturally, you need to import the goocanvas module:


import goocanvas

Then, in the finish_initializing function, create and show a goocanvas.Canvas:


self.goocanvas = goocanvas.Canvas()
self.goocanvas.show()

The goocanvas will only be added to the window when there is an audio playing file, so don't pack it into the window yet. But let's an image to the goocanvas so we can make sure that we have the system working.

Add Pictures to the GooCanvas
Add an image to the goocanvas by creating a goocanvas.Image object. First, we'll need to create a gtk.Pixbuf object. You can think of a gtk.Pixbuf as an image stored in memory, but it has a lot of functions to make them easier to work with than just having raw image data. We want to use the file called "background.png". In a quickly project, media files like images and sounds should always go into the data/media directory so that when users install your programs, the files will go to the correct place. There is a helper function called get_media_file built inot quickly projects to get a URI for any media file in the media directory. You should always use this function to get a path to media files, as this function will work even when your program is installed and the files are put into different places on the user's computer. get_media_file returns a URI, but a pixbuf expects a normal path. It's easy to fix this stripping out the beginning of the URI. Since it was created for you, can could also change the way get_media_player works, or create a new function, but this works too:


logo_file = helpers.get_media_file("background.png")
logo_file = logo_file.replace("file:///","")
logo_pb = gtk.gdk.pixbuf_new_from_file(logo_file)

You don't actually pass the goocanvas.Image into the goocanvas.Canvas, rather you tell the goocanvas.Image that it's parent is the rootA_items of the goocanvas. You can also set other properties when you create it, such as the x and y coordinates, and of course the pixbuf to use:


root_item=self.goocanvas.get_root_item()
goocanvas.Image(parent=root_item, pixbuf=logo_pb,x=20,y=20)

Show the GooCanvas When a Song is Playing
So now we want to take the MediaPlayerBox out of the HPaned when a song is playing and show the goocanvas, and also visa versa. We can easily extract the format of the file because we included it in the dictionary for the row when we created the DictionaryGrid in the openbutton_clicked_event function:


format = selected_rows[0]["format"]

We can also get a reference to the visual that is currently in use:


current_visual = self.ui.hpaned1.get_child2()

Knowing those two things, we can then figure out whether to put in the goocanvas.Canvas or the MediaPlayerBox. So the whole function will look like this:


def play_file(self, widget, selected_rows, data=None):
self.player.stop()
format = selected_rows[0]["format"]
current_visual = self.ui.hpaned1.get_child2()

#check if the format of the current file is audio
if format in self.supported_audio_formats:
   #if it is audio, see if the current visual is
   #the goocanvas, if it's not, do a swapperoo
   if current_visual is not self.goocanvas:
       self.ui.hpaned1.remove(current_visual)
       self.ui.hpaned1.add2(self.goocanvas)
else:
   #do the same thing for the player
   if current_visual is not self.player:
       self.ui.hpaned1.remove(current_visual)
       self.ui.hpaned1.add2(self.player)

#go ahead and play the file
self.player.uri = selected_rows[-1]["uri"]
self.player.play()

Add another Image to Canvas
We can add the note image to the goocanvas.Canvas in the same way we added the background image. However, this time we'll play with the scale a bit:


note_file = helpers.get_media_file("note.png")
note_file = note_file.replace("file:///","")
note_pb = gtk.gdk.pixbuf_new_from_file(note_file)
note = goocanvas.Image(parent=root_item, pixbuf=note_pb,x=175,y=255)
note.scale(.75,.6)

Remember for this to work, you have to put a note.png file in the data/media directory for your project. If your image is a different size, you'll need to tweak the x, y, and scale as well.

(BTW, thanks to Daniel Fore for making the artwork used here. If you haven't had the pleasure of working Dan, he is a really great guy, as well as a talented artist and designer. He's also the leader of the #elementary project.)

A goocanvas.Image is a goocanvas.Item. There are different kinds of Items and many of interesting visual things you can do with them. There are items like shapes and paths. You can change things like their scale, rotation, and opacity. You can even animate them!
Add Text to the goocanvas.Canvas
One kind of goocanvas.Item is goocanvas.Text. You create it like a goocanvas.Image. We won't use any text when we create it, because that will be set later when we are playing a song. Since the goocanvas.Text will be accessed from the play_file function, it should be a member variable for the window. So after adding the note image in the finish_initializing function, you can go ahead and add the text.


self.song_text = goocanvas.Text(parent=root_item,text="", x=5, y=5)
self.song_text.set_property("font","Ubuntu")
self.song_text.scale(2,2)

Update the Text
The text property of the goocanvas.Text object should then be set when an audio file is played. Add a line of code to do this in the play_file function, after you've determined the file is an audio file:


   self.song_text.set_property("text",selected_rows[0]["File"])

Now when an audio file is playing the title shows.

Moving the Media Player Controls
You've probably noticed a pretty bad bug, when an audio file is playing the user can't access the controls for the media player. Even if that were not the case, are 2 toolbars, one for the controls, and one that only has the openbutton. Also, the controls are shifted over because of the DictionaryGrid, so the time labels are not visible by default.

Fortunately, PyGtk let's you move widgets around really easily. So, it's possible to write a little code that:

Creates the openbutton in code instead of glade
Takes the toolbar for the MediaPlayer controls out of the MediaPlayer
Inserts the openbutton into the controls exactly where we want it
Adds the controls back into the window

To start, go back to Glade, and delete the toolbar you added before. Replace it with an HBox. When prompted, set Number of Items to 1. It should be named hbox1 by default. After adding the HBox choose the packing tab, and set Expand to "No". Otherwise, the HBox will take up all the room it can, making the toolbar huge when you add it back in.
Then, back in finish_initializing, after creating the MediaPlayerBox, remove the controls:


self.player = MediaPlayerBox(True)
self.player.remove(self.player.controls)

Then, create a new openbutton:


open_button = gtk.ToolButton()

We still want the open button to be a stock button. For gtk.ToolButtons, use the set_stock_id function to set the right stock item.


open_button.set_stock_id(gtk.STOCK_OPEN)

Then show the button, and connect it to the existing signal handler.


open_button.show()
open_button.connect("clicked",self.openbutton_clicked_event)

The MediaPlayerBox's controls are a gtk.Toolbar object. So, insert the open_button into the controls using the gtk.Toobar classes insert command. Pass in a zero to tell the gtk.Toolbar to put open_button first. Then you can show the controls, and pack them into the window:


self.player.controls.insert(open_button, 0)
self.ui.hbox1.pack_start(self.player.controls, True)

Now users can use the controls even when audio is playing!
Conclusion
This tutorial demonstrated how to use Quickly, Quickly Widgets, and PyGtk to build a functional and dynamic media player UI, and how to use a goocanvas.Canvas to add interesting visual effects to your program.

The next tutorial will show 2 different ways of implementing play lists, using text files, using pickling, or using desktopcouch for storing files.

API Reference
PyGtk

Quickly Widgets
Reference documentation for Quickly Widgets isn't currently hosted anywhere. However, the code is thoroughly documented, so until the docs are hosted, you can use pydocs to view them locally. To do this, first start pydocs on a local port, such as:
$pydocs -p 1234

Then you can browse the pydocs by opening your web browser and going to http:localhost:1234. Search for quickly, then browse the widgets and prompts libraries.

Since MediaPlayerBox is not installed yet, you can look at the doc comments in the code for the modules in natty-branch/quickly/widgets/media_player_box.py.
GooCanvas

Python GooCanvas Reference

GStreamer
MediaPlayerBox uses a GStreamer playbin to deliver media playing functionality. GStreamer si super powerful, so if you want to do more with it, you can read the docs.

Playbin Documentation (you can use self.player.playbin to get a reference to the playbin).
Python GStreamer Reference

New Quidget: MediaPlayerBox adds video to your app in a few lines

2011-01-04T20:36:00.000-08:00

I've created a new quickly-widget to make it dead simple to add a video or sound file to a Quickly application. All you need to do is create a MediaPlayerBox, add it to your app, set the uri property to tell it what file to play, and call "play()". 5 lines to playing a video:

        self.player = MediaPlayerBox(True)
   self.player.show()
   self.ui.vbox1.pack_start(self.player)
   self.player.uri = file_to_play
   self.player.play()

By passing in True when I created the MediaPlayerBox, that told it to display controls. You can also control whether controls are displayed by setting the controls_visible property:

        self.player.controls_visible = True

It's got other functions that you would expect:

        self.player.pause()
      self.player.stop()

And other useful properties too. For example, you can get the duration of the current media file, and you can get and set the current position. So you could seek to halfway through the media file like this:

        dur = self.player.duration
      self.player.position = dur/2

MediaPlayerBox is really just a thin wrapper around the gstreamer's playbin, so you still have all the power of gstreamer if you end up needing to go there. You can just use the playbin property and go to town if it comes to it.

But MediaPlayerBox is focused on simplicity, just getting a video or song playing n your app esasily.

MediaPlayerBox is currently in a branch, so you can grab it and try it out.

Changing the Opacity of gtk.Pixbuf

2011-01-02T13:33:00.000-08:00

Photobomb has lacked the ability to set the opacity of images the way it could set the opacity of text and scribbles. This was because goocanvas.Image lacked this capability, and I could not figure out how to make a pixbuf transparent. I looked through all the pygtk docs, all the PIL docs, and all the cairo docs. I tried a bunch of things, and just couldn't make it happen.

I finally ended up with a solution that works (but is a tad slow on larger images). To start, you need a transparent PNG file loaded into a pixbuf. I do this by storing a transparent PNG image on disk. If I was slicker, I could probably create one out of thin air using the various pixbuf functionalities. You also need a pixbuf that you want to make transparent.

Anyway, given a transparent pixbuf, this function will set the transparency.

    def change_opacity(self, opacity):
     """
     change_opacity - changes the opacity of pixbuf by combining
     the pixbuf with a pixbuf derived from a transparent .png

     arguments:
     opacity - the degree of desired opacity (between 0 and 255)

     returns: a pixbuf with the transperancy

     """

     trans = self.transparent_img
     width = self.pixbuf.get_width()
     height = self.pixbuf.get_height()
     trans = trans.scale_simple(width,height,gtk.gdk.INTERP_NEAREST)
     self.pixbuf.composite(trans, 0, 0, width, height, 0, 0, 1, 1, gtk.gdk.INTERP_NEAREST, opacity)
     return trans

I'm sharing it here in case someone else runs into this and can either use my solution, or offer a better one.

This is Photobomb

2010-12-29T13:06:00.000-08:00

The last couple of days I made some good solid progress on Photobomb:

Refactored items on the goocanvas into PhotobombItems to make changes easier, and code easier to maintain.
Fixed the Gwibber tab to pull images from the Gwibber sqlite database.
Removed Python threads from throughout the application while keeping the UI from freezing during long running actions (thanks gobject.idle_add!).
Added a "download-error" event to UrlFetchProgressBox and handled download errors better.

There are still a few things I want to get to, but I am making steady progress.

Anyway, I was talking to some folks about Photobomb, and they kept referring to it as an "Image Editor". To me, and image editor is used to open an image, modify the image, and save the image. Photobomb is decidedly not that! Photobomb integrates with your social desktop, allowing you to mashup images from your devices, the web, your feeds, and your web cam. Photobomb also lets you share those mashups into your feeds. So, it's a social app.

Here's a 5 minute video I made to try to help explain Photobomb ...

New Personal Goal: Photobomb for Natty

2010-12-27T09:58:00.000-08:00

I'm on holiday for the next week, yeah! I've started filling some of my free time by resurrecting Photobomb (again). There have been some technical improvements to the APIs I've been using, and also, I've learned some ways to do a few things better. I'm hoping that by spending a few hours a day, I can pretty much complete Photobomb by the end of this week, and then work on getting it into Universe for Natty.

Things I accomplished so far:

I fixed the WebcamBox quidget so that it doesn't hang if you try to tell it play when it hasn't been realized. The effect of this is that I can put the webcam tab on the end of the tabs, much nicer.
Then I went on to complete how the UI is organized. I want Photobomb to work really well on netbooks running Unity in Natty. Since I started Photobomb on Lucid, apps have gotten slightly less horizontal space but more vertical space. I moved the toolbar from the right, and added it as a tab on the left. Even when making the tabs wider, this reclaimed lots of vertical space.
I added delete and duplicate! So now you can delete or duplicate the selected item. I was going to add cut, copy, and paste, but I think delete and duplicate works better for this app.
When I started Photobomb, I simply created GooCanvas items like goocanvas.Imate, goocanvas.Path, and goocanvas.Text. Each of these types of items interact with different parts of the toolbar slightly differently, so there were lots of places in the code where I had to use code like "if type(self.selected_item) == goocanvas.Path:". Whenever I find myself type checking, I know that subclassing is in my future. Also, goocanvas.Items only let you write to their opacity properties, so for the increase and decrease opacity functions, I've been tracking opacity externally, in a dictionary, rather than as a property on the items. Refactoring was clearly in order before I continued to add features, so I created photobomb_item.py, and added PhotobombImage, PhotobombPath, and PhotobombText, then implemented common properties on each. It was only after doing this that it was reasonable code factoring to create the duplicate function. I'm not quite done this part, though.

Here's a quick video showing the new layout and the duplicate function in action:

There's still a lot on my Todo list before I'll consider Photobomb ready for general availability.

Complete the refactoring into PhotobombItems. This will drag me into my first experience with multiple inheritance in Python. I think that it will be simple for this particular application. Every PhotobombItem will derive from PhotobombItem to pick up common properties and functions, but also from the appropriate goocanvas.Item (Image, Path, or Text for now). I'll probably do this one next, as I will use that to fix the opacity controls.
I want to move common editing commands into their own toolbar which is always available. The new found vertical space from Unity provides this luxury.
I use Python threading code in directory tab, and also the web tab. Python Thread code is notoriously difficult, and indeed, there are a number of hangs or situations where Photobomb doesn't quite quit all the way due to threads running and colliding. I will replace threads with a combination of UrlFetchProgressbox, and gobject.timeout_add. In fact, I am considering creating quidgets to handle common asynchronous activities that I have mistakenly used Threads for in the past. Depending on how it goes, I may create DirectoryScannerProgressBox, DictionaryScannerProgressBox, XMLScannerProgressBox, and JSONScannerProgressBox. I would intend for these to work in very similar ways, but make it super simple to perform long running tasks without blocking the UI or resorting the Threads.
I will change the Gwibber page to use libgwibber, and also the poster button to use libgwibber.
I'll make the webcam tab present the webcam image on a button instead of using a separate button. This will be more consistent with the other tabs.
I want to add an undo/redo stack (which should be lots easier after I'm done with the PhotobombItem refactoring).
For the toolbar tab, I didn't really do any code refactoring, I just grabbed the table of buttons, removed them from the main window, and packed them into the tab. I should really do a proper job of making the toolbox into a proper widget that rips signals. In this way, the UI will become much easier to modify in the future, and generally the photobomb code will become reusable.
Since Photobomb has no preferences, I may as well remove the preferences code. All it does it start up desktopcouch and then not use it.
Finally, the global menu means I can add in a menu bar without sacrificing any vertical space. This will have a few benefits. It will mean users can access the toolbar functions without changing to the toolbar tab, it will be way easier for me to add key commands for the functions, and I can add certain functions only to the menu. For example, the export and microblog commands may be better hanging out on the file menu, rather than be part of the toolbar.

If you want to play with latest Photobomb, get it from trunk.

Hot New Quickly Template Features

2010-12-10T06:24:00.000-08:00

The Quickly Ubuntu Application template for Natty has cool new features already. Here's a couple of videos to highlight these changes.

Here are some changes contributed by Mike Terry. What he's done is:

Reduce the code in the generate boiler plate down to about 65 lines. This makes it a lot easier to hack on and maintain.
Make it so that you don't have to use the builder to access widgets that you've added in glade. Instead of "self.builder.get_object("entry1").set_text("hi"), you can just do self.ui.entry.set_text("hi"). In other words, Quickly just knows.
The third thing demoed here is the new auto signals feature. Instead of picking a signal handler name, and defining it in Glade and in your code, if you follow some simple conventions when you name your function, Quickly will just know it's a signal handler, and it will work.

In this second video, you can see the much much much improved preferences system contributed by Tony Byrne. By following some naming conventions, and adding 2 lines of code, you can persist and access user settings with ease.

Alpha 1 Unity Checkpoint

2010-12-10T04:01:00.001-08:00

While attending a sprint this week, I've gone ahead and updated my Dell mini 10v to Ubuntu 11.04 Alpha 1, and also took some updates on Tuesday.

I have to say, I am finding Unity to be running really really well on this computer. I can use the spider diagram to provide a more structured description to what I think is going well, and also, how far we still have to go before we have a shippable product.

Up

Launcher Appeal (6-7): The Launcher looks a lot nice n autohide mode.
Launcher Functionality (3-6): Significantly improved now that the launcher includes autohide and quicklists allow me to pin and unpin apps to the launcher. It's still too hard to use with workspaces, but code for that landed this week, so next week, I hope to pop this up to 7! Jason is absolutely rocking the Launcher functionality.
Application Window Management (5-6): Little tick marks in the launcher items show how many windows are open. Meta-W shows all the windows in a workspace. I think they should add an item for Meta-W to the launcher. That would make it really easy and discoverable to find your apps.

Down

Indicator Quality (6-4): Starting this week, there has been these times when the indicators stop responding to mouse clicks, or become don't activate for a really long time.

Unchanged

Launcher Performance (8): The launcher is even faster on my Dell mini 10v than on my desktop at home. I assume this is because I use a computer with a shared memory graphics chip (i965) for my desktop, but with a large screen. So the combination laptop graphics chip with desktop screen is not ideal. However, it's still plenty fast and snappy on my desktop. I'm tempted to pop this up to 9, but I want to see how it's working for folks with proprietary drivers first.
Application Launch Time (8): Nothing seems to have changed here.
Everything dash related. I could pop up Find and Launch apps since they tied the Ubuntu button to the Applications directory as a temporary measure until the dash is ready. However, I think I'll just wait until it's their real deal.
Indicator functionality hasn't changed, expect I hear there is code in trunk to bring back keyboard access and navigation! This has been a real productivity killer for me, so I can't wait until next week.
Global Menu Integration. However, I hear that there is a team working on Mozilla/Unity integration. I'll also be looking forward to when they can turn the shotwell menus back to the global menus.

Log those Unity Crash Reports!

2010-12-02T10:13:00.000-08:00

Natty Alpha 1 is baked and available!

This alpha is exciting to me because the Unity Launcher is already pretty usable. I'm using it daily, and am already addicted. The move to the new compiz has really really sped things up. Of course, I can't recommend to an average user that they rely daily on alpha software. This is fresh code, and it stresses more fresh code in the graphics stack. This means crashers.

However, you don't have to be a hacker to really help get Unity into shape stating right now. A great way to help Ubuntu and the Unity team right now is to get them as many crash reports as we can, so they can these issues fixed asap and move on to adding those features we are so much waiting for.

Way 1: Tonight, before the packages get updated, run Ubuntu Alpha 1 from a live session when it become available. If there are crashers, Apport, the crash report system, will kick in and help you log crash reports easily. If you can't get to it right away, no problems, but you'll want to use the current daily build to make sure you are testing up to date packages.

Way 2: Install Alpha 1 on a test machine. Enable Apport, and start upload crash reports when there are crashers. It's really easy to do, instructions are on the wiki. If you go this route, you can update daily and help by reporting new crashers as you encounter them.

Unity in Natty Evaluation 1

2010-11-29T15:57:00.000-08:00

Today I am finally finding Natty to be usably stable. So long as I stay away from Open Office, it seems to be running quite fine. So, I updated my maverick spider diagram in an attempt to capture where I think Unity is in the journey to being the Ubuntu desktop.

In this first natty diagram, yellow is the target, blue is maverick, and that orangy color is my subjective assessment of Unity as it is today. You can review the criteria that I chose from assessment in a previous post.

Note that there is a large portion of the diagram missing. Everything related to the Dash is zero, because none of that is implement yet. Here is a summary of why I picked these values for the other items:

Natty > Maverick

Launcher Performance (3 to 8): The natty launcher feels snappy when you drag the items, and when the launcher overflow and "folds" items, the unfolding and access to those items is also totally responsive. This is a big improvement!
Application Launch Time(4 to 8): I was told a few times that apps didn't start any slower under Mutter. However, they sure always seemed to. Well, they seem to start nice and fast now, so I'm saying that application launch time is nice and fast.
File Management (3 to 6): The launcher features a nice big Nautilus item at the top of the launcher. This makes access to typical file management tasks much easier accomplish, because you can find them. Since there is no dash, there is no integration with dash and that search yet, so hopefully this particular area will improve.

Maverick > Natty

Launcher Quality (5 to 3): I'm probably being really unfair here, but I'm blaming all the crashiness, especially when I'm using OOo on the Launcher. It's probably really Compiz itself, but subjectively, it feels like the launcher is the new thing, so I'm blaming that.
Launcher Functionality (6 to 3): Without quick lists, this took an big hit. You can really only launch and switch now. Adding back in the quick lists, and then getting a hiding launcher, and we'll be in business.
Application Window Management (5 to 4): Not much has really changed here, except that without the quick lists there is no where to click on different windows from the same app. I use Alt-Tab, so this doesn't much impact me, personally. Minimized windows still disappear with no way to get them back.
Application Window Management:

Natty == Maverick

Launcher Appeal (6): The launcher is still a bit "blocky". I do like how the items look, and the attention getting animations as well. I expect to see lots of improvements to the look and feel of the launcher, especially when they start adding in some of the animations and transitions.
Global Menu Integration (5): I don't see any changes to this part. Firefox still has it's own menu, for example.
Indicator Appeal (7): I don't see any changes here, either. I expect to see some slightly tweaked icons and maybe and improvements to the look of the indicators themselves.
Indicator Performance (8): No changes here.
Indicator Functionality (6): No changes today, but I hear that the new indicator for the network manager was supposed to land today. That will mean that all the default functionality will be managed by indicators, so no more panel applets by default.

I also just noticed that key nav between the indicators isn't working! grrrr. It's also not working for the global menu. Well, Accessibility is already rated zero, so there's really no way to change my ratings based on that, unless I added it to "Indicator Functionality". I'll see how annoying it is to me, and maybe change it then.

Ubuntu is not moving to a rolling release

2010-11-24T09:50:00.000-08:00

So, I just got asked to provide a statement about whether Ubuntu is moving to a rolling release. The statement I provided was:

"Ubuntu is not changing to a rolling release. We are confident that our customers, partners, and the FLOSS ecosystem are well served by our current release cadence. What the article was probably referring to was the possibility of making it easier for developers to use cutting edge versions of certain software packages on Ubuntu.This is a wide-ranging project that we will continue to pursue through our normal planning processes."

The reason that I was asked to comment on this was that an article appeared this morning that built off of some comments that Mark made regarding daily builds. The article went on to make some reasonable conjecture about possible implications. Links to this article were then labeled things like "Ubuntu Moves to Rolling Releases!"

I do like the idea of making it easier for developer and enthusiasts to use daily builds of software that they really care about, and maybe even have them discover this capability through the software center. Currently you have to find PPAs or maybe activate backports to do this. But having a stable release with a six month cadence plus the option to stay cutting edge on certain packags (at your own risk) is not really a rolling release.

3 Weeks In

2010-11-19T13:56:00.000-08:00

I was about half of last week, and this Monday as well. So I didn't do a week 2 update. Again,, please note that these are things that are happening that I found interesting or important, or was otherwise involved in. This is not the status of work that I personally did. Here's my perspective on week 3 ...

Unity
This Week

Unity landed in Natty (today actually).
I installed Unity and turned it on in the Compiz settings. I was able to play a bit with the launcher, and it was very snappy, and it launched apps. Places is still not working. Compiz in general seems quite snappy.
Unfortunately running Unity caused so much crashing, that I was unable to evaluate it for a spider diagram again.
A decision was taken to focus Unity on for Natty, and not work on a Maverick PPA. Based on my experience with Unity today, this was a sane decision in my estimation.
I checked in with Luke and Gary regarding Unity accessibility. Luke is still working on getting his head around gobjects and such.

Next Week

Hopefully enough stability in Unity that we can really evaluate it.
Luke to start with some accessibility prototypes.

Testing
This Week

The QA team has started putting automated integration tests into place. These tests will try to catch bugs in the way applications work within Unity very quickly and frequently.
We started planning a sprint, where a few Canonical folks will get together for the first week of December and focus on tests for kernel SRU validation, as well as for desktop integration.

Next Week

More tests written and running.
Better definition for sprint goals.

Contributors
This Week

Finalized plans for "Patch Pilot" Program. Informed Canonical Engineers about the new process and schedule.

Next Week

Start of Patch Piloting schedule.

Software Center
This Week

Plans for New Apps in Maverick were finalized. Will be installed in /opt/extras.ubuntu.com. Python apps will lack per-compiled byte code if installed in this way for Maverick, but there should be a better solution in Natty.
didrocks landed changes in quickly to support installing to /opt in Natty.
mterry landed changes to the Quickly template to make it easier to attach to events (no more defining signal handler in Glade).
I'm not sure about the status of ratings and reviews. Since it's mvo driving, I assume all is well.

Next Week

Misc.
This Week

Schedule-wise, there is one week until Feature definition freeze as of yesterday. So this week we asked all teams to have work items identified by eod yesterday so that we could finalize plans by the Feature Definition Freeze. You can see all the blueprints for natty. I summarized how some of the Essential and High importance blueprints will effect the Editions as well. Of course there will be lots of Medium and Low blueprints that have a lot of impact too!
Release meetings started again, with new format and agenda thanks to skaet.

Next Week

Next Thursday is Thanks Giving holiday in the US, so I'm expecting about 60% of normal productivity in Ubuntu.
Work items should be identified for Alpha 2, so I will prepare a detailed review and ensure that items are prioritized appropriately heading into the A2 milestone.

1 Week In

2010-11-05T10:36:00.000-07:00

Back from UDS for a week now. Here's a progress update on some of the happenings in Ubuntu that I am tracking. There are, of course, myriad other aspects to the product that I care about, but that I am not following closely. You may notice a strong correspondence between these areas and The 5 Foci.

Of course I am doing almost none of this work personally. When it makes sense I'll credit the specific people and/or teams. Questions and comments welcome, of course. I have no idea if this kind of thing is useful to folks. But I wonder if I can keep up a weekly cadence of updates.

Unity
This week

Dx team is working to get the Compiz based experience ready for testing
Nothing new uploaded this week, so no update to the spider diagram :(

Next Week

I hope to start testing new compiz-based experience and update the spider diagram

Testing
This Week

ara has confirmed that mago will work with apps under unity so it's possible to start writing integration tests
Unity integration testing is blocked this week on looking into the global menu because of a bug in the dumper tool, but it should be unblocked next week
Server team outlined steps for packaging Hudson

Next Week

Switch Unity Integration testing on Natty
Start teseting the global menu on Unity (this is important because there are lots of bugs their in Maverick)
Get more tests in place and running daily
Progress on packaging and deploying Hudson

Contributors
This Week

Created documentation for Path Pilots (a tweak to our system for responding to contributors)
Straw man schedule for Ubuntu Engineering Engineers set up (these are engineers paid by Canonical to work on Ubuntu)

Next Week

Share Patch Piloting schedule with Ubuntu Engineering Engineers, let them change it around to suit self
Ensure documentation works for Patch Pilots
Pick a date to start with the tweaked system

Software Center
This Week

I followed up on UDS session regarding using /opt for installing new apps on a stable release, and drafted a proposal to the App Review Board that they ask the Tech Board to remove the /opt requirement for Maverick, since there are so few apps we can really review them carefully, and the technology is not there to support /opt properly in Maverick
didrocks broke out work items to ensure that Python build system and Quickly will support installing to /opt in the future

Next Week

Perhaps see some progress by didrocks on making the Python build system work with /opt
First meeting regarding Donations with IS, I requested that the notes from the call be posted to a mailing list or such

Misc
This Week

I confirmed with cjwatson that we can make good progress on "Text Free Boot" in Natty. It won't surprise anyone to know that I had trouble grocking the blueprint :)
Open stack is all packaged up and ready for better integration with Ubuntu Server
Set schedule to get to Feature Definition Freeze with the Ubuntu Engineering Managers (All Blueprints Accepted by 11/11, All Work Items Identified by 11/18)

Next Week

Perhaps create a system for getting feedback on which platforms can boot Text Fee so we can start to assemble the white or blacklist
Some server team members to attend Open Stack Design Summit next week
pitti to reset work item tracker to start burndowns for teams that are ready

This is it!

2010-10-26T07:19:00.000-07:00

This is it! Porting the Unity view to Compiz, comibing the Desktop and UNE editions, and defaulting to UNE for users who can run it. This is is a huge opportunity for the Ubuntu community to make something that can deliver free desktops to millions and millions of people who don't have software freedome today. And also, having a lot of fun with our friends doing something really big along the way.

There is also a big risk here. We *have* to make Natty "really good". But what does "really good" mean? I guess this is inherently subjective, so here's my take on it. "Really good" is multi-faceted, and for me, I think about Unity "goodness" in the following dimensions.

Launcher Performance - Is the launcher snappy and responive?
Launcher Quality - Is the launcher robust and not buggy?
Launcher Appeal - Is the launcher visually beautiful and are the interactions fun?
Launcher Functionality - Does the Launcher have the essential functions that users need?
Find and Launch Apps - Can users easily launcher their apps?
File Management - Can users find their files and operate on them as desiered?
Search - Does the Unity search work well for users?
Dash Appeal - Is Places visually beautiful and are the interactions fun?
Dash Performance - Is places snappy and responsive?
Dash Quality - Is places robust and not buggy?
Indicator Functionality - Do the indicators have the essential functions users need?
Indicator Quality - Are the indicators robust and not buggy?
Indicator Performance - Are the indicators snappy and responsive?
Indicator Appeal - Are the idnicators visually beautiful and are the interactions fun?
Global Menu Integration - Are applications across the desktop working well with the Global Menu?
Application Launch Time - Do applications seem to launch quickly and smoothly?
Application Window Management - Can users position windows, and use desktops as desired?
Accessibility - Is the toolkit accessible to screen readers, is the functionality of the desktop universally available?

So, after thinking about all these different facets, I hit on the idea of represent the current state on the target state in a spider diagram. In the following diagram, the blue shape is the current shape of Unity (in Maverick) and the Red shape is where I think Unity needs to get to in Natty. I made this by grading each facet on scale of 1-10 in an Open Office Spreadsheet. Again, in a subjective manner.

So, clearly, there is a lot of work to do to get Unity "into shape". And, of course, we still need to be awesome maintainers. We need to keep up with upstreams, fix bugs, respond to users, etc... This part of our work has the further complication that the Server Edition is starting to get some more serious usage, so we need to ensure that we're doing the right things for server as well.

So, how do we be great maintainers, while getting Unity into great shape? Well, for the Ubuntu Engineering Team (of which I am the Director), the answer is to focus. I will be asking each team to limit their work items so that they can have plenty of bandwidth open to help with bug finding, bug fixing, enhancing performance, etc... whatever it takes to change the shape of the spider diagram.

Here are the 5 foci for Ubuntu engineering:

Unity - Well, not much more to say what I mean here.
2D experience - Not all users will have hardware to run Unity. For these users, we must ensure that Ubuntu continues to work really really for them, just as well as Maverick works, and just as well as Unity in Natty works.
Software Center - This an important area for us to continue to make innovation and progress in order to meet the needs and expectations of users and software developers. So, this is the one area of actual feature development that is staying on the list of focus areas.
Testing - Ubuntu Engineering needs to become a testing organization. I want to see automated itnegration testing for Unity, and I want to see it starting soon.
Contributions - This is possibly the most important part. We need to step up our responsiveness to existing core contributors and new contributors. We should be implementing fewer features ourselves, but we should be ensuring a really great and personal experience for people who contribute patches, apps, etc... So, Ubuntu Engineers should be signing up for fewer features, but more time for contributors.

$quickly create ubuntu-pygame targets

2010-09-26T17:21:00.000-07:00

I hit a kind of hard part in photobomb, basically, creating copies of objects and applying clippings turns out to be a bit challenging. Sometimes when I'm feeling stymied, I switch to something new for a while to keep the programming fun. Of course, this results in having a few programs, like Photobomb, that are in a perpetual state of being incomplete. However, since I write FOSS software for the fun of it, I figure ... meh ... might well keep it fun.

Anyway, I recalled a really simple and fun game we used to play in college. I decided to build some similar game play, using the Quickly PyGame template. I created this template for Lucid, but it didn't really get any attention from me since then.

Here's some game play video, I mercifully left out the sounds:

The goal is to get points by touching the target, which moves after it is touched. The player controls the green smiley faced guy. By default, the PyGame template assumes that the player will control "the guy" using the keyboard. So, I had to change this by mapping the guy's location to the mouse. The place to update the guy's location is in the main files "controller_tick" function. This function fires each clock tick, and you use it to update the models of all the sprites and such. Checking out the PyGame docs, this turned out to be a simple one-liner:

    g.x, g.y = pygame.mouse.get_pos()

g is the variable name for the instance of the guy, and it's easy to set with the tuple returned from mouse position function. So that was all it took to make the guy follow the mouse (and deleted the code that used the keyboard of course). But then, I wanted to enemies to bounce around and be a bit hard to avoid, by by default, enemies wrap around the screen. Since I wanted all the sprites in the game to bounce off of wall, I edited the base_sprite.py file to change the wrapping to bouncing:

        #make the sprite bounce off of walls
  if self.x + self.rect.width > sw:
      self.x = sw - self.rect.width
      self.velocity_x = -self.velocity_x
  if self.y + self.rect.height > sh:
      self.y = sh - self.rect.height
      self.velocity_y = -self.velocity_y

  if self.x <= 0:           self.x = 0           self.velocity_x = -self.velocity_x       if self.y <= 0:           self.y = 0           self.velocity_y = -self.velocity_y

This code simply changes the direction that the sprite is traveling so it is reflected at the opposite angle that it hit. There's probably a more elegant way of doing it, but this turned out to be readable and reliable for me once I wrote it.

A bit harder was making enemies bounce off of each other. In previous games I wrote, sprites either did not interact, or killed each other. So this part took me quite a few iterations. I also saw that there were quite a few options for how to program the physics. I chose to make items essentially exchange their velocities, but I added just a touch of randomness. The randomness is designed to keep enemies from getting locked into boring patterns, like moving back and forth in a straight line. Here's the code I eventually ended up with to handle guys bouncing off of each other.

    for enemy in enemies:
    e = pygame.sprite.spritecollideany(enemy, enemies)
    if enemy is not e:
        if enemy.velocity_x * e.velocity_x >= 0:
            if enemy.velocity_x >= e.velocity_x:
                faster_x = enemy
                slower_x = e
            else:
                faster_x = e
                slower_x = enemy

            stash = faster_x.velocity_x
            faster_x.velocity_x = slower_x.velocity_x
            slower_x.velocity_x = stash
        else:
            stash = e.velocity_x
            e.velocity_x = enemy.velocity_x
            enemy.velocity_x = stash

        if enemy.velocity_y * e.velocity_y >= 0:
            if enemy.velocity_y >= e.velocity_y:
                faster_y = enemy
                slower_y = e
            else:
                faster_y = e
                slower_y = enemy

            stash = faster_y.velocity_y
            faster_y.velocity_y = slower_y.velocity_y
            slower_y.velocity_y = stash
        else:
            stash = e.velocity_y
            e.velocity_y = enemy.velocity_y
            enemy.velocity_y = stash

        e.velocity_x += random.randint(-5,5)
        e.velocity_y += random.randint(-5,5)

        enemy.velocity_x += random.randint(-5,5)
        enemy.velocity_y += random.randint(-5,5)

Due to horrible variable naming, this code is too hard to read. I should really fix that up. In any case, it is work mostly reliably. The only time it doesn't work is that sprites can get overlapped too much, and they don't travel far enough way to not collide in the next tick, and they look a bit odd weirdly bouncing off of each other.

I added a few game play features, like making the guy a ghost after he gets killed, to give the player a chance to get away and not killed over and over again if the guy is caught in a touch place. I also programmed for the background to update every 20 points.

I used the beloved InkScape to create some new sprites. Of course, I'm a pretty bad programmer, but I'm a worst artist! Any help with graphics would be most welcome :)

I still have some stuff left to do before I consider the game done enough to put in my PPA:

Make and associated some nice sounds.
Make the game increase in difficulty as levels go on. I'll probably increase the number of enemies, make them go faster, and also make the homing missles smarter, laster longer, and maybe faster.
Format the score and levels so they are readable.
Add power ups. I'm thinking ones that make the enemies freeze for a bit, maybe slow them down too. Free lives, and point multipliers of course. I was also thinking that sometimes the power ups could do bad things, like speeding up the enemies and/or changing their velocities unpredictably.
Find a theme and a reasonable name.

If you want to check it out, branch, collaborate, etc... feel free to get the code from launchpad.

Anything New in Quickly Widgets for Maverick?

2010-09-11T15:07:00.000-07:00

Going into Maverick, I had envisioned myself spending a lot of free time on Quickly Widgets throughout the cycle. Sadly, though, due to various factors, I did not make the kind of progress I was hoping to. Then a couple of days ago didrocks pinged me to ask if I was going to update Quickly Widgets for Maverick, because if I was, now is the time. So, today I went through all my changes over the last few months, to make sure tests were passing, and that they were generally working well.

Well, it was a good exercise, because I came to find that I had actually made some decent progress! Here's a quick overview of what is new and improved in Quickly Widgets for Maverick (or will be when it actually gets into Maverick next week). Note that most of the changes were put into place for specific users, so I know that each of these improvements will be useful to at least one person :)

Enhanced DictionaryGrid
In Lucid, when you created a dictionary grid, the keys were used for the titles of the columns. I think this is good, because it's easy and fun. You can get going fast, and a fair amount of the time, this functionality will be more than sufficient. However, sometimes that column title needs to be changed or maybe different than the keys. This was doable, of course, because a DictionaryGrid is just a TreeView, and you can set the titles on a TreeView. You could loop through the columns, and set the titles as desired. Too much code, so I added a helper function. You can create a dictionary of keys to titles, and set them. So an app like PyTask would do this if it wanted different keys and titles:

        titles = {"name":_("Name"),"priority":_("Priority"),
"due":_("Due"),"project":_("Project"),
"complete?":_("Completed")}
self.grid.set_column_titles(titles)

You don't have to do all of the titles, you can just pass in the keys that you want you to change titles for. I also made it a bit easier to access a column. You can just index into the columns by the key. So in the tests, for example, you can see where I used it like this:

        grid.columns["key1_1"].set_title("KEY")

Nice one liner. This is just accessing the gtk.TreeViewColumn, so you can whatever you need to with the column, this just makes it easy to get to the columns you need.

As I previously blogged, there is now a datecolumn with built in editing (thanks to the pygtk faq):

And there is a grid filter to go with it:

So now, any column with a key that ends in "date" will default to be a date column.

DictionaryGrid also has an enriched set of arguments for the cell-edited signal. In addition to the row index and key that were previously reported, it now tells you the new value and also provides the dictionary for the row as well. Makes it easier to decide what to do when a cell is edited without having to probe into the grid.

Enhancemed CouchGrid
The most salient enhancement to CouchGrid, is that it's easy to tell the grid to delete data form desktopcouch now. You do this by passing delete=True to the remove_selected_rows function. So apps like PyTask don't have to do all these crazy contortions to remove data from the underlying store, PyTask just does this:

    def remove_row(self, widget, data=None):
"""Removes the currently selected row from the couchgrid."""

self.grid.remove_selected_rows(delete=True)

I like this because it lets the programmer keep the grid as their mental model of how to interact with the underlying store, and keeping desktopcouch an incidental piece of plumbing.

Enhanced GridFilters
Personally, the ability to apply a filter UI to a grid with just a few lines of code is one of the things about quidgets of which I am the most proud. I still don't know how I managed to pull it off, but I did. I like it because it turns a big chore into something easy and fun. If nothing else, it makes a sweet demo.

So I did make some good progress with this in Maverick. The key thing was that I refactored what a FilterRow contains. The FilterRows were hard coded to use a combo box and TextEntry. This became limiting with data types other than strings. So, I did some open heart surgery on the Filter Code, and after a successful refactoring, can now drop in any set of widgets I would like for a filter row. In addition to a date filter, there's an IntegerFilter now:

New Widgets
Thanks to sil, it's now really trivial to download content from the Internet. Sil wrote the code, and I did a vblog about this a while back. In case you missed that:
This widget works by reusing the common signal handling patterns in PyGtk. From the test app:

    def start_download(self, btn):
prog = UrlFetchProgressBox("http://www.ubuntu.com/desktop/get-ubuntu/download")
prog.connect("downloaded", self.downloaded)
self.vbox.pack_start(prog, expand=False)
prog.show()

def downloaded(self, widget, content):
print "downloaded %s bytes of content" % len(content)

There is also a TextEditor now. This removes all the bookkeeping code that you have to write to keep a TextView, TextBuffer, Markers, etc... all straight.

For example, to tell the TextEditor to highlight a word, just add it to the text editor's list of words to highlight:

        self.editor.add_highlight("some")

Really! That's all you need to highlight the word "some" in a text editor.
It's also got undo and redo built in! So instead of mucking with this yourself, you can hook up an undo command with a one-liner:

        undo_button = gtk.Button("Undo")
   undo_button.connect("clicked",self.editor.undo)

If you haven't tried making an undo, redo stack yourself, trust me, this is much easier.

I recently blogged about the new WebCamBox as well. I won't rehash that here.

House Keeping
Finally, I went through this morning to ensure that all of the quidgets were using gettext properly (so bring on the translations if you got 'em), and I've also been adding and improving tests as I've been along.

Anyway
I guess I should write a nice comprehensive tutorial or similar. But in the meantime, there are lots of videos and such on my blog. So, if you want to write an app for Ubuntu, consider using Quickly and Quickly Widgets, because it's getting more fun and more easy with each release!

About Quickly Widgets
Quickly + Widgets = Quidgets
There is a Launchpad Project for Quickly Widgets
The most up to date changes are in the Quickly Widgets Trunk Branch

Quidgets < 3 Gstreamer, and the Return of Photobomb

2010-09-03T16:39:00.000-07:00

I'm finally settling back into the groove of some of my side projects. I guess I'm handling the new position a bit better as time goes on, and feel that I can spend some free time working on somethings that I want to do, not just things that I feel that I should do.

So, these side projects I do for fun, and they are the most fun when they combine together in sweet ways. During the dead of winter, I spent a bunch of weeks working on Photobomb . On of the features that I added was that you could add an image directly from your web cam. To do this, I used the PyGame Web Cam API, essentially because I saw the API, and knew that I would be able to use it relatively easily, which in fact turned out to be the case.

It also turned out that not everyone had PyGame already installed on their systems. As a result installing Photobomb meant a 25+ Megabyte download, most of which was PyGame. So I was advised to use GStreamer instead. I got started on this conversion back in April, by creating a simple web cam display application using gstreamer. I ran into a series of roadblocks, one such roadblock was removed by Chris Halse Rogers of desktop team fame, who knew why it kept crashing (basically, I was trying to access the xid of a widget that wasn't yet realized).

But I soon had a pipeline together that could display the web cam, but I could not figure out how to modify it so that it could save out a picture whilst still displaying the web cam output. I finally hopped into #gstreamer to see if someone could give me a pointer. Well, it turns out that someone already wrote a pipeline called caemerabin that does everything I need for the web cam, and more.

Well, it turned out that the documentation was out of sync with the current API. This isn't too surprising, as camerabin is still in gstreamer0.01-plugins-bad, and the API is actually improved by the changes. But I was struggling to understand camerabin, so I went back to #gstreamer. Often in IRC, someone will volunteer to spend some time helping you out with a problem. thiagoss (who I think might be this guy) really helped me out. I'm not sure, but I think he may actually be a primary author of camerabin. Anyway, he set me straight on a couple of things, namely:

1. use $gst-inspect camerabin to see what properties and methods the GStreamer elements really support (if they are out of sync with the docs).

2. use GST_DEBUG=2 to run your gstreamer apps, as this puts more warnings in your output.

Well, between these 2 tips, I was quickly able to realize that my WebCamBox widget would not much more than some Gtk/Gstreamer app boiler plate, with a wrapper around camerabin.

So, for example the "take picture" function just creates a time stamp, then tells the camerabin instance to emit a "capture-start" signal.

      stamp = str(datetime.datetime.now())
extension = ".png"
directory = os.environ["HOME"] + _("/Pictures/")
self.filename = directory + self.filename_prefix + stamp + extension
self.camerabin.set_property("filename", self.filename)
self.camerabin.emit("capture-start")
return self.filename

Then in on_message, I capture the message that it is done, and fire a signal:

       t = message.type
if t == gst.MESSAGE_ELEMENT:
 if message.structure.get_name() == "image-captured":
     #work around to keep the camera working after lots
     #of pictures are taken
     self.camerabin.set_state(gst.STATE_NULL)
     self.camerabin.set_state(gst.STATE_PLAYING)

     self.emit("image-captured", self.filename)

Play, Pause, and Start were trivially easy to implement:

        self.camerabin.set_state(gst.STATE_PLAYING)
self.camerabin.set_state(gst.STATE_PAUSED)
self.camerabin.set_state(gst.STATE_NULL)

Like I say, there is also some boiler plate to instantiate the camera and associate it with a gtk.DrawingArea. It took me a lot of iterations to get it working, as you can see from all of these pictures of me working on it ...

The net result is that it's now pretty easy to create an app with a web cam in it. Here's all the code for the WebCamBox test app.

if __name__ == "__main__":
"""creates a test WebCamBox"""
import quickly.prompts

#create and show a test window
win = gtk.Window(gtk.WINDOW_TOPLEVEL)
win.set_title("WebCam Test Window")
win.connect("destroy",gtk.main_quit)
win.show()

#create a top level container
vbox = gtk.VBox(False, 10)
vbox.show()
win.add(vbox)

mb = WebCamBox()
mb.video_frame_rate = 30
vbox.add(mb)
mb.show()
mb.play()

mb.connect("image-captured", __image_captured)
play_butt = gtk.Button("Play")
pause_butt = gtk.Button("Pause")
stop_butt = gtk.Button("Stop")
pic_butt = gtk.Button("Picture")

play_butt.connect("clicked", lambda x:mb.play())
play_butt.show()
mb.pack_end(play_butt, False)

pause_butt.connect("clicked", lambda x:mb.pause())
pause_butt.show()
mb.pack_end(pause_butt, False)

stop_butt.connect("clicked", lambda x:mb.stop())
stop_butt.show()
mb.pack_end(stop_butt, False)

pic_butt.connect("clicked", lambda x:mb.take_picture())
pic_butt.show()
mb.pack_end(pic_butt, False)

gtk.main()

Almost all of it is standard code for creating widgets. I love that doing functions like play, pause, stop, and take a picture can be handled in lambdas. So much easier!

So my last step was to drop it into Photobomb. All I had to do was modify the CameraPage class that I had already set up for the PyGame based version.

import gtk
from quickly.widgets.web_cam_box import WebCamBox
from ImageListPage import ImageListPage

class CameraPage(ImageListPage):
def __init__(self):
   gtk.VBox.__init__(self,False, 0)
   self.__camera = WebCamBox()
   self.__camera.connect("image-captured",self.image_captured)
   self.__camera.show()
   self.__camera.set_size_request(128, 128)
   self.pack_start(self.__camera, False, False)

   button = gtk.Button("Take Picture")
   button.show()
   button.connect("clicked", lambda x:self.__camera.take_picture())
   self.pack_start(button, False, False)


def image_captured(self, widget, path):
   self.emit("clicked",path)

def on_selected(self):
   self.__camera.play()

def on_deselected(self):
   self.__camera.stop()

Well, almost all I had to do. I discovered a bug where if the WebCamBox is not actually visible, it locks up Photobomb if you try to show it. For now, I've worked around this by putting the CameraPage as the first and open page, so it just works. However, I suspect the bug is due to the xid not being available when camerabin tries to display on it. I think with a little thought, I can block this condition, and perhaps not let the camera play if it's not ready yet.

Anyway, I ended up with a few lines of wrapper code, around my wrapper code, and it all works thanks to the efforts of the folks working on camerabin!

camerabin has a whole lot of functionality that I haven't wrapped yet. It takes video, including audio! Also, it looks like you can change encoders, and drop in filters and such into the pipeline. To handle this for now, WebCamBox exposes a "camerabin" public property, so if you are using the widget, you won't run into a wall.

Quickly Widget Dating

2010-09-01T19:56:00.000-07:00

Earlier this summer I started some work on DictionaryGrid and GridFilter in order to make them easier to use in apps like PyTask.

Well, tonight I decided to finish what I started and get this stuff into trunk. Specifically, I wanted to have a DateFilter to go with DateColumn. I wanted to use a Calendar widget for users to select dates, instead of typing them in.

Before I could do that, I had to do some heavy refactoring in GridFilter. I originally made the simplifying assumption that users would enter text into an entry field to enter their values. The only exception was CheckFilter, which needed no gtk.Entry, but I just put in a small hack to make that work. So, this simplifying assumption meant that I could deliver grid filters really fast, but now it was time refactor so I could add new features.

Fortunately, it seems that I had started that and was well on the way, so I only had to finish a few things out for the refactoring. I had even already implemented CheckFilter in the new structure, so it was a simple matter to copy that pattern to get to the DateFilter working.

It's always an odd feeling when I am working with code that I had written a while back. There's a certain amount of detective work involved, "how did I go about making this all work?" There's a strange familiarity, but yet it's similar to debugging someone else's code. It's nice when I figure it out, especially when I think "that's just how I would have done it."

I also found a rather serious bug in CouchGrid along the way. So I stopped off and spent some time fixing CouchGrid, and adding test to make sure I don't see that bug again. The code slightly improved while I was in there, making sure that the grid doesn't have to render itself multiple times when it's initializing.

Anyway, I'm really happy to have made some progress on Quickly Widgets again. It was really fun and relaxing. Time well spent this evening.

Why I Have Nothing Interesting to Say

2010-09-01T07:45:00.001-07:00

This posting has been kicking around in my draft's for almost 2 weeks now. I've been wanting to polish it a bit, since it's a bit personal, but Jono's posting a couple of weeks back inspired me to just run it over and get it out there, even if it's still rough. I have nothing interesting to say, anyway ;) Just be warned, the following is not well organized or concise in any way ....

Anyway ... I normally use my blog as a way to share and get feedback on projects like Quickly and Quickly Widgets. I haven't been blogging because I haven't been working much on those things lately, so haven't had much interesting to say along that front (though a friend did unblock me on my WebCam widget, so now I'm blocked on bending gstreamer to my will rather than a random crash.)

The reason that I haven't been working on those is two fold. One part, I've been traveling a lot for work and I took a holiday. But the main reason is related to a recent refactoring of the Ubuntu related teams at Canonical.

Changes to Canonical Organizational Structure

This refactoring (or "reorg" in corporate speak) was led by Matt Zimmerman and Robbie Williamson. The resulting structure broke the whole 100+ person Ubuntu team at Canonical into 3 teams:

1. Linaro Engineering. These are the Canonical folks working on the Linaro project.

2. Platform Services. This team is dedicated to doing work in Ubuntu for partner teams in Canonical, like OEM services.

3. Ubuntu Engineering. The team of Canonical developers focused on Ubuntu the Free and Open Source Community distribution.

I believe the purpose of this refactoring was to make the teams a bit smaller and more focused. However, one of the effects was to leave the Ubuntu Engineering Team with an even tighter focus on Ubuntu as a community distro. Ubuntu Engineering is the biggest team of the three, I believe 85 or so people working on it.

Changes to My Role(s) in Ubuntu

Another effect is that of the refactoring was that each of these teams needs a leader, or "Director" in terms of job title, each of whom will report to Matt. The reason that I have been a bit busy to work on Quickly and Quickly Widgets is that I interviewed for, and subsequently got the "Director" role for Ubuntu Engineering. So my job title is now "Ubuntu Engineering Director" (or something like that). I'm still also the Engineering Manager for the Desktop Team until we can find someone awesome to take that role (we're still interviewing, so if you are interested, please apply!!).

This all went down like 10 weeks ago or something. The personal effect on me is that I've been trying to learn how to do a new role while still trying to hold down the fort on the desktop. So, basically, I am working 2 full time roles. As you can imagine, I am not doing either very well.

Figuring Out My New Job

As Director, the engineering managers for the kernel, foundations, server, ARM, desktop, QA, and community now "report" to me. Of course, you know these folks (pgraner, robbiew, jib, davidm, tbh, marjo, and jono) and you know that they are awesome. There are a couple of new roles too (release manager and technical architect). We have very strong people in these roles as well.

So if the management team and the engineers are so awesome, what's my job? This is a question I have been asking myself, and I do see some areas where I should provide some leadership. I'd like to spend the rest of the post quickly commenting on just one of those areas. It's a bit hard to label, but I think I'll put it under the heading of "Nurturing the Ubuntu/Canonical Partnership".

Of course I was originally attracted to Ubuntu because it's a Free and Open Source Community Distro, but what made me quit my job and base my living around Ubuntu was that it's a community distro with a Commercial Partner. I thought that a commercial partner would make my efforts more relevant (by reaching more people) and more endurable (by sustaining the project for a long time). A commercial partner can also negotiate with OEMs and help fulfill the dream of a pre-installed FLOSS desktop.

So it's important for Ubuntu to honor this partnership in order to maintain it's staying power and relevance. Conversely, it's important to Canonical that Ubuntu is a thriving community open source distribution. The reasons for this are probably self-evident, so I'll leave that out. Anyway, it's helping Canonical with this part about being a good partner to Ubuntu that the rest of this post is about.

Being Part of the Community
Firstly, in my view, being employed by Canonical is not something that separates me from the Ubuntu Community. If anything, it provides me a lucky position within the community, if nothing else because I am paid full time to contribute to Ubuntu I have more time to dedicate to it. The point is that being on the Ubuntu Engineering Team means that I am part of the Ubuntu Community. This is true for allpeople employed by Canonical to work on the Ubuntu. The Ubuntu community is comprised of all kinds of people contributing in all kinds of ways, including some that get paid by Canonical to work on Ubuntu full time.

So, if Canonical and Ubuntu both benefit from this partnership, and I am both part of Canonical and the Ubuntu Community, I think that part of my new role of Director should be to help these partners work well together. There are some things that I think we (Canonical employees in the Ubuntu Community) can do better in this regard. I'm still thinking through it, but I am formulating two key goals at this point, one around transparency, and the other around growing the number of core contributors.

Transparency

I think that we (the whole community) still follow our transparent processes around UDS, blueprints, specs, and bugs. So we are transparent in the sense that anyone can come and carefully study our documents and learn pretty much anything they want about what Ubuntu is working on. I suspect that the way of being "transparent" work very well for the project when there were way fewer users and way fewer people working on the project. But now the project has grown a bit, and perhaps the old ways are not totally sufficient.

In one sense, we've made great strides in exposing what we are working on via our work item tracker. But this a very granular view. I'd like to see us do better in expressing the gestalt of a release, the high level goals for the release. I'd like to see us be able to *push* information at this level before, during, and after UDS, and throughout the cycle. I don't know if this goal is really about changing the way we work per se, so much as creating an information architecture around the work that we (and I mean "we" inclusively as the Ubuntu community) are doing, and then having the discipline to maintain a drum beat of communication within that architecture. In this way, the community should better be able to see what the Ubuntu Community and Canonical is focused on in developing Ubuntu, and how that work is going.

Growing Core Contributors

While I think the work item tracking system has been great for exposing what we are working on, and also for providing visibility into our status, I suspect it has had an unintended effect. I think it's turned the Canonical employees into feature creation machines. Something about a burn down chart motivates you to work to stay under that trend line. While creating lots of new features is great, I am concerned that it has come at the expense of other important work. A community needs investment, and I am wondering if our focus on work items and features has supplanted some amount of our investment in the community (and by "our" here, I am referring to Canonical Employees in the Ubuntu Community).

I can see several areas, such as patch reviews, REVU, archive admins, etc... that are bottlenecked by not having enough core contributors. But our very inability to focus on things like reviewing patches and REVU means that we are not inviting new people to build towards being core contributors. But new people is exactly what we need to remove the bottlenecks! A sweet catch-22. I think that this will require the bold move to hold back on commitments to features, to tilt Canonical Employees investments a bit toward nurturing those new comers (as well as our stalwart comrades, of course).

So there are 2 great topics for UDS discussions. Whatever the case, can I just say that I am thrilled to have this new gig, and I look forward to getting to know a whole lot of people and to help them with their goals for Ubuntu? I guess being my blog, I can say that ;)

Can we count users without uniquely identifying them?

2010-08-10T08:13:00.000-07:00

Aaaah

Hi all. I'm just back from a rather nice holiday. Well, technically, I'm still on holiday, but there were a few things I wanted to take care of, so I popped in for a few hours of work yesterday and today. I saw that there was this post on Phoronix that triggered me writing a post that I've been meaning to do for the last few weeks, since the Canonical Platform Team got together in Prague three weeks ago, to be exact.

Pre-installed desktops ftw

One of the roles of Canonical relative to Ubuntu is to get Ubuntu pre-installed on as many computers as possible. This is one of the dreams of the Linux desktop. Pre-installs mean end users don't have to fiddle with configurations, installing drivers, etc... (at least when done well) and the users can make an apples to apples comparison between their free desktop and proprietary systems that normally come pre-installed.

Canonical does this by working with OEM customers. OEMs are companies that sell assembled computers to people. One of these customers asked Canonical if there was some way that they could know how many computers that they send out with Ubuntu on them keep Ubuntu on them. The customer's engineer came up with a system where they would create a unique identifier for each Ubuntu computer they sold, and then when the computers requested update info daily, it would send that unique identifier with it.

The customer didn't really want to use a unique identifier though, because though it was anonymous, the customer wanted to *count* computers, but unique identifiers are for *tracking* (following a user over time). We mulled it over and over, and finally, based on our experience with web browsers we hit upon a system of non-unique channel identifiers to do the counting. This would make tracking impossible, but of course, tracking is not the goal, counting is.

Non-unique channel identifiers

So, we flashed on this: if each install sent just the model name and the number of times it has updated, systems could be counted, but no unique data would ever be sent to the server. Now, I am not a mathematician, so each time I try to explain why I think this works, it takes me a while. But in the end, everyone is convinced. In fact, Matt Zimmerman ended up writing a test program to prove to himself that it worked. Let me try, stick with me here ...

Every day each computer from the customer sends it's model name and the number of times it has already sent this data to the server. So if a model of a computer is called, say "foo", the first day it sends "foo" and 0 to census.canonical.com. After sending the 0, the computer remembers that it already sent a 0, so it will send a 1 next time. When the server sees the foo.0 in the log data, it essential stars a new counter for the model foo. The total number of foo.0 are the total number of the model foo ever activated.

Take one of those foo computers. The next day it will send foo.1, saying "this is a computer of model foo, and this is the 2nd time it has pinged that it's alive". Notice that neither foo or the number 1 are unique data. Any number of computers will be reporting the exact same model name and increment number. When the server sees a 1 come in, it finds the first counter at 0 and increments that counter to 1. Now it knows the total number of computers ever activated (all the counters), and it can count all the counters that were incremented in a day and thereby know how many computers were online that day.

Future?

Currently this system is only slated to be used by the specific OEM customer who requested it, and it will be up to the customer to disclose the data they collect as they wish. I wonder if it would be a good thing to install on normal ISOs though, but this would be part of our normal participatory community decision making process. Projects like this make think that users would like to be counted, so long as they can't be tracked. We'll see how it plays out, it may be something to discuss at UDS if the community feels the data would be useful.

New Quickly Widget: Text Editor

2010-06-20T12:12:00.001-07:00

Here's an 8 minute demo showing how to use the new TextEditor Quickly Widget. This removes all the pain and suffering of adding text editing functionality to your app. No more gtk.TextBuffer, no more gtk.TextIter. Just a series of simple function calls, and you're ready to go. Of course, TextEditor is a gtk.TextView, so if you need to access any of the power and flexibility of the underlying Gtk library, it's right there.

TextEditor is now available in quidgets trunk.

Sorry for the loudness of the video. I made it in a coffee shop, and moved my mic closer to compensate for background noise. It didn't work out too well.

New Quickly App: Daily Journal

2010-06-20T11:08:00.000-07:00

Quickly has started to unlock productivity for me in unexpected ways. I've mentioned about writing my own development tools, like bughugger, and slipcover. Last week I extended this to writing my own productivity apps. In this case, I wrote an app to replace my Tomboy usage to focus specifically on the functions in Tomboy that I actually used. The above video shows that app, "Daily Journal". It's available in my PPA.

In my next posting, I'll show how I used quickly.widgets.text_editor to create Daily Journal.

Go Here to Learn to Program from MIT

2010-06-14T10:24:00.000-07:00

I run into folks who want to get started programming, but they "don't know a language". If you are in this camp, I highly recommend the online course from MIT. It's designed for people with no prior programming experience, and it's Python!

After the first few lessons, you'll know enough Python to start a Quickly app!.

New Quickly Widget - async downloads with two lines of code

2010-06-06T11:33:00.000-07:00

The Ubuntu Developer's Manual team was discussing the instructional app that we should use for the manual. During this discussion, it became apparent that there wasn't a way to download from a URL that was both easy and also asynch. Instead of choosing between simple and good, Stuart made a Quickly Widget that provides a way to fetch from a URL that is both simple *and* good.


     fetcher = UrlFetchProgressBox("http://identi.ca/api/statusnet/groups/timeline/8.rss")
     fetcher.connect("downloaded",self.create_grid_from_feed)

So, two lines! Just say what url you want to download, and tell it the function to call when it's done.

Having Users Makes Your Code So Much Better

2010-06-01T16:44:00.000-07:00

I mentioned in a previous post that I was finding PyTask to be pretty cool. Of course, one of the cool things, for me, was that it used Quickly Widgets. As I mentioned, Quickly Widgets lacked some key features, like a DateColumn.

Having a user means that I know at least one way that someone it trying to use the code. I went ahead and implemented a DateColumn in PyTask, and my next step will be to add DateColumn to quickly widgets, so Ryan doesn't have to maintain the code in PyTask. First I need to kind of make room for this in the grid_filter module. I have a good idea of how to do it, so just a SMOP at this point.

There were other more subtle things that I ran into as well. For example, it turns out that I didn't handle the case of deleting rows in a CouchGrid, or even removing rows from a DictionaryGrid if that grid was filtered. The later case was "just" a bug. So I worked around this in PyTask code so that PyTask could ship while waiting for me to fix Quickly Widgets.

Since I have intimate knowledge about how the PyGtk was assembled, I was able to write this code for PyTask

    def remove_row(self, widget, data=None):
"""Removes the currently selected row from the couchgrid."""
# work around to actually delete records from desktopcouch
# in maverick, using delete=true in remove_selected_rows will have
# the same effect
database = CouchDatabase("pytask")
for r in self.grid.selected_rows:
   database.delete_record(r["__desktopcouch_id"])

if type(self.grid.get_model()) is gtk.ListStore:
   self.grid.remove_selected_rows()

else:

   # The following code works around:
   # https://bugs.edge.launchpad.net/quidgets/+bug/587568
   # get the selected rows, and return if nothing is selected
   model, rows = self.grid.get_selection().get_selected_rows()

   if len(rows) == 0:
       return

   # store the last selected row to reselect after removal
   next_to_select = rows[-1][0] + 1 - len(rows)

   # loop through and remove
   iters = [model.get_model().get_iter(path) for path in rows]
   store_iters = []
   for i in iters:
       # convert the iter to a useful iter
       store_iters.append(model.get_model().convert_iter_to_child_iter(i))

   for store_iter in store_iters:
       # remove the row from the store
       self.filt.store.remove(store_iter)

   # select a row for the user, nicer that way
   rows_remaining = len(model)

   # don't try to select anything if there are no rows left
   if rows_remaining < 1:
       return

   # select the next row down, unless it's out of range
   # in which case just select the last row
   if next_to_select < rows_remaining:
       self.grid.get_selection().select_path(next_to_select)
   else:
       self.grid.get_selection().select_path(rows_remaining - 1)

Essentially, it deletes the selected rows from desktop couch, and then goes on to figure if the grid is filtered, and if so, figures out where in the unfiltered model the rows are, and removes them from there. It also tries to select a row for the user after removing.

So I moved the code to delete records from desktop couch into CouchGrid.remove_selected_rows and all the "remove properly even if filtered" goo into DictionaryGrid.remove_selected_rows. The result is that when the next version of Quickly Widgets lands, Ryan will be able to simplify the function down to this:

    def remove_row(self, widget, data=None):
"""Removes the currently selected row from the couchgrid."""
self.grid.remove_selected_rows(delete=True)

A bit more sensible.

Another area where the DictionaryGrid lacked functionality was related to column titles. It was easy to write a little code to change the column titles:

        for c in self.grid.get_columns():
      if c.get_title() == "name":
          c.set_title(_("Name"))
      elif c.get_title() == "priority":
          c.set_title(_("Priority"))
      elif c.get_title() == "due":
          c.set_title(_("Due"))
      elif c.get_title() == "project":
          c.set_title(_("Project"))
      if c.get_title() == "complete?":
          c.set_title(_("Completed"))

Except, when doing this, it meant that the column titles in the GridFilter didn't match. :/ This is because the GridFilter got the names of the columns from the keys instead of the title.

Again, knowing the structure of the PyGtk intimately, I was able to work around this by modifying rows in the filter as each is created:

   def __new_filter_row(self, widget, data=None):
   """
   new_filter row - hack to allow naming of columns
   in a grid filter.

   This code works around:
   https://bugs.edge.launchpad.net/quidgets/+bug/587558

   """

   row = self.filt.rows[len(self.filt.rows)-1]
   row.connect("add_row_requested",self.__new_filter_row)
   model = row.column_combo.get_model()

   for i, k in enumerate(model):
       itr = model.get_iter(i)
       title = model.get_value(itr,0)
       if title == "name":
           model.set_value(itr,0,_("Name"))
       elif title == "priority":
           model.set_value(itr,0,_("Priority"))
       elif title == "due":
           model.set_value(itr,0,_("Due"))
       elif title == "project":
           model.set_value(itr,0,_("Project"))
       if title == "complete?":
           model.set_value(itr,0,_("Completed"))

I fixed this a bit easier in Quickly Widgets.

All of this managing the title stuff was really obtuse, and it seemed that setting column titles might be generally useful. So I added two things to DictionaryGrid to make this easier. First, I made a property that returns a dictionary of columns indexed by the column key, so you can easily get ahold of a column you want. Here's some code from one of the Quickly Widget tests:

        grid.columns["key1_1"].set_title("KEY")

That's a bit easier than for c in grid.get_columns(), etc...

I also made a convenience function that Ryan can use. Here's the code from the tests:

        titles = {"key1_1":"KEY1","key1_2":"KEY2","key1_3":"KEY3"}
     grid.set_column_titles(titles)

So this should make it really trivial to manage the titles of columns separate from the keys in the dictionaries. Of course, if you don't want to care about column titles, that's fine too. They still work just by using the keys.

Anyway, thanks to Ryan for letting me use PyTask to improve Quickly Widgets!

Video Walkthrough of Work Item Tracker for Maverick

2010-05-26T10:20:00.000-07:00

Track the Desktop and UNE in Maverick

2010-05-25T10:09:00.000-07:00

Ubuntu development happens in a very transparent manner. I won't cover the lead up and execution of UDS here, but I will discuss what happens after UDS for maverick.

First, you should know where we are in the schedule. The schedule is always available.

At UDS discussions center around blueprints. After UDS, the Ubuntu developers take the set of blueprints that they are committed to working on, and they break down the blueprint into "work items". A work item is roughly one half to two days of work that is a required step to accomplish the blueprint.

Work items are then mapped to a milestone, or work item iteration. Note that the Ubuntu developers only commit to workng on work items for the current work item iteration! The current work item iteration maps to Alpha 2. So you can see the work items that the desktop team is committed to working on on our Alpha 2 tracking page.

If you want to explore the whole release, you can see the landing page for all of Maverick.

But remember that work items that are not slotted to Alpha 2 are not committed to yet!

So, what exactly is the Desktop Team planning for Maverick? Here are some highlights.

Software Center

The software center will get many UI improvments. However, the biggie is that we are going to figure out how enable application developers to target the current stable release for new apps! This means new apps that don't modify the underling Ubuntu platform and libraries will be made available in software-center even if the app was written after that version of Ubuntu released. See the blueprint here.

Gnome Changes

We always decide at UDS what to take from new Gnome and how. We are very excited about Gnome 3.0, but due to tight release schedules, we are going to be cautious about Gnome 3.0 for Maverick. We will update to the current platform, and we will deliver gsettings and latest versions of apps as appropriate. As usual, we will make gnome-shell available to users who choose to use it. See the blueprint here.

Browsers and Apps

We're going to try for Chromium by default in UNE, though we are sticking with Mozilla as the default in the Desktop Edition.

We are also changing to Shotwell as the default image library application.

xorg-xserver

Interesting decision here is to hold off on promise of 3D support for -intel 8xx series graphics. If the -intel driver is not providing sufficient stabiliy we may support those chips with Vesa, and perhaps deliver an older intel driver for community support for those 8xx users who want to give it a go.

Social From the Start

We'll work on gwibber start up time and robustness, but also work bake more integration of social services into the desktop.

Everything Else

Of course, we'll be working to integrate the latest and greatest from all of our upstream projects, fix bugs as fast as possible, and generally do all the awesome stuff Ubuntu Desktop developers do everyday.

PyTask, written with Quickly and Quickly Widgets

2010-05-17T05:36:00.000-07:00

On Saturday I received an email from a developer name Ryan. He was using Quickly and Quickly Widgets to create a task list application. CouchGrid seemed to suit, but due to the fact that there are no documents for it, he naturally had some questions about how to proceed. His project is called PyTask, and so far, I like it. It's a very simple set up, and just works in terms of data persistence and syncing across desktops.

Looking at the App, it was clear that there were a few more features that DictionaryGrid needs to really rock, though:

It needs a DateColumn to handle the "due" column. Users would want to set this with a gtk.Calendar widget.
It needs a ComboColumn to handle the "priority" column. Users would want to pick from a list of valid predefined priority values rather than free input text. This will be interesting to create a nice API for. I suppose application developers will want to pass in just a list of strings to the column. I think this is doable, but may take some refactoring as currently there is no intuitive way to get a hold of a column and set a property on it.
Both of these will require new GridFilter functionality. In fact, I have been waiting for a reason to refactor this part of Quickly Widgets, as the GridFilterRows are hard coded to use specific widgets, and this should be flexible.

Anyway, as it is, I am using PyTask, I hope Ryan get's it into a PPA soon. I like the simplicity. Ryan and I are currently collaborating on creating the new functionality in DictionaryGrid that PyTask needs. Open Source FTW!

Install Apps from PPAs without Using the Terminal

2010-04-26T22:12:00.000-07:00

Here's a really nice Lucid feature. In this video you can see that users can now add software from your PPA without using the CLI. They just need to get you deb line, and using the software center, they are good to go.

Quickly: 90 Seconds to Your PPA

2010-04-26T21:06:00.000-07:00

Here's a quick video showing taking a finished Quickly app, setting the desktop and setup.py file, and then uploading to a PPA using $quickly share

Create Your Own Games with Quickly Pygame

2010-04-25T21:01:00.000-07:00

A couple of months ago I created a Quickly template with the goal of making it easy and fun to get started my games. The template doesn't have any "add" or "design" commands, but it does have all the other commands. The template creates a functioning arcade-style game, and then you provide you own artwork and start hacking the code to make your own gameplay.

$quickly tutorial ubuntu-pygame is the best way to get a detailed introduction into getting started making your own game, but here's some video of hacking the code. I hope it inspires you to try your hand at creating your own games.

Part 1: Create the game, copy in your artwork, and make the guy work the way you want

Part 2: Program the enemies

Part 3: Create a power up sprite, and manage collisions

Slip Cover: Creating Views

2010-04-25T13:18:00.001-07:00

I've been doing a few minutes of work a day on slip-cover, working towards getting view editing pretty complete. Pretending that I want to create a view that simply lists all of the keys in a database, you can see here that you now can:

1. Click the "Add Button" above the views, which adds a row to the views that you can start editing. Here I start by naming the design document.

2. Then I name the view. Notice the view editor is not visible yet, as I have not completed specifying the design doc or the name for the view.
3. Then I can try out my map function, and also name the view.
Currently, the view gets automatically saved to the database when created. I suppose this is ok, since it is easy to delete. The view doesn't track the dirty state at all. I should probably do something so users remember to save their views after they edit them. Undo and cut/copy/paste will all be necessary for the map/reduce editors as well.

Quickly and Quickly Widget Intro Videos

2010-04-24T19:36:00.000-07:00

You probably saw that didrocks released another update for Quickly. It's chock full of bug fixes and tweaks based on the feedback from the last release.

About a week ago I made some updated intro videos to show Quickly in action, and highlight some key changes between Quickly in Karmic and Quickly in Lucid. They are all available in HD, so you switch to that when they start playing, it makes them waaay easier to read.

Part 1: Create a project and use Glade to edit the UI

Here you see that you use "quickly create ubuntu-application" instead of "quickly create ubuntu-project" to create an app. You also use "quickly design" instead of "quickly glade" to design the UI.

Part 2: Using CouchGrid

One of the key differences here is that CouchGrid is now in the quickly.widgets module instead of the desktopcouch module. The CouchGrid moved into quickly.widgets because it now extends the DictionaryGrid class. This brings a lot benefits:

Automatic column type inference
Ability to set column types so you get the correct renderers
Correct sorting (for instance 11 > 9 in IntegerColumn, but "11" < "9" in string columns

And of course you get all the goodness of automatic desktopcouch persistence.

Part 3: Using GridFilter

GridFilter is a new class that provides automatic filtering UI for a DictionaryGrid or descendant such as CouchGrid.

Slip Cover, Integrated View Editor for DesktopCouch

2010-04-22T16:19:00.000-07:00

I removed the ViewDesignerDialog, and changed it to a ViewDesignerBox. Basically, a widget that is now embedded into Slip Cover. I also wrote some code to extract the views that currently exist in a database, and offer those under "Views" so you can click on them and see the views map function, and the views reduce function if it has one.

Besides editing views and trying out your edits, this lets you look at the databases you have and see how they work. In the example above, you can see how the views for your contacts are set up. Handy if you want a similar feature in one of your databases.

This screenshot shows two things. First, it shows the view I constructed to get the record type for each record in a database, and also whether the record has been deleted. It's a bit "meta", but the purpose of this is visible in the Record Types list. I use the view to list out the record types, and how many records are deleted and how many active.

Still a few missing features:

The "Create View" button doesn't work yet (though shouldn't be too very hard to make)
"Save View" also doesn't work yet.
I want to add options for executing your view, such as Group and such.
I want to add a bit more data about each database, and whether you can sync it or not. I'm thinking about doing this on the server info tab, maybe an editable DictionaryGrid?

Also, in terms of quickly-widgets, I hate writing the same notebook code for tabbed interfaces over and over again. We should have a quidget that makes it easy and fun, and handles close buttons on the tabs, has a free document menu, and has alt # navigation to documents.

Desktop Couch View Editor

2010-04-18T10:36:00.000-07:00

As I've been learning to use DesktopCouch, I've come to understand the key role that writing map and reduce functions play. Basically, a view is stored map function and optional reduce function. I still haven't quite figured out reduce functions, especially wrt rereduce.

Anyway, I was finding it way to tedious to iterate on views in iPython. A map or reduce function looks to DesktopCouch as a string, thought it is a function written in javascript. And there is no syntax highlighting, or really any help at all writing this function as they look like strings in gedit and iPython.

So yesterday, my ViewDesignDialog was born, and added to Slip Cover. Currently, it supports running a map/reduce function as a temp view. This has been very helpful for me already, as I've been able to finally write a map function gives me each record, it's record and type, and whether that record is active or deleted. I want this for the record types view in slip cover, so you can see if there are any active records associated with the record type. I might be able to go on and build an "undelete" feature which would be handy for undo actions in slip cover.

I will add a "Copy as DesktopCouch" code next, which will just put the code on the buffer so you can paste it into your Python code as desired. Also, I'll add "Save". To do this I'll need to do some work with design_docs.

Eventually, I expect Slip Cover will use this so you can create new views, and edit existing views, for a database using Slip Cover, in addition to having a handy tool for generating DesktopCouch code (or just browsing a database I suppose).

It's not integrated into Slip Cover to well atm. Maybe I'll get a chance to work more on this tonight, but I am plan to do some things that don't involve a keyboard for a while this weekend ;)

Quickly For Lucid Release, Intro Video

2010-04-15T12:00:00.000-07:00

Didrocks released quickly 0.4 yesterday. What a great contribution from didrocks! I suspect he his work will help tons of people have a really fun time writing Ubuntu apps. Read about the release in his detailed blog post.

In the meantime, I made a cheesy video last night, showing some of the changes in quickly, and how the new CouchGrid and GridFilter work.

[Note that it takes blip.tv a bit of time to render out a high def video like this, so if the video is not yet working, you can check back later.]

[D'oh .... stupid blip.tv bailed on encoding my video. I'll try again with smaller files. Stay tuned]

Today's Slip Cover Feature: New Database

2010-04-12T18:47:00.000-07:00

So as planned, today I added the feature for creating databases. This was one of those sweet features where it ended up on the tip of previous coding, so it took literally a matter of minutes to implement. Just get a name from the users, create the database, then load it in the UI,

    def new_database(self, widget, data=None):
     title = _("New database")
     msg = _("Specify a name for the new database")
     response, val = prompts.string(title,msg)
     if response == gtk.RESPONSE_OK:
         CouchDatabase(val, create=True)
         self.load_db(self,val)

So now I have an end to end tool for designing my desktopcouch databases.

Use File->New and make a name for my database:
Get an empty screen for the database.
Use the "+" to create a new record type.
Use Add keys to add keys for record type.
Then add rows and fill in the data.

Today's Slip Cover Feature(s): Add Record Types

2010-04-11T18:03:00.000-07:00

Today I spent a few minutes to add an "Add Record Type" feature. As you can see, this was a matter of creating a button, and then in the handler, creating a single record with only that record type in it.

    def add_record_type(self, widget, data=None):
       title = _("Add Record Type")
       msg = _("""
       Specify a string name for the record type. By convention, the
       name should be a URL where you can document the user of the record type.
       """)
       response, val = prompts.string(title,msg,"http://wiki.ubuntu.com/")
       if response == gtk.RESPONSE_OK:
           r = Record({"record_type":val})
           self.database.put_record(r)
           self.record_type_grid.append_row({"Record Type":val,"editor":None})

After adding a record type, you can use add/delete rows/keys to full design and populate a data set. I'm kind of working inside out with regard to making a full desktopcouch designer. I started with modifying rows, then add/removing rows, then adding/removing keys, and now adding record types.

The next step is to implement New/Delete Database, and I'll a functional designer. I'll probably add Slip Cover to my PPA at that point.

There is no "Delete Record Type" function. This is because desktopcouch never permanently deletes a record, it only marks it as deleted, and as such does not return it when you query for records. This has the odd effect of making Record Types last forever. I am considering adding a "deleted count", and an "active count" column to the grid for the record types. This would take more Map/Reduce skills than I have right now, so would probably be a good thing for me to learn.

Today's Slip Cover Feature(s): Deleting Keys, Refresh Button

2010-04-10T14:55:00.001-07:00

Because I added "Add Key" yesterday, today I wanted to be symmetrical, so I added "delete keys". This turned out to be much more work. First, I ended up creating another quickly.prompt, and then I had to dive into the internals of CouchGrid, and also do some hair raising mucking with desktop couch.

quickly.prompts.checklist()
When the developer clicks the "delete keys" button, I wanted to present them with a list of keys they could choose from. And then have all of those get deleted. This seemed like the kind of thing that I'd want to use in other programs, so I decided to solve this problem generically by adding it to quickly.prompts.

I accomplished this by deriving from quickly.prompts.Prompt, and also creating a helper function. CheckListPrompt works as you would expect for prompt. You set it up by passing in some configuration info, including a dictionary of strings as keys, which will be labels for the checkboxes, and a bool value to determine if the box is checked by default.

You get back a response and val. The val is a dictionary of keys again, with bools for whether the checkboxes are active or not.

So to use the CheckListBox, I just pass in a dictionary of the keys for the CouchGrid, and then see if any were selecct:

       val = {}
    for k in self.grid.keys:
        val[k] = False
    response, val = checklist(title, message, val)
    if response == gtk.RESPONSE_OK:
        #do stuff

Hair Raising Munging
Since "do stuff" is pretty destructive, I use a quickly.prompts.yes_no to confirm that the users wants to blow away all the data and screw up their database. Assuming they do want to delete the keys and values in the desktopcouch database, it turns out to be *not* easy to do the deletion without reading way into CouchGrid. The issue here is the couchdb reserves anything staring with a "_" for itself. But DictionaryGrid uses "__" as a convention to determine that a key should be hidden in the grid by default. So as a result of this CouchGrid munges _id and _rev and record_type before it reads to and from the database.

The second troublesome part was dealing with desktopcouch. It turns out that you can't just delete a key from a record. You have a delete the whole record and then create a new record without that key. so as a result the code deletes and recreates each and every row.

I really think this code belongs inside CouchGrid:

    def delete_keys_from_store(self, model, path, iter, keys_to_delete):
     for k in keys_to_delete:
         d = model.get_value(iter,len(self.grid.keys))
         if k in d:
             del(d[k])
     if '__desktopcouch_id' in d:
         keys = d.keys()
         for k in keys:
             if k.startswith("__desktopcouch"):
                 dc_key = k.split("__desktopcouch")[1]
                 d[dc_key] = d[k]
                 del(d[k])
             if k == "__record_type":
                 d["record_type"] = d["__record_type"]
                 del(d["__record_type"])
         self.database.delete_record(d['_id'])
         del(d["_rev"])
         del(d["_id"])
         self.database.put_record(Record(d))

Who would ever be able to figure out to do all this?

Refresh
So after this the refresh function was trivial. Just tell the CouchGrid to reset, and then recreate the grid:

    def refresh(self, widget, data=None):
      self.grid._refresh_treeview()
      self.remove(self.filt)
      self.filt = GridFilter(self.grid)
      self.pack_start(self.filt, False, False)
      self.reorder_child(self.filt,1)
      self.filt.show()

desktopcouch Editor
So now with adding a removing records and keys, along with freshing, I have a functional desktopcouch editor. This tool has already proved a bit useful in getting a peak into certain database. However, I can't actually create new record types yet. Maybe tomorrow?

Today's Slip Cover Feature: Adding Columns

2010-04-09T20:25:00.000-07:00

I started out wanting to add "refresh". However, I just wiped my netbook and set up Lucid UNE Beta 2 on it, so only had one database in my local desktopcouch and it didn't have any records. I didn't know how I'd test the feature. I haven't set up my Ubuntu One yet on this computer, because I've been waiting for gwibber to get fixed (it is!) so that I could test out the Social From the Start Experience.

This is a long winded way of saying that I decided to implement another feature first to make it easier for me to test refresh out, editing an existing database. The first step of this was to be able to add columns. So I added an "add column" button.

I used quickly.prompts to get the string from the user. To actually add the column required a bit of intimate knowledge of the internals of DictionaryGrid. It occurred to me that folks might want to be able to add a key/column to a Grid themselves, so I logged a bug to remind me to make this easier.

Since Fagan asked to see the code when I posts :) -

    def add_column(self, widget, data=None):
    response, val = prompts.string("New Column","Please select a name for the new column")
    if response == gtk.RESPONSE_OK:
        self.grid.keys.append(val)
        self.grid._refresh_treeview()

Today's Slip Cover Feature: Adding/Removing Records

2010-04-08T16:34:00.001-07:00

Took a few minutes of refactoring gtk code to push the UI around, but I added the ability to delete and rows to a desktopcouch database, by record type. Now I can remove annoying messages from my stream, or put fake ones in!

Bonus Feature

I added a grid filter to the UI (in literally less than a minute using quickly.widgets.GridFilter

Slip Cover, writing my own dev tools

2010-04-08T09:48:00.000-07:00

I use desktopcouch quite a bit for the apps that I write. As a programmer, I want to be able to see into the database and confirm that my code is working, or make tweaks to the database so that I can test out new things. Also, I need to delete databases and records a lot.

Futon is the current tool provided for programmers to work with desktopcouch. However, I find it:

Not work all the time
Too complex UI wise
A Couch tool, not a desktopcouch tool (a subtle but important distinction)

Thus, I started a new project for myself, slip-cover. Of course it's using Quickly 3.9.x ;) Also, the use of quickly-widgets made it very easy to boot strap this project. Though I am starting to see a need for some kind of quickly.widgets.DocumentTabs sort of thing.

The first iterations allows you to:

view some desktopcouch instance info
view records in a database by record type
Modify existing records

I want to add some features based on my needs, in about this order:

Ability to delete records
Ability to delete a database
Ability to add records
Ability to add a field to records
Ability to control whether a database syncs
Ability to view views
Ability to design views

Maybe a "feature a day" approach would work for this, especially as we close in on Lucid Final Freeze.

Fixing a real bug with the help of Winpdb

2010-04-05T09:45:00.000-07:00

Over the last few years as I have gotten more and more addicted to programming Python, I have basically stopped using debuggers. This is not because I write bug free code, but because I prefer not use any of the IDEs available for Python, and I really don't much get along with pdb. I have always found that I need to invest a lot of effort into pdb to get what I want from it, and so now I default to "print line" debugging (using print statements to dump state to the console).

A couple of days ago, I decided to look into graphcial debuggers. I tried some of the Python IDEs out there, and they just really weren't for me. I saw Winpdb in the repositories, and decided to give it try. Today I have a bug that was a good test case for it. I imaging that I will be adding Winpdb to my toolkit on a more regular basis now.

The Bug
Over the weekend didrocks update quickly-widgets in universe for me. quikly-widgets provides the DictionaryGrid class, that I use in bughugger to display data from bdmurray's JSON searches. I check bughugger every morning to see what the desktop team is working on, and generally where we are in terms of the bugs assigned to use.

So when I run bughugger this morning, I saw this:

Oops, only columns. Obviously a bug in quickly-widgets broke bughugger, but where?

Starting the Debugger
So I fired up the Winpdb. First thing is to select the file to launch. So I choose File -> Launch, and navigate to the bin/buhgugger file. I select a line close to, but before where I want to break the program. Clicking in the channel there, are using F9 key, sets a breakpoint. The run button then runs that app and will stop at the first breakpoint it hits in the source.

Debugging
After stopping at the first breakpoint, I see that I need to set a breakpoint in the add_*_triage_page functions, as that's where bughugger starts to assemble the view. The "keys" variable determines what columns are created in the DictionaryGrid, so I decide to watch the keys get passed around. I can see that the keys are set correctly here.

I use "run to line" and "step into" to see that the keys are still correctly set at when BugsPane is being created.
So I run to where the DictionaryGrid is created. The fact that I depended on the order of arguments instead of using keywords looks a bit suspicious to me.

So I step into the constructor for the DictionaryGrid, and see that, in fact, I did change the order of the contructor parameters, so it's not surpriisng the app went a little haywire. I fixed the bug by changing the call to use keywords.
I think using Winpdb saved me tons of time and effort compared to using pdb, or print statement debugging. In any case, it was a matter of minutes to find this bug, do I could go on to fixing the next bug :)

My Lucid Quickly Task List

2010-03-30T17:30:00.000-07:00

I'm seeing if I can just recycle this post instead of create a whole new ones ...

Finished my last bit of Quickly related coding for Lucid just now. Got the quickly-widgets tests passing. I fixed a bug here and there along the way. Changes are pushed into trunk, next I'll ask didrocks to update universe.

Of course, I still have 2 weeks to fix bugs if you find 'em ...

__________

We have entered the Lucid end-game. Which is great. Sadly, there were a whole mess of things for Quickly that I wanted to get done this cycle. I know I won't get to everything, but I can still do a lot. I decided to set out a list of goals, and to work on the list each night, hopefully picking one item off per evening.

I always consider work on Quickly to be related to, but not actually part of, my day job. Thus I enjoy working on it in my free time, but don't typically commit to accomplishing anything specific, because it is my free time, after all. However, let's see how this works.

Here is my tentative list (completed ones are crossed out):

~~Finish fixing pygame template indentation and comments.~~

~~Refactor pygame template to put screen size in the configuration file.~~

~~Create my own sample sounds for pygtame template.~~

~~Make pygtame template actually a template (add the string replacement functions and derive from ubuntu-application commands)~~.

~~Remove CameraButton from quickly-widgets.~~

~~Finish quickly-widgets documentation.~~

~~Make quickly-widgets tests work (test apps currently work, but some of the tests fail erroneously).~~

~~Fix the ubuntu-application template tutorial to use quickly.widgets.couch_grid instead of desktopouch.couch_grid.~~

~~Update ubuntu-application tutorial to use new Quickly commands~~

~~Update ubuntu-application tutorial screenshots~~

Add PPA section to ubuntu-application tutorial.

~~Write PyGame template tutorial~~

Make new videos for ubuntu-application.

Make videos for PyGame.

Those 10+ things seem like good goals to start. If I missed something, etc... please provide a comment.

My "Just Works" Audio Experience in Lucid

2010-03-27T20:23:00.000-07:00

I've been doing a lot of desktop based VOIP calls lately, so decided to invest in a slightly nice set of headphones. I noticed that when my computer's fan is running, it adds a lot of noise to my normal audio card input, so I decided to go with a USB headset. I booted up, plugged into a USB port, and pick "Sound Preferencecs..." from the Sound Menu, and there was my new headphones an mic. A couple of tests, and yes, it works perfectly. First time, no configuration. Sweeeeet.

sfxr for the blam.wav

2010-03-21T22:34:00.001-07:00

I posted on some of the work I want to knock out for Quickly, and specifically regarding the PyGame template, there was this comment:

Michael said...

These look good. I just wanted to point out that if you haven't heard of it, sfxr (http://code.google.com/p/sfxr/) is often used in the indie game community and could help out with #3!

So, yeah, sfxr is quite cool. Just took a bit of Googling to find the dependencies needed to "make" it. I jammed out some sound effects in a matter of minutes. Thanks sfxr dev(s)!

XML Copy-Editor FTW

2010-03-20T08:16:00.000-07:00

Picking up where Fagan left off on the Quickly ubuntu-application tutorial, I'm writing a ubuntu-pygame tutorial using docbook format. The last time I tried available XML editors, the ones I found were crashy, or didn't offer much above and beyond Gedit, so I ended up editing XML in Gedit.

I tried again in Lucid, and found XML Copy-Editor in software-center. I love it! I'm getting statement completion for the schema currently in use (see screenshot above), and error highlighting when I make mistakes. It's also fast and rock solid on my mini 10v!

Interesting that it's built in wxWidgets. I wonder if they target this to be Cross Platform?

Beyond Release Blockers (also a bit on bughugger and f-spot)

2010-03-15T09:39:00.000-07:00

Release Blockers and Beyond
Every release the various ubuntu teams focus on "release blocker bugs". These are bugs that are "High" or "Critical" in importance, and are targeted to the release. Of course they also have to be assigned so that someone knows about them and can work on them.

Of course, every release the desktop team fixes lots of bugs that are not release blockers. seb128 is leading an effort to organize the team to focus on the "right" set of these non-release blockers to fix. These are personal goals that the desktop team members sets for itself.

Process

seb128 is combing through bugs that he considers addressable, and assigning the ones that he thinks will be most valuable to users if fixed to canonical-desktop-team. He sets the importants and targets to Lucid as well. pitti will then assign to specific engineers as needed. Of course, anyone is free to fix these bugs.

Bughugger

I am using bugger to watch this project. The version of bughugger that is currently packaged in universe calculates gravity and looks for attached patches. Unfortunately this makes the queries take so long, that it is basically impossible to use. (I've fixed this in my local copy, but haven't pushed the changes yet. By "fix" I mean removed the slow features.)

However, the JSON searches are working very well. From the bughugger search menu, choose JSON Searches, and you'll get a list of searches that run on a cron job on bdmurray's server.

After the results load, I can look for bugs assigned to the Canonical Desktop Team.

Because we worked in three iterations for Lucid, and minimized work for the third iteration, I am hopeful that we have a bit more time for bug fixing this cycle. However, even if the amount of bug fixing stays the same, I expect that having seb128 on point for choosing the highest impact bugs organized in a single list will help the best set of bugs get fixed by the desktop team, enhancing the general community quality efforts.

F-Spot

On a side note, RAOF has recently joined the desktop team as a Canonical supported employee! One of his first tasks was to implement the f-spot features required for the default application selection blueprint. F-spot now handles in situ editing of files. Which means no need to load images into the library to edit them, and no need to load up the gimp just do a quick crop! I cropped these screen captures using f-spot and it worked swimmingly. Thanks RAOF!

Ink Scape + PyGame = Fun

2010-03-14T16:02:00.000-07:00

Dropped in some new image files while working on the PyGame template tutorial

Quickly Task List Progress

2010-03-10T21:07:00.000-08:00

Well, Monday night I went out for beer with my wife. Last night I cooked dinner and spent time with my kids. So, good nights, but no progress on my Quickly Task List.

However, I made some good progress #5 and #6 today.

Well, #6 was just: $bzr rm camera_button.py, so not much accomplishment there.

However, I made solid inroads for #5, documentation for #quickly-widgets. I got PressAndHoldButton totally documented, and did the module documentation for grid_column.py, which included a bit of work to document how to create a custom column for a DictionaryGrid.

Speaking of DictionaryGrid, I got a question from a developer using it about how to respond to edits in the DictionaryGrid. I realized that I did not make this easy. It's easy to enable the UI for editing, but in order to receive a signal when a change occurred required iterating though the columns and attaching to each column's edited (or toggled) event. So I fixed this by adding a "cell-edited" signal and that's in trunk now.

It's so important to be getting feedback from users. Otherwise, you don't know the right use cases, and you can miss obvious things like this.

The Raving Rick

Bit of fun with JQuery and CSS

In Vino JQuery, not a Socratic, dialogs

In Vino Veritas and HTML5 Client Apps

Smoke Tests

12.04 Quality Initiatives Update

Some Rock Solid things are Quite Beautiful

Stealthy, An App to Pause Desktop Logging

Using PyGame in a PyGtk App

A Photobomb Sale!

Cha-ching!

The End of an Era?

Coding Copy and Paste Functionality

Coding an Undo/Redo Stack

My Effort at Writing Help for Unity

Overview

How to Activate Applications via the Launcher

How to Activate Applications from the Dash

Adding an Application to The Launcher

Finding and Opening Files

Running Applications in Unity

Managing Windows

Switching Between Active Windows

Window Size and Positioning

Workspaces

Settings

Congrats to GNOME!

Unity Almost There

Video Demonstraton of a Few Things I Like in Unity

Easily Support the Sound Menu in Python

Python Sound Menu Integration or GDBUS Can't Come Soon Enough

Pithos of Rain

The Dash Has Landed

Quickly Tutorial for Natty: DIY Media Player

New Quidget: MediaPlayerBox adds video to your app in a few lines

Changing the Opacity of gtk.Pixbuf

This is Photobomb

New Personal Goal: Photobomb for Natty

Hot New Quickly Template Features

Alpha 1 Unity Checkpoint

Log those Unity Crash Reports!

Unity in Natty Evaluation 1

Ubuntu is *not* moving to a rolling release

3 Weeks In

1 Week In

This is it!

$quickly create ubuntu-pygame targets

Anything New in Quickly Widgets for Maverick?

Quidgets < 3 Gstreamer, and the Return of Photobomb

Quickly Widget Dating

Why I Have Nothing Interesting to Say

Can we count users without uniquely identifying them?

New Quickly Widget: Text Editor

New Quickly App: Daily Journal

Go Here to Learn to Program from MIT

New Quickly Widget - async downloads with two lines of code

Having Users Makes Your Code So Much Better

Video Walkthrough of Work Item Tracker for Maverick

Track the Desktop and UNE in Maverick

PyTask, written with Quickly and Quickly Widgets

Install Apps from PPAs without Using the Terminal

Quickly: 90 Seconds to Your PPA

Create Your Own Games with Quickly Pygame

Slip Cover: Creating Views

Quickly and Quickly Widget Intro Videos

Slip Cover, Integrated View Editor for DesktopCouch

Desktop Couch View Editor

Quickly For Lucid Release, Intro Video

Today's Slip Cover Feature: New Database

Today's Slip Cover Feature(s): Add Record Types

Today's Slip Cover Feature(s): Deleting Keys, Refresh Button

Today's Slip Cover Feature: Adding Columns

Today's Slip Cover Feature: Adding/Removing Records

Slip Cover, writing my own dev tools

Fixing a real bug with the help of Winpdb

My Lucid Quickly Task List

My "Just Works" Audio Experience in Lucid

sfxr for the blam.wav

XML Copy-Editor FTW

Beyond Release Blockers (also a bit on bughugger and f-spot)

Ubuntu is not moving to a rolling release