Uncategorized

Developing python for maemo 5

I wrote before about my little attempt to write a basic twitter client for the n810 and n900.It now has it's own page here on my blog.

It has come on a long way in a fairly short space of time. It still doesn't support OAuth, and it's still a monolithic app rather than a nicely engineered one.

But I did switch to doing the UI using glade. This is ok, and makes some things faster to do. However, on maemo there are some customizations not available through glade. So I have to reparaent the objects under the hildon window. And attatch other things like 'pannable area' from code.

You get objects that were defined in your glade file by loading the file, then reading in the widgets

self.gladefile = "/usr/share/witter/witter.glade"
self.wTree = gtk.glade.XML(self.gladefile)
self.vbox = self.wTree.get_widget("vbox1")
self.vbox.reparent(self.window)

So basically this lets you create most ui elements in glade, then ignore the window level stuff, and just attatch the top level object to the hildon window.

Some things are really cool and easy. Dialogs automatically look swishy sliding in and out. Using pannable area instead of scrolledwindow gives you kinetic fingerscrolling for free. it's as simple as getting one:

pannedWindow = hildon.PannableArea()

which you then load stuff into which will scroll. in my case I just pack it with my tree view.

Some things are a real pain...you would not believe how long it took me to get it to launch properly from the application menu. It should be easy, but no. There are some files you have to create and when I followed the example I could not get anything to launch. And most frustratingly it gives you zero feedback, no error message, no log you can check. Eventually I tried deleting X-Osso entiries from my .deskop file and things seemed to work. Then they stopped working, and I went round the houses trying everything again. Then I removed the entries again and it seems to work...maybe with a log it would have been obvious I'd made a silly mistake somewhere along the line. It seems ok at the moment, but that one problem really slowed me up and curbed my enthusiasm. I felt I could no continue until I'd resolved this basic problem, but it's not fun spending time blocked on something so basic.

I learned how to use 'pango' markup in order to output text with colours and sizes. It's basically a subset of html as far as I can see. This let me make better use of screen space. By making the text clearer with blue screen_names, and small text for timestamps.

Basically you define a tree view column like this:

self.tvctweet = gtk.TreeViewColumn('Pango Markup', cell, markup=2)

That number in the markup= is actually the column in the liststore that is used for the data. This threw me for a bit because I had previously used

self.tvctweet.add_attribute(cell, 'text',2)

but that seemingly had no effect any more. Then the text in that liststore can have markup like


<span foreground="blue">blue text</span>

This is nice because you get to have rich text, which makes things look much nicer.

Another aspect of making the UI nicer was adopting the fremantle style for the main menu. this is done with:

menu = hildon.AppMenu()

the weird thing is that this take buttons, not menu items. I guess I'm surprised that it's not just a case of hiding most of the differences from you. But I had to re-write the whole menu building method to do this for every menu entry

        GetTweets = hildon.GtkButton(gtk.HILDON_SIZE_AUTO)
        command_id = "Get Tweets"
        GetTweets.set_label(command_id)
        # Attach callback to clicked signal
        GetTweets.connect("clicked", self.getTweets)
        menu.append(GetTweets)

I also added a whole bunch of views. Opening up Mentions/direct messages/trends/search/public/friends. These are all minor variation on the main timeline. I'm sure i could have structured it in a more clever way. But whilst I'm figuring things out I basically copy-paste-modify to achieve each function. I hit on a model of just switching the liststore of data underneath the treeview for each view. Then checking which one is currently there in order to make buttons like refresh do the right thing.

I personally prefer this to opening separate windows for each view. I've seen a few comments along the lines that it is not a very user friendly app. Which has got me thinking about what that means. My main goal in creating the app has been to have very few clicks to get to any function. I consider this friendly to *me* as a user. but that does mean that there are things that work a certain way which if you don't 'know' that's how it is, then it's really not obvious. For instance, in the search view, I just reuse the text entry field and the 'refresh' button so if you enter text and hit refresh it will use that text to perform the search.

The advantage for me is that it doesn't involve messing with the visible buttons dynamically as you switch views, and no extra pop-ups to go through. The disadvantage is that it's really not at all obvious.

Similarly, to twitpic, you just enter the comment you want with it in the entry field, then go to menu and twitpic. and when you hit the 'twitPic' button it will upload the image with the comment. Again, easy for me, not so obvious for anyone else.

So, at some point I may have to make a decision, do I try to make it nicer for the average user? or do I stubbornly stick to it being cryptic but with low click-to-function counts.

One last thing I've found is that the more I take advantage of fremantle stuff, the less I can be bothered to maintain an n810 version. I guess if people explicitly want it, then I can probably update the n810 version with some of the new stuff. But I probably won't do so for just myself, since I don't really use my n810 any more.

I have found that whilst alot of information does exist, particularly on maemo.org around developing etc. there are a number of things that aren't that obvious. It took me a while to figure out the autobuilder stuff, and more specifically it took me a while to understand how to 'promote' from extras-devel to extras-testing. the instructions all appeared to reach a dead end. they said you could do it via the packages interface. what took me a while to realise was that I had to explicitly click on a particular version of my project, and then I'd get the option to promote it.

The next thing I need to do is make a better job of the application icon. At the moment it was a *very* rushed job in gimp to just write a W in yellow with a drop shadow. I'm tempted to keep the icon as a W, but maybe see if I can make a nicer looking version. At least until I think of the next interesting feature to add. I suppose I can always go back to the dreaded OAuth support ...