Older blog entries for dobey (starting at number 281)

Hacking Launchpad

A couple weeks ago, I wrote a quick hack for myself and the Online Services team at Canonical, to help make doing reviews on all the projects we manage, much easier. It pulls the list of branch merge proposals for each project from Launchpad, and sticks them all in a nice list in a GtkTreeView, along with the number of votes, and what type of vote. As there was a lot of immediate interest in the tool from other people, I ended up creating a new project on Launchpad, and pushing the code to a public branch there, under the GPLv3. You'll find it at http://launchpad.net/lptools. I will probably be adding other tools soon as well, as every time I have to use a web browser, it slows my progress, and interrupts my ideal workflow. If anyone else has tools they'd like to have included here, or ideas for tools, feel free to propose branches which add them, or send me mail.

I'm not a fan of Python. But I chose to write this tool in it anyway, as I wasn't intending to make a real project out of it. It was just a quick hack to make part of my life much easier, until I can get around to writing something much better and more deeply integrated with the desktop. But the GTK+ bindings, and python-launchpadlib, made it very easy to hack this script up very quickly. I do wish there was a better way to do the authentication though. Opening a browser, and requiring the user to press "Enter" in the console, is an awful experience. But it works, and I only have to do it once...

Frankly, launchpadlib makes it very easy to not have to use the web... and in some cases, makes it better, since the Launchpad web UI doesn't expose all the features that are in the API.


Syndicated 2009-08-10 01:39:10 from dobey's blog

Central Services

We do the work, You do the pleasure

Hi there. I want to talk to you about ducts. Do your ducts seem old-fashioned? Out of date? Central Services' new duct designs are now available in hundreds of different colors, to suit your individual taste. Hurry now while stocks last, to your nearest Central Services showroom. Designer colors to suit your demanding taste.

A lot of people have talking about the social desktop, networked services, and similar stories lately. I guess the integration between computers and network services, which I had been talking about over 11 years ago, is finally catching on. Thanks to all the new smartphones, netbooks, and similar devices, designed to be on-line all the time, and the services people are providing for those devices, we're now trying to wedge the same integration into our outdated desktops. And it seems like nobody really wants to do what's best for everyone here. Having all the apps just use the same libraries to access the same data, and parse it separately, and have the user add their account to all the apps N times, just isn't going to make a good or useful experience.

This is where Central Services would come in. I've talked a little bit about it before, to a few people at UDS, and on IRC. I haven't had a lot of time to work on getting the ball rolling though. But I really want to get things going now, so that we can build a really awesome experience in the desktop, around all the services available, and that everyone uses daily. The goal is to provide a central system where all the plug-ins and configuration live. The user would then only have to add their account for any particular service once. The system would also provide transcoding features for data, taking the XML or JSON for example, and converting it to a common format that all the apps which are designed to display the data only have to actually deal with a single, defined, common format. Central Services however, would not be a data store. Rather, it is a central place for accessing your data from wherever it is stored. There would be a small, optimized local cache, perhaps, and we could integrate with indexing solutions, which may store the data, to provide more feature-rich search capabilities in the desktop as well. But the overall goal is to provide a simple, consistent means for accessing and managing your data. I've been thinking a lot about the problem over the years, and I think a modular, centralized system is the best way forward on the desktop with it. I've been trying to think of a nice way to design the API, with a good balance between being generic, yet powerful. The main API access will be via DBus, but there will be some C and Python convenience libraries as well. I'm not entirely sure what the best way to document the API, and get stuff rolling there is, but I'd love some help and feedback with it. If you're interested in making the desktop awesome, and helping define the API, and getting some working code up and out in the wild, please e-mail me and let me know, or poke me on IRC. You can e-mail me at the usual dobey on gnome.org or dobey on wayofthemonkey.com to get my attention.

A common API, accounts interface for users, and cross-service integration all over the desktop would be a huge win for everyone. Let's get together and make it happen.


Syndicated 2009-08-04 02:17:10 from dobey's blog

30 Jul 2009 (updated 30 Jul 2009 at 17:08 UTC) »

The System Is Down

Last night, Stuart and I were having a little argument about the merits of OAuth and whether it is actually suitable for what we are using it for (authenticating destop applications to access a service), as I am not particularly fond of it, and I was working on support for OAuth 1.0a. Stuart's argument is that user's trust the browser, and we need some piece of trust in the system, and OAuth provides that as it pretty much requires a browser to use it. But I don't really think users trust their browser (as so many don't even know what a browser is), but instead, what they trust is the site they're looking at. The browser doesn't even exist. It's just this inherent part of the system that you have to use. To most people it's The Internet, or the giant blue e, or a compass. The browser has no real meaning to them. It's the place they have to go to search for things, and access information. And Humans have two very important attributes. They are both very prone to error, and very resilient. People will keep going to the web, despite all its problems with poorly designed sites, and crashing browsers, and broken plug-ins, because they need to get at the information they're looking for. And they will very often type their password in the wrong place, or mistake a phishing site for a real site. No amount of code will fix this. And nothing that requires a Human to do something will guarantee security and authenticity. It will only create annoyances that Humans will optimize around.

As a specific example. I received a PayPal phishing mail in my Inbox this morning. It's a pretty nifty attempt at getting credit info, too. It includes an HTML form attachment, which POSTs to PHP script that was implanted on http://ag-exchange.com/, presumably by compromising either Apache, PHP, or some other module their server is using. It appears to be a simple script which just reads the POST data, and redirects the user to the PayPal About Us page. The HTML form requires javascript and has a little card number validation method it seems, to avoid getting bad data. The mail was sent to my alias on gnome.org, and apparently got sent by taking advantage of an SMTP relay with a broken configuration. Of course, the SMTP server may have also been compromised and just had the configuration changed to allow open relay as well, but I suspect it was probably just open already. And that mail server belongs to

Syndicated 2009-07-30 15:09:16 (Updated 2009-07-30 17:08:52) from dobey's blog

Things Goin' On

I meant to make an announcement last week, but have been too busy to write up anything... The new version of intltool, 0.41.0 was released last week, with several bug fixes. It's available on Launchpad. This release also gets rid of the long-standing and annoying multi-line quotes warnings in Python files. So get your distros upgraded!

Speaking of annoyances, another one that's be cropping up quite a bit lately, due to the fact that the Ubuntu One client code wants to launch a browser for acquiring an OAuth access token, is how obviously un-usable the Default Applications concept really is in our desktop, as so many people have been filing bugs about the browser failing to launch. And the logs show exactly what's wrong, the configuration is broken, and pointing at an executable or path that no longer exists, and probably hasn't for some time. I'm surprised anything in the desktop can open a browser on these machines. This is of course, because we call the xdg-open script to launch a browser, so that our client will work on all the XDG desktops. Calling the GTK+/GNOME API directly would probably result in a different key being used, and the browser loading fine. I wonder if we can somehow make this better, because having multiple different configuration keys to launch the browser is doomed to fail at some point (which is of course what is happening right now for us).

I'd say something about RMS, but I know a bunch of you would take the time to write me some fiery e-mails. But the Michael Jackson bits in the South Park episode "Mexican Staring Frog of Southern Sri-Lanka" were great.


Syndicated 2009-07-20 20:27:16 from dobey's blog

Tarmac Mini-Sprint

Today we are having a mini-sprint via the ether for Tarmac, the most awesome piece of branch landing code using launchpadlib and bzrlib, to land approved branch merges automatically. Join us in #tarmac on freenode and help us make it even more awesome.


Syndicated 2009-07-10 13:55:11 from dobey's blog

Ubuntu One 0.90.2

We've been in a controlled beta of Ubuntu One now for a little more than a month. Recently, I've been hacking on the client a fair bit, porting our Nautilus extension to C, to avoid the dependency on python-nautilus, and for the extension to perform better, and not slow down desktop start up times by loading up Python. As part of this, the build system for ubuntuone-client was switched over to autotools for most stuff. We still generate a setup.py, and use it to perform a few tasks, but that should be going away soon as well. Keeping it around requires some funky magic in the build system, to pull all the necessary pieces into a release tarball correctly, and get Python pieces installed to the system. But now we have a way to build reproducible tarballs, and should be doing regular releases on Launchpad. You can find them here:

Ubuntu One Storage Protocol

Ubuntu One Client

We encourage people to build packages for their favorite distros as well, and are glad to answer any questions about how things should be packaged. If you have any questions, feel free to come bug us in #ubuntuone on FreeNode (irc.freenode.net). Enjoy!


Syndicated 2009-06-19 04:16:04 from dobey's blog

Pre Tricklet

So, I just got my Pre yesterday, and was messing about with copying some of my more important contacts over (until my new Laptop arrives, and I can use Vista to copy the rest over from my older Win Mobile phone), and noticed that the Pre doesn't save commas in contact entries. After no luck searching through the manual, or with a search of the internets, I ended up calling Sprint's customer support. Apparently, I'm the first person to call about this issue, and so nobody could help really, though it was suggested to possibly call Palm directly. So I went back to do a little searching, and found some references to using the 'p' or 'w' characters to mean pause/wait on other phones. Not exactly the results I was hoping for, but inserting a 'p' does let me store the bit of information I need in the contact entry, and use it in the dialer. It simply does a 'wait for input' type of thing, and appends a button for the next sequence of numbers to dial, which must be manually 'pressed' during the call. At least it will let me still use conference numbers at least somewhat more easily than remembering the PIN myself.


Syndicated 2009-06-08 02:49:03 from dobey's blog

It's a Mock WOrld

Some people like to live in dreams. Others like to live like those dreams can never be real. I like to make them come to life.

I've mentioned in a couple place recently that I'd been working on some mock-ups of a new interface for contacts management. I'm finally posting them here now, and hope I can figure out some of the details for getting it implemented, soon. The idea is to provide a very simple interface, and extra information about a user, which one wouldn't normally find in the address book interface. I also want to get rid of the concept of having sepparate "address books" that you manage separately from your actual contacts, that may even have the same contact in multiple places.

This is the simple list view for the contacts. Not sure what would belong in all the menus, or if it should even have any, yet. The current tool bar items are new contact, return to list view (would be greyed out in the view), and a combo box to filter the list. Filtering would work based on which store the contact is in, tags on the contact, names, status, and all the information assosiated with a contact, so it would pretty much be a "do what i mean" sort of interface. The content associated with the contacts, which ends up in the list view, is also not entirely specified, nor is the context menu which would pop up when right clicking. Opening a contact would use some neat clutter-like animation sequence and bring you to the Contact view:

Not entirely sure what the layout should be like exactly, as some of the things would require scrolling. Probably will just have one scrollbar for the whole canvas, and just overflow vertically where needed. Here the new contact item would be disabled in the toolbar, but I think the filter entry might be still useful, for condensing the information displayed for a contact. Typing "phone" to show only the contact's phone number information, for example. We could display a lot of information for a contact here, such as RSS feed data, flickr posts, related contacts, and similar things from web services. I want to find a nice balance and show the most pertinent information in the prominent top portion of the canvas though, such as useful free/busy agenda information, basic contact info, status, presence, and contact store locations.

This contacts UI is a small part of a much larger project I've been talking with some other hackers with, to unify the backends, and an access API, for getting at all this information, to really make people and relationships a first class part of the desktop. More news coming soon on that.


Syndicated 2009-05-27 21:36:02 from dobey's blog

Ubuntu One Beta

Ubuntu One is now in a limited public beta. Check it out. There will be lots more awesome stuff on it in the future too.


Syndicated 2009-05-11 23:13:48 from dobey's blog

Moving intltool

After a short discussion, Danilo and I have agreed that moving intltool to Launchpad would be better for the project, and us, as its maintainers. The project is not specific to GNOME, and we would like to encourage non-GNOME projects to adopt it for use by their translators. All future development will take place in the LP project, with Danilo and myself as its continuing maintainers. Please report any new bugs or requests in the bug tracker on Launchpad. I will be sending a mail shortly to the appropriate GNOME lists, with some more details soon. If you have any questions about how this will affect you, feel free to e-mail me or ping me on IRC.


Syndicated 2009-04-08 17:56:16 from dobey's blog

272 older entries...

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!