Tag Archives: Maemo

www.maemo.org

Glom in Maemo Chinook extras

After much struggling with branch merging and fighting with incompatible scratchbox rootstraps, an alpha version of Glom is now available for Maemo’s new Chinook SDK, in the extras repository. Thanks to Armin and Johannes.

glom_maemo_screenshot.png

Software developers might also be interested in the dependencies that we packaged, in addition to the existing gtkmm and hildon*mm libraries: libglademm, libpq (postgres client), libgda, libgdamm.

I think Glom on Maemo could be very useful for tasks such as

  • Restaurant order-taking
  • Stock taking in warehouses
  • Surveying of property
  • Note-taking for deliveries or checkpoints
  • Portable databases
  • Jack Bauer fighting crime

But so far this is purely a proof of concept. Some work would be needed to make it really useful. For instance,

  • The screenshot shows that there is a huge amount of wasted space. The spacing and padding needs to be reduced to 1 pixel everywhere, and the table title and mode can be removed. We use libglade and don’t want to have a separate .glade file for the two platforms, so maybe a new feature in Glade/libglade could help us.
  • Obviously it shouldn’t say it’s in developer mode. This client-only version can’t even do developer mode.
  • The Details/List tabs and navigation buttons need to go into the menu so they are not seen normally.
  • The treeviews needs to have column headers. Applications must do this explicitly when porting to Maemo because it GTK+ changes the GtkTreeView defaults – this is unnecessary and frustrates people.
  • Entry widgets need the hildon keyboard hints so appropriate on-screen keyboards are used for numeric or text fields, plus auto-capitalization where appropriate.
  • Use hildon widgets such as the time and date widgets (needs modifications to hildon to allow them to be empty (NULL), though these should probably be in GTK+ anyway).
  • Special layouts for the Maemo version. We need to let the developer specify a full layouts for the regular desktop version and a cut-down layout for the handheld version, so he doesn’t need to keep two separate copies of the .glom file.
  • We probably need Mathias’ height-for-width extended layout to make sure that we only have vertical scrollbars, though I think we can fit a lot into the horizontal space, at least in full-screen mode.
  • Keyboard navigation: Make sure that this works well by default and allow the developer to specify a tab sequence.
  • Dealing with loss and reconnection of the network, requesting new connections when necessary, using libconic.
  • Support Maemo’s offline mode and other states (suspend).
  • Avoid excessive network re-connections and duplicate SQL queries
  • Self-hosting of databases. Glom on maemo is currently client-only, though the desktop version has self-hosting by starting its own postgres instances. So at the moment you need a central database server and a constant network connection. It would be nice to allow the database to exist on the handheld itself. We’d probably want to port the client-only version to sqlite, though I suppose we should check postgres’s performance on the internet tablet before dismissing it. Our use of libgda should make it fairly easy to use sqlite if necessary, though some generated SQL will need attention.
  • A simple replication feature. People will often need to add or edit data while offline and then have everything reconciled when they get back to base. This is a complex issue, but I hope we can offer some simple strategies for this which don’t require much human intervention.

I hope Openismus can find funding for that work somewhere.

By the way, Armin is now working on the Windows port.

Update: Here is a new screenshot after making some of the easiest small changes:
Glom 1.6.6 on Maemo

Some new C++ bindings

We released some extra C++ bindings recently:

gtksourceviewmm-2.0

I updated Dodji’s gtksourceviewmm to wrap the new gtksourceview-2.0 API. Here’s the svn, and the tarball download.

libnotifymm and hildon-notifymm

Johannes Schmid created libnotifymm (svn, tarball) to wrap libnotify, and we also wrapped Maemo’s hildon-notify, though there’s no documentation to say what this does beyond regular libnotify. I suspect that Maemo should just use a port of libnotify without requiring use of special API.

There are lots of examples in the libnotifymm source code. It seems quite simple, and particularly useful for code that uses Gtk::StatusIcon.

Work on Modest and C++ for Maemo

Some public statements allow me to now mention some work I’ve been doing recently for Openismus, for Nokia, though the heavy cloak of secrecy still hangs over many Nokia things by default.

Maemo Modest

Since Nokia’s Dirk-Jan Binnema talked about Maemo’s new Modest email-client at the GNOME conference (his slides), I can mention that some of the Openismus people (myself, Armin Burgmeier, Johannes Schmid, and Christian Kellner) have been working on this project quite intensively since May 2007. It consumes most of my time at the moment.

Modest is an email client for the Nokia Internet Tablet that’s actually usable, meaning it can handle real world amounts of email, via both POP and IMAP, and it has presets that make it easy to set it up to use many common email accounts, such as Yahoo and Gmail. If we can get everything done (Nokia’s quality requirements are sensibly high) then this will be used by a lot of people.

It uses Tinymail, which uses Evolution’s camel code, so we obviously get most of the functionality that Evolution has, without using Evolution’s UI, but everything is much faster and responsive. It is by far the best way that I can imagine to write an email client now, not that there’s a lot of competition. I say that even though I think that tinymail is currently not a lot more than a glorified wrapper for camel. It’s just that it’s a very good wrapper. Good APIs cause applications to be better and save developers time. It will get really interesting when there’s a future version that can use something other than camel. Philip Van Hoof knows the Tinymail and camel code very well and is incredibly responsive to our needs. While I might be up all night worrying about a problem, Philip has usually been up all night fixing it properly.

We’ve made some small but significant changes to tinymail’s version of camel (camel-lite) – a big investment of time. I think that Evolution should be ported to our camel-lite in the near future, to get some improved stability (general fixes and better thread locking to avoid intermittent hangs and crashes) and improved error codes (allowing better error messages), and obviously to get the performance improvements (though a one-time cache upgrade would be needed, I think). That would be useful even if they never decide to use Tinymail, which they probably should do too one day.

Maemo C++

The updated C++ bindings for Maemo, which I mentioned recently, will be released and supported by Nokia (with help from Openismus) as part of their regular SDK. This means that people can feel safe about using C++ and gtkmm to develop Maemo applications, should C++ be their programming language of choice.

Maemo Chinook/Sardine C++ bindings

I’ve updated the C++ gtkmm bindings for Maemo for the unstable Chinook/Sardine release, which will one day become the new stable Maemo release. That’s hildonmm (previously hildon-libsmm) and hildon-fmmm.

Some links:

If you are running Maemo Sardine then you can add the extras repository by adding these lines to your /etc/apt/sources.list:

deb http://repository.maemo.org/extras/ sardine free

deb-src http://repository.maemo.org/extras/ sardine free

and then install them like so:

fakeroot apt-get install libhildonmm-dev libhildon-fmmm-dev

Packages are only available for the x86 target for now, but I’ll create ARM packages fairly soon.

Feedback is welcome. Add a comment here, please, because there doesn’t seem to be any bug-tracker for Maemo extras projects.

Maemo Chinook alpha and Sardine extras

A few days ago Nokia released a Maemo 4.0 “Chinook” alpha SDK, as a preview of the next stable Maemo release, which will be released at an unknown time in the future. It’s basically the easy way to get a Maemo Sardine scratchbox target set up.

Sardine is the Maemo version that is always the latest work in progress, but it’s generally been difficult to install because it required an upgrade from the stable version, and tended to break quite often. But now that it’s easier for people to start using Sardine maybe it will become more stable.

It doesn’t have the closed-source applications, so there isn’t much to see. It’s just meant to help people port their applications to the new platform.

Maemo Sardine as of August 2007

But for developers there are big improvements. If you have ported software to Maemo then you should be testing with this new SDK now. We finally have GTK+ 2.10 instead of ancient GTK+ 2.6, and there are no longer eccentric API-breaking changes to GTK+, thanks to a shot of sanity from Maemo developers like Lucas Rocha. Most of the good stuff has been cleaned up and is already upstream in GTK+ itself, I believe. hildon-libs is now hildon-1 and has had much of the irrelevant crap removed, so it’s easier to see what is useful.

We can now also upload “extras” packages for Sardine, so our software can be ready for Maemo Chinook on the day that it’s released. I’ve already uploaded gtkmm and I’m working on the updated C++ bindings for hildon-1, hildon-fm, and friends.

Scratchbox Moving Target

I use Scratchbox a lot to do embedded GNOME and Maemo development work. When it works its wonderful, compared to all the other crappy embedded development environments I’ve had to use. But scratchbox is rather fragile.

There’s a lot of theoretical things to discuss about Scratchbox and alternatives, usually mentioning OpenEmbedded. I don’t bother with that discussion for now- life is complicated enough. But life would be a lot easier if they just got some basic things right – at least that would reduce the set of possible causes of the other problems. This is like a case study in apparently poorly maintained software:

  • Bad names and version numbers: (edited due to my understandably confused wrongness. In fact I should remove this point really.) There’s Scratchbox 0.9.8 and there’s Scratchbox “Apophis” version 1.0.1 … 1.0.8 (though the early ones were not considered stable, I think). There’s a Scratchbox 2 (not obviously unstable, but probably so), at a separate web site.
  • Unstable API/feature-list: Between 1.0.7 and 1.0.8, the devkits changed name (“debian” was removed and “debian-etch”/”debian-sarge”, and “maemo3-debian” and “maemo3-tools” were added). This breaks any instructions and scripts that used the old devkit names.

Please be like GNOME: Don’t use even minor version numbers for unstable releases, and don’t change or add features or API without increasing the minor version number. Sometimes it means more work for you, but it makes life easier for users.

And when each new micro release doesn’t risk destroying something, you can finally get this thing into the regular Debian and Ubuntu repositories, instead of maintaining your own Debian packages and producing various eccentric forks.

They maybe had their reasons for both of these messes, but I doubt it was worth it and, on the evidence, I’m sceptical that they understand the problem.

ABI Stability of C++ Libraries

ABI Stability Is Difficult

It’s easy to break the ABI of a C++ class. Just add a new member variable to a public class or add a member variable to an implementation class that’s used a a member instance in a public class. C has the same problem, though it’s not quite as bad because they tend to use pointers more rather than member instances.

I have mostly had the luxury of working in these two situations:

  • The code is used by a closed group of people, who expect to rebuild their entire set of software often.
  • The code is open source, even during its development, so the API and ABI can become quite mature before it is declared ABI stable. However, there are still things that I wish I could change now.

But what if it’s a toolkit whose first public version will be released as ABI-stable?

Pimpl?

Pimpl is the only real solution that I know of. You use an opaque pointer as a member variable. The class to which the pointer points is not fully defined in the header. For instance:

class PrivateThing;

class Something
{
   ...

private:
  PrivateThing* m_priv;
};

The instance of PrivateThing is then created in the Something constructor.

This has some disadvantages:

  • It requires more runtime allocation of memory, in more pieces, which is slow.
    However, I wonder whether this is significant in the average application, given that the public class is probably a member of something that’s allocated dynamically anyway.
  • It causes a slight slowdown, because an extra dereference is necessary whenever the member data is accessed.
    This might not be significant.
  • It makes the code less easy to read, and adds repetitive code to each class method.
  • You cannot provide protected (rather than private) members for use in derived classes while simultaneously hiding those members.
    Many would say this is a good thing. I would probably make m_priv protected though, so that derived classes in the toolkit itself can access members directly, with their knowledge of its definition, while preventing use from applications.

I am fairly confident that this is the best solution, particularly as it’s equivalent to what GTK+ does in C. But please do comment if you have opinions or alternatives.

Openismus at FOSTEL

The FOSTEL Telephony summit looks to be shaping up well, for Wednesday 4th and Thursday 5th April 2007 in Paris. I am consistently impressed with Dave Neary’s ability to get stuff done. Thanks, Dave.

Unfortunately I don’t have time to attend myself, but Openismus is sending Armin Burgmeier, mostly so he can represent his Gobby collaborative editing project. I know he has plans for a more generic next-generation version, even using plain C this time, so make sure you make a full-duplex connection with him.

Openismus is growing gradually, but I’m being very careful about the money stuff so that we don’t stumble. Therefore our expenses budget is not overflowing at the moment, and this is the first time time we’ve sent someone other than me to a conference. To justify it, Armin is under strict instructions to repeatedly say “By the way, Openismus does paid software development” and variations on that theme. It’s not his fault.

Nokia’s N800 “Canola” media player

Here are some of my thoughts after trying the latest beta version of Canola. The smooth über-simple UI very nearly turns the N800 into a home internet media player, but falls slightly short. If it was open source then it would get there sooner. If Canola doesn’t then someone else will first, which would be a waste of the developers’ hard work.

Installation

This is great. Just open a link from the browser and the thing is installed after a few straightforward button clicks. It seems that Maemo supports .INSTALL files, offering to add a line to the apt-get sources.list file, and then using it to install the specified package. Well done, someone.

Separate configuration

Canola can use UPnP and Dmap (part of DAAP, I think) servers to get shared audio and video from your PC or media server device. I think this concept has encouraged the developers to take the client/server idea a bit too far. So there is a separate Canola Configuration menu item, which starts a web page which connects to a local web server. There’s no reason for this to be a web UI, and no reason for it to be a separate application, interrupting the user experience. It’s an implementation detail that has been exposed to the user unnecessarily. For instance, there’s no good reason that I should have to use a web page to change Canola’s UI theme. If the developers want to get and set application configuration via a local http service then that’s fine, but it doesn’t need to be exposed to the user via a web UI. This is architecture astronautism at the expense of user experience.

The same goes for radio stations and podcasts. Please let me choose them from a list or wizard via the regular UI. At the moment they are even hidden under a “plugins” section in the web UI. Give me instant gratification now, please.

Too many clicks

I can’t click on things as soon as I see them. The simple menu is nice, but quickly annoying for one reason: To select something I have to scroll with the arrows until the item is in the selection rectangle and then click it. I should be able to click it as soon as it comes on screen, as I keep trying to do. Then the selected-item rectangle would be meaningless and could be removed.

It would also be nice if I could scroll with a sweep gesture, as I can in the browser. Trying to do this causes me to accidentally select one of the horizontal icons when my stylus touches it.

When I select an “iRadio” station, it should start playing. Don’t make me click the play button too.

Bugs

Something is causing the list of radio stations under each category to be different each time I open the category. I think it’s doubling the list each time.

Media Server

I haven’t tested the Shared Audio and Shared Video features. What upnp server should I use on Ubuntu? The Canola web-page recommends Twonky, which seems to be proprietary.

Scratchbox on Ubuntu Feisty

I’m using a dodgy fork of Scratchbox 0.9.8 so I can use apt-get through https instead of http, but the following tips should be relevant for the regular Scratchbox 1.0.x that I’d rather be using.

  • Make sh point to bash instead of dash (probably not necessary for Scratchbox 1.0.newenough):
    sudo rm /bin/sh
    sudo ln -s bash /bin/sh
  • Install linux-image-2.6.20-6-generic and boot from it. You’ll probably need to press Esc when booting to see the boot menu. This vdso bug might be fixed in Ubuntu’s linux-image-2-6.20-10 soon.
    If you don’t do this then you’ll see this error after logging in:
    Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso’ failed!
  • If you see this error while installing some packages, such as docbook-utils,
    ERROR: ld.so: object ‘/usr/lib/libfakeroot/libfakeroot-tcp.so.0’ from LD_PRELOAD cannot be preloaded: ignored.
    then fix your fakeroot like so, while logged in:
    sbox-config –copy-libfakeroot
  • Update: You’ll need to correct the hosts line in your /scratchbox/etc/nsswitch.conf file, so that apt-get can resolve domain names (wget will work without this, which is confusing).
  • Update2: That nsswitch.conf corrections seems to still be necessary with Ubuntu Gutsy and the latest Scratchbox version (as of July 29th 2007).

Ross Burton helped me with most of this. Thanks, Ross