Category: maemo

My thanks to the GUADEC organisers

I thought I would walk to the Collabora party from the conference.  It was four miles, a pleasant walk.  On the way I had to stop to write a sonnet.

If anything should happen to The Hague,
if someday they abandon Amsterdam,
philosophers will take these strange and vague
descriptions, and derive each tree and tram
by mathematical necessity:
should nations shake their fists across the seas
with words of war, it follows there must be
a middle ground, a people loving peace.
And is this scrap alone a netherland?
Not so: we spend our nights beneath the sky,
and every country’s low for us, who stand
a thousand miles below the lights on high;
if only I could learn to live as such,
and count myself as kindly as the Dutch.

I passed the Palace of Justice on the way, which is very beautiful. Collabora’s party was as impressive as always, with barbecues and beer. This morning I managed to pull myself out of the resulting hangover enough to give part of a talk on xzibit. (It was really Guillaume’s talk, but he was kind enough to give me a timeslice.) The talk went well except that the demo failed, due to my having tried to fix something and breaking it further. There will presumably be video of it all at some point.

Many thanks to Collabora for organising the party, but still more for sending me here (and to Cambridge).

I have written a nautilus plugin to post photos online. I might tidy it up a little and package it.

The MeeGo book is fast approaching publication. It feels like levelling up.

Reviewers

Yesterday, sitting on a beach in New Jersey, I wrote the final chapter of the first draft of the book on MeeGo on which I’ve been working since a little before Christmas.

There’s still a fair amount of redrafting to do, but it’s mostly in the bag now.

I’m sorry that patch review has suffered during this time. I will be starting to tackle the backlog now.

My editor tells me that we need reviewers. The book is about Qt on Python under MeeGo. If you know about this and would like to review, please let me know (thomas at thurman.org.uk). Apparently reviewers don’t get paid but do get their names in the book.

I shall let you know when the book gets published.

Working on a book

If I’ve seemed rather busy recently, it’s because I’ve been working on a book for Packt. It will be a “cookbook” of ways to solve problems on MeeGo using Python and Qt. It started out as an N900-specific book, but it’s grown in the telling.


How to place a phone call

(Of course, until a version of MeeGo with a GUI goes public, I’m testing everything on the N900.)

I’m enjoying writing it immensely. It should be out sometime around the autumn.

Using the Shavian alphabet on the N900

For a while I’ve wanted to take notes in the Shavian alphabet on my N900.  The other night I finally got around to putting in Shavian support. It was a whole lot easier than I’d imagined: about ten minutes’ work, and as so often I’m rather impressed at how flexible Maemo is. This post was enormously helpful.

You can switch alphabets using the system menu; excuse the dreadful antialiasing on the icon I whipped up in a few seconds. When you’re typing in Shavian, the Fn (bluearrow) key will let you type in the Latin alphabet briefly.

And the notes application (and Conboy) don’t have any problem with the non-BMP codepoints needed.

I would package this, but I’m not sure it would be useful to anyone but me. On the other hand, it might be helpful for other people who wanted to know how to do something similar.

BBC Micro

In unrelated news, last night I packaged the Maemo port of Beebem which I’ve been talking about for a while.  So if you want to play around with the BBC Micro, go and have a look. Be warned that it’s very, very flaky.

I’d rather like feedback on whether and how well it works for you, and suggestions on how to fix any of the points raised in that post.

Contentment

Brown paper packages tied up with stringsI was having a discussion earlier on IRC about the role of the N900’s App Manager. The question I’m raising is: is it legitimate to package non-programs which can be already downloaded in another way?

Here’s an example.  A film which is DFSG-free such as Sita Sings the Blues could be packaged as an app.  The package would install the .mp4 of the film, which would then appear in Media Player, but perhaps would also have an icon in the launcher.  (Of course people can already find Sita on the web and watch or download it there, giving the same effect, but then they might be more likely to find it in the app launcher.)

Far-fetched?  Not really; there are already iPhone apps which contain only a book, and there are existing Debian packages which only install free HTML and text content.

Since films are essentially documents which can be opened by Media Player, the question can be generalised: Should documents be packaged, or only apps? When someone ports Frotz to the N900, should it have its own separate download manager for Z-machine games inside it as the iPhone port does, or should each game become available in the App Manager as a separate package as used to be done on Debian?

And then there are radio stations such as Soma FM which have iPhone apps to let you listen to them.  Now of course you can already do this in the N900’s media player, so would it be worthwhile for them to package a specific N900 app which connected to their streams?  Or to make a package which only populated the media player with a list of them?

But just because people do something with the iPhone it’s not necessarily a good idea:

  • media packages should probably install into /home/user/MyDocs or /media/mmc*, but the conventional place for large files in app packages is /opt, which would fill up quite quickly with a few Sita-sized films
  • each package gets to run scripts as root, and this may have more security considerations than people are comfortable with just to watch a film
  • people expect app stores to contain apps (don’t they?)

I think an alternative route would be to have one standard application which could maintain a browsable list of Free content, and which could download it for you as appropriate.  Maybe it could be extensible to act as a download manager for Free content for the emulators and so on, as well as just films and text.  What do you think of all this?

Photo © Caro’s Lines, cc-by-nc-sa.

Two thoughts about Belltower

I have a Maemo application called Belltower in testing, which lists towers hung for English full-circle change ringing (rather than any tower in the world which happens to contain bells). Here is a screencast of the app in use. The data comes from Dove’s Guide. It allows you to

  • find all towers nearby, using the GPS
  • find a tower by name
  • find a tower by geographical area (country, then county, then alphabetically)
  • bookmark towers and come back to them later

Here are two questions about Belltower on which I’d like your feedback.

1. The front screen currently looks like this:

But I’m wondering whether it would be more Maemo-ish to give it an interface like the app manager and the media player. Something like this (excuse the quick mockup):

What do you think?

2. Generalising Belltower. An application to find belltowers is useful for ringers, but the same code could come in useful in other ways for other people. Eiffel on t.m.o suggested that there should be a wiki which lists sets of geographical points within a particular category, such as

  • belltowers
  • Tube stations
  • public toilets
  • perhaps a chainstore might want a set of points for its own stores
  • stone circles
  • UFO sightings…

which could be fed automatically by sites such as Dove and openstreetmap, or just by people editing the wiki itself. Each point would have

  • a name
  • a short block of HTML giving facts about the point (such as, for a Tube station, which lines it was on)
  • possibly a picture
  • possibly a URL to follow for more information
  • and always a latitude and longitude pair.

Then son-of-Belltower should be able to pull from this wiki with a custom API; the user could select which overlay they were interested in.

I think this idea has a lot of merit. I may do it. I’d like to hear your ideas about it as well.

Writing apps for the N900, part 4– the power of DBus

There is a contents page for all these posts.

Matters arising from last time. Several people have been replying to these posts as if I was the embodiment of the Maemo team. Although I worked on some really interesting parts of the desktop as part of a team from Collabora, I didn’t have anything to do with the package format or anything like that, and I’m writing these posts as an individual (and I welcome corrections). If you want to ask about the rationale behind anything here, there might be people who would know more at talk.maemo.org.

It’s a grand life on the buses. One of the many wonderful things to happen to the free desktop in recent years has been the invention of DBus as the glue to stick it all together; it’s gone a long way towards making Unix not suck.  Maemo sticks together with DBus just as much as GNOME or KDE do, which means we can interact with system services fairly painlessly.  And if we don’t know how to do something, we can always run dbus-monitor, use some other program to do what we wanted to do, and see how it managed.  Then we know what to google for when we’re looking for the official documentation.

Sharing is good. So today we’re going to be adding a “share” button to the app, so that we can tell our friends when we find an interesting link on reddit, and we’re going to be doing it using only a DBus client. Adding the entry to the menu is pretty trivial:

Selector with the 'share' item added

Now, let’s consider how we might want to share things with people:

  • Microblogging (twitter, identi.ca…): yes, definitely. You can very simply post a message to an account on one of these systems using DBus services provided by a library called microfeed. We’ll add an optional dependency on that library, and assume that people who are using it will already have set it up (using Mauku or something similar).
  • Email: certainly. We can interact with the email subsystem using DBus services provided by modest.
  • IM: yes, but… We could do this by putting up a dialogue from the address book, waiting for them to choose a contact, and then sending the message using Telepathy. But that’s not what we want; what we want is to start a conversation: we want to put up the IM window with the link as a sent message and allow the recipient to respond. I don’t know a good way of doing that, but maybe you do.
  • “Sharing services” usually means file hosting services like share.ovi.com, and isn’t really the sort of thing that concerns us here– even if the link’s to an image, you probably don’t want to upload a second copy of the image to your Ovi account.
  • Bluetooth: probably overkill (do people really send URLs over bluetooth? Apparently they do, actually, so maybe we’ll add that later.)

But let’s stick with microblogging and email for now. I’ve created a rather rough version of this idea as a separate file, sharing.c, in case it could be separately useful to someone else. This brings us up to raeddit-06 (diff to raeddit-05, git cloneable, and available from maemo-extras). When the user taps “Share”, this part of the program will put up another selector listing “Email” and as many microblogging services as it can find:

Sharing selector

Let’s say we choose Twitter; then the message gets posted, and we can go and check it in Mauku or the web browser:

Successful tweet

Behold the power of DBus!

Next time we’ll be adding the ability to view images in-process rather than launching the web browser, and we’ll be learning about a rather wonderful innovation called “stackable windows”.

Writing apps for the N900, part 3 — touch selectors

There is a contents page for all these posts.

Matters arising from last time: There’s been some very helpful feedback:

  • Colin Watson pointed out that debhelper 7 makes building debian/rules files far, far simpler. But Jonny Lamb told us that Maemo doesn’t ship with debhelper 7.
  • A Nokian emailed me to point out that in Maemo 5, application icons should be 48×48, and that 26×26 is from Maemo 4. (26×26 will still work, though, as we saw.)
  • Several people pointed out that the “B” in “XB-Maemo-Icon-26” stands for “binary”.
  • And someone on Reddit said that “raeddit” is not a particularly wonderful name. This is true, and I’m open to better suggestions. I didn’t want to call it “reddit” without asking the reddit admins!

Today we’re going to introduce another new widget which is specific to Maemo.  The program currently opens the target site when you click a link. Last time, we promised to make it put up a menu of possibilities, instead:

Selectors. This is called a HildonTouchSelector, and it pops up (so to speak) all over the place. It can live inside any window, but it also has its own special kind of dialogue called a HildonPickerDialog.  It’s very like a combo box, but much easier to use with your fingers.

You see that the program behind the selector is blurred out: that’s to show that it’s not available. If you were to tap the blurred area, the selector would close without making any choices, and you would return to the rest of the program. You can also see that the switcher button at top left is not blurred: that’s because the selector is only modal, not system-modal. You can’t interact further with this program until you deal with the selector, but you’re free to switch to another program or start a new one.

What do we actually need? Now, before we dive into coding, let’s think about what we need from any representation of one of the lines in the menus.

  • We will need to ask it for the text to appear in the menu.
  • And it should be able to decline to appear in the menu.  For example, “vote up” should only appear if you’re logged in.
  • We will need to ask it to deploy, if it’s chosen.

How could we best implement that?

  • The fairly elegant way would be a set of singleton classes all implementing a common interface.
  • The very elegant way would be a set of DBus services.  That way, third parties could come along and add new menu options.
  • And perhaps we’ll do it the very elegant way later.  But this is a quick and simple tutorial, so…

We’ll use a set of callbacks.

  • Each callback takes a representation of the post, and a boolean– true if we’re preparing, false if we’re deploying– and returns a char*.
  • If we’re preparing, the char* is the name that will appear in the menu, and should be freed by the caller.
  • But if we’re preparing, the callback may also return NULL, to decline to appear in the menu.
  • If we’re deploying, the callback should always return NULL.
  • We promise not to ask a callback to deploy if it returned NULL in the preparation stage.

A small amount of extra work brings us to raeddit-05 (diff to raeddit-04, git cloneable, and available from maemo-extras).  This contains two callbacks: one to visit the actual site, and one to visit the comments page on reddit.  It looks like this:

Selector with two entries

It’s already much more useful this way, but it’s looking a bit bare with only two entries.  Clearly we can’t put in “vote up” or “vote down” until we allow the user to log in. We could easily put in the ability to buy a shirt, but there seem more important things to do first.

For example, every good mobile application needs a “share” button.  So next time we’ll be looking at how to add an entry which lets us IM or email the link to our friends, or post the link to twitter or identi.ca.