Older blog entries for ted (starting at number 8)

Let applications be applications

One thing that kept bothering me in the GNOME UI Hackfest was how little data applications export out to the desktop. As I was in the shell group we were discussing various things that we wanted to do and John Mccann kept having to remind me not to worry about the implementation as I would get frustrated that we simply didn't have the data. I want to fix this. I want to have the data in a structured way.

What I've come to realize is that we need to let applications be applications, let panels be panels and let applets be applets. With the notification area specification we created a way for applications to break through this barrier and put a little segment of the application into the panel. While this sounds great, and it has created a quick way to prototype some interesting ideas, it's also created a complete mess in our panels. There is no consistency of action nor in look for that section of the panel. I like to call the notification area the "bag of crap." While it's created a way for applications to innovate, it's drastically stalled innovation for panels and shells.

What I'd like to put forward is the idea of little flags that applications can hold up to say what they're thinking or doing, which I'm going to call indicators. The application can then represent in a structured way that it's got something of interest to the desktop as a whole, and then the desktop can represent that to the user. How ever it likes. It's not the application's responsibility to figure out how to do this, or if it needs to be done in a single place or multiple, or anything other than raising the flag. While I think that this might frustrate application developers at first in that they don't have control over the display of this information, I think that long term it will empower them in that they don't have to fiddle with this type of interaction any more.

First off I want to build something simple (start small, think big), the messaging indicator, which will mostly consist of a GNOME panel applet. It will do simple things like represent IMs and e-mail and not a lot more, but the real goal is starting to get applications like Evolution and Pidgin to export this information. Once we're there, then we can start to look at new ways to use it. I love the idea of having the Evolution icon having the number of unread messages a la Apple or Gwibber also putting messages in the messaging indicator. Those are all next steps, but I think important ones in starting to explore how we can get data out of the applications and to the users in usable and attractive ways.

Syndicated 2009-01-06 04:52:00 from TedBlog

Where music is going

I'm going to make a bold prediction here, hold on to your hats! I'm going to predict that the next music player I buy will have more storage than the one I have now. I'd bet even the one after that will have more than that one!

While that prediction isn't groundbreaking, thinking about it lead me down an interesting path. I, like probably a lot of people, got onto the bandwagon of ripping my CDs to MP3s pretty early. It was exciting to have my whole collection of music on my hard drive (portable players were pretty rare back then) and compared to my computer speakers the quality was amazing! After doing that, I was then at the point of realizing that I needed to do it again. Things like reliable tagging made it so most of the files weren't useless, but I would get better results by just starting from scratch. So I did.

I then realized that I never want to do this again so I needed to rip all my music into a lossless format, but no player could hold all that data, at least not yet. In turn that forced me to realize that over time storage will probably grow faster than the amount of music I'm interested in, but the variable I can adjust is quality. So I can build a bunch of 96 kbps MP3s for my phone and keep 256 kbps OGGs for my laptop. And, eventually, everyone will just have those flac files I originally ripped. Whew, now getting from A to B.

I decided that I needed to make a Makefile for a few different reasons:

  • Make handles the idea of transformations pretty easily, so the idea of a transformation between flac and another format would be simple to express.
  • Make already tracks which jobs are complete by looking at the file times and which files are created. This would make it easy to rip new CDs as only the new files would be re-encoded.
  • Make can parallelize the whole thing for me to work on my dual-core processor. nice make -j 2
  • If I quit half way make will delete the half built files and allow me to pick up where I left off.
The one problem that I had using Make is that it doesn't easily handle file names with spaces in them. This was easy enough to change:
$ find . -name "*.flac" -exec rename "y/ /_/" {} \;
Which is a small one line operation to find all the files ending in .flac and replace all the spaces in their name with underscores.

Here is the Makefile and the small shell script that I'm using to do the conversion (mostly stolen from a forum thread I can't find now). Everything is grossly hardc oded, but it works great for my situation. My situation includes putting both of these in the Flac folder and wanting to put all the MP3s into the ../mp3 folder. Currently it only builds MP3s at 96 kbps. Good luck, hopefully my collection will be encoded in a couple of days.

Syndicated 2008-12-31 02:29:00 from TedBlog

Where are my messages?

One of the improvements that we worked on for the Intrepid release is building a combined applet with the fast user switching, session management and maintaining instant message status. I'm happy with how this turned out. I'm planning on continuing the messaging story in Jaunty.

An interesting aspect of messaging on the desktop is that while you can get messages, and get a notification of their appearance, you still may want to respond to them. Currently every messaging app you run provides this through it's own icon into the notification area. Many people I know have both Pidgin and XChat icons in their notification area routinely. Besides the fact that both of these work significantly differently, they also are very different visually providing the appearance of clutter in the panel.

How do we fix this? I think that a reasonable approach is to consolidate them into what I'm coining as a "messaging indicator." The goal of the messaging indicator is provide a simple and clean way for messaging apps to provide the notification to the user that other people are trying to talk them while not having to put something in the notification area. The notification area is evil. Here's a simple use case done as an SVG mockup:

I'm sorry, it seems that your browser does not support SVG. Here is the diagram, please upgrade your browser to a newer version.
Or, you're reading this through a planet, which apparently doesn't like SVG. Sadly.

The diagram is simple, and that's a really good thing. Here we're seeing a IM message coming in. The notification disappears into the messaging icon and the message can be found underneath that icon. Nothing complex, but it allows the user to know that all of their messages are a single tidy place and there is only one graphic required on the panel for all messaging.

What is a message? It's really easy to over reach with the idea of what a message is. One could say: "Apparmor is messaging me that I can't edit that file." While that sentence is correct, it's important to note that users don't agree. So my goal is limit this indicator to messages sent from other humans to the human using the computer. Now I need to go and fight some feature creep.

Syndicated 2008-12-12 01:01:00 from TedBlog

Saving the world one uW at a time

I'm here at UDS and joined a session between the kernel and desktop teams talking about power. Like all of such sessions the kernel team thinks that the desktop should fix all the problems and vice versa. At their suggestion, I took an action item.

One of the features of GTK+ is that it provides two timeout functions: gtk_timeout_add and gtk_timeout_add_seconds. The difference is much more important than not having to add a "* 1000" in one and not the other. The important thing that the second function does is that it tried to group wake-ups to ensure that the program wakes up as little as possible. This is never perfect, but it's a small thing that can help to save some power and reduce the number of wake-ups.

So I looked through the Ubuntu main archive to figure out how many applications use the more precise function, but just pass in several seconds as the parameter. I figured this would be a few apps, and I'd submit a couple patches, then I could go back to blaming the kernel team for all our problems. There are more than a couple packages. There are a lot of packages. The results of the grep and a cleaned up list of packages that are likely to have easy fixes.

I realize now that I can't do this by myself, the only hope is to document how to fix it.

So if you'd like to help save a little power on your machine, follow these instructions.

  1. Take one of the packages in the list above and find it in the package repository (instructions).
  2. Branch it:
    $ bzr branch http://package-import.ubuntu.com/x/xproject/jaunty localfix
  3. Find the instances that might be causing the problem.
    $ rgrep timeout_add *
  4. Commit and build a package:
    $ bzr commit -m "Saving the world"
    $ dch -i
    $ debuild
  5. Test it on your system, make sure things still work reasonably.
  6. Generate a patch:
    $ bzr diff -r ancestor:
  7. Submit it upstream!

Syndicated 2008-12-10 20:28:00 from TedBlog

Right side status

Updated FUSA menu with session management and status

We started with a mock up and an idea of how we wanted to redesign the fast-user switching applet. The goal was to integrate in session management and IM status into the applet and put it into a prime location in the default desktop. Now we have code an screenshots to show the work. It's not perfect yet, but we're very happy with where it is. You can grab test versions either for Hardy or Intrepid in my PPA.

We used the old FUSA applet to base our code on as we're using GDM 2.20 in Ubuntu. In this case there isn't much of a reason to merge upstream but to make things easier if upstream wanted our patch, or for other people to use the code, I've split out the various functionality into a set of Bazaar branches. Each one represents a patch that we're including. The patches are:

  • ltsp_client is an older patch that we've had in Ubuntu for a while, but now updated. It disables switching to the login screen on LTSP clients.
  • guest_account is a patch that connects to the GDM patches that are currently in Intrepid to add a guest account. This is an unprivileged account that you can switch to when you hand your laptop to a friend.
  • session_management adds all of the session management commands to user switching menu.
  • fusa_menu_changes includes the changes to the basic user switching menu items. This includes removing the check boxes and the icons and also includes the 'conflict mode' where if two names that are the same adds the username.
  • status_icons is a theft of the Empathy icons. But since we're not making Empathy the default IM client, I had to steal them. They're uuencoded so that this can be a patch.
  • show_status is the code that connects to and shows the status information from an IM client whether it is Empathy and Pidgin. It also allows for setting status in those clients.

Keeping track all of these is a little bit of a trick. But, if you want to generate the patches from Bazaar branches you can use this little shell script that I wrote.

Syndicated 2008-09-18 14:54:00 from TedBlog

Nature isn't straight

As hurricane Ike is coming closer to my house than I'd like, I've been watching the predicted path maps on the National Weather Service's homepage. What bugs me is that there are straight lines between all the points. How silly is that? Nature never moves in straight lines, so I had to make my own map.

Hurricane Ike map with spiro prediction

What I did was take the map and then place a path over it using the spiro splines live path effect in Inkscape. Spiro splines are amazingly natural, and so I figured they'd work very well here also. I like the results, and it seems just from looking at it, to make more sense as a path for the hurricane. Perhaps they should use Inkscape at the National Weather Center?

Syndicated 2008-09-11 19:10:00 from TedBlog

Location, Location, Location

It's said that in real estate the most important thing is the location, and that's also true when thinking of screen real estate. How big something is and where it's located is tied closely to how useful it is.

Logout button in the upper right corner of the current Ubuntu desktop

The point is accentuated when it comes to the corners of the screen. These four precious areas are very easy to mouse to, making them very quick for oft used items. In the current Ubuntu default desktop we've chosen to give the upper right hand corner to bringing up the logout/power dialog. While this is a good use, I think we can do better.

Adding IM status and fast user switching to the right hand corner of the desktop

One of the problems with that solution is that we're using a whole corner for basically only one function. While it's an important function (turns out the center of the Earth isn't oil) it would be nice if we could put more functionality into that location.

The functionality that we're looking at putting into that corner is managing your IM status. Almost every user I see today is using some form of messaging client. If we look to optimize the interactions with instant messaging we're likely to see productivity gains for large numbers of users.

The other piece of functionality that we'd like to put on the same menu is fast user switching. This is a very handy function, but it is directly related to logging in and logging out. In many ways it is similar to "Pause session."

All in all, the better use we can make of our corners, the more efficient we make our users. If we have users that are 100 times more productive, even if we only have 5% of users, we can rule the world!

This update may or may not make users 100 times more productive, it hasn't been tested so it might, we just don't know. Remember, numbers never lie.

Syndicated 2008-07-31 00:10:00 from TedBlog

Ubuntu Desktop Technologies at OSCON

I gave my talk about Ubuntu Desktop Technologies at OSCON, and the slides are all online. You can get the source here or follow the pretty picture bellow to get to the binaries:

Ubuntu Desktop Technologies slides, title slide

Overall the talk was well received. Many people liked the slides especially, and I loved being able to say that they were both done and Inkscape, and use features that Illustrator doesn't support.

A comment that Miguel made is that I should have called it "GNOME Desktop Technologies" instead of "Ubuntu Desktop Technologies." He followed that with "perhaps I should only talk about Mono on SuSE." While it makes me laugh to think how many people would be happy with him doing that, he does make a good point. There are a few reasons that I titled the talk the way that I did:

  • One of the technologies that I highlighted is Telepathy which isn't yet a GNOME technology. I hope that it will be soon, but it currently isn't.
  • I also talked about DBus which is more of a GNOME dependency rather than a GNOME technology.
  • The number of people that come up to me, want to help with Ubuntu and are surprised when I mention they could work on GNOME. No seriously.
  • The talk was originally scheduled for Ubuntu Live, and then migrated to OSCON.

The third point there always befuddles me. But I'm learning to deal with it. Since the talk was targeted to new users and developers, I wanted to draw as many of them as I possibly could. Using the "Ubuntu" name seems to do that better than the "GNOME" name today, for better or worse. A new contributor is a good thing no matter what project name draws them in. As Ubuntu, we need to always ensure that we continue to inform people of our roots even though they seem plainly obvious to us.

Syndicated 2008-07-30 19:36:00 from TedBlog

Bazaar Power Management

When I saw Robert's interesting and fun Bazaar search plug-in I had a few thoughts:

Wow, that's cool!
It would sure be awesome if I could say that I've written as many Bazaar plugins as Robert this month.
That sounds like work.
Perhaps I can do this with, like, 6 lines of Python.

I've now written a plug-in to provide desktop power management support to Bazaar. You can install it like this:

mkdir -p ~/.bazaar/plugins
bzr branch lp:~ted-gould/+junk/bazaar-power-management ~/.bazaar/plugins/power_management

This hack-ish plug-in uses the initialization of the plug-in to call the DBus interface for power management to inhibit the power manager. It then relies on the fact that the power manager will drop an inhibit request from a client that disconnects from the bus which happens when the process exits. Both are relatively unsupported, and mostly undocumented ways to use the systems, but it works.

Why would you need something like this? Well if your trying to create a repository from a really slow SVN server which takes longer than the sleep timeout of your laptop (not that I've done this) you can end up really wishing your laptop hadn't gone to sleep. Yes, things restart, and you don't loose everything, but you'd really rather your laptop was awake the whole time. With this plug-in your laptop won't go to sleep while Bazaar is running.

The only thing left to consider is: What is Robert going to do to retaliate? 7 lines of Python?

Syndicated 2008-07-04 05:26:00 from TedBlog

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!