Gramps Mobile Interface – part I
As technology geeks, the programmers of Gramps have watched the developments in the smartphone world with anticipation. The iphone, android phones and recently WP7 phones show a new way of being connected and getting some work done on the move. This year, tablets will probably explode as the new computing device to have.
It seems clear that the ‘old’ way of working, using a laptop or desktop pc with a keyboard, will not go away for the professional hobbyists needing to get work done. It is just as clear that this ‘large’ pc will be complemented with a smartphone and/or tablet.
So where does that leave Gramps? Unfortunately the phone OS makers have not chosen the PC model to create their phones, but instead have chosen for specific tools one has to use to deliver an application to the phone. In the PC world, you can use whatever you want and ship it to the users computer, in the smartphone world you need to use or Apple’s SDK, or some sort of Java (Android), or Silverlight (.Net, MS). This essentially means rewriting your application in these languages, not very attractive for Gramps as you need to enlarge the skill sets of the contributors, and cannot just reuse the things that are working great in Gramps.
There is however a fourth way I am investigating. Nokia has the N900 device on the market, and probably will release a Meego phone in the near future. These phones follow the PC model, so they allow different tools to be used in order to create an application. One of these is python, the tool used to create Gramps, so the same developers can work on it and can reuse large part of the logic as written for Gramps. (Note that if you ‘root’ an Android device, you can do this too, but probably not many people will want to do this, and, moreover, the phone makers might not allow you to do it (eg Motorola)) (also note that Bada OS from Samsung might also allow python).
So, it seems that for now our only hope of leveraging the Gramps code to quickly make a mobile app would be to aim for the Meego platform. We still need to decide on the widget toolset then however. On one hand there is Gtk-Clutter, on the other Qt. As Gramps is now using Gtk for the visual elements, Gtk-Clutter seems like the best choice, but as we have to rewrite the user interface anyway, and because Qt is the official way that Nokia sponsors, my guess now is that it is best to aim for a Qt interface. This is just my feeling based on my experience, don’t search anything behind it.
It is hard however to choose a winning platform. Choosing the wrong technical basis means redoing things when a project is abandoned. For example, we also have to choose which python bindings to choose so as to talk with QT. There are two, PyQt and PySide. As PySide is the official Nokia sponsered bindings, it seems safe to assume they will keep it current and have it installed (or easily installable) on whatever device they might ship in the future. So my choice would be PySide.
So, if we do a try to create a Gramps Mobile Interface to use on a touch interface, it now seems our best bet is to go for core components: python, Qt and PySide. This should allow us to reuse all the logic present in Gramps, and just put it in a new jacket to show on a mobile interface. And who knows, perhaps somebody can do a tablet interface going from there?
One thing is certain, as Gramps ships as one big component at the moment, it will have to be part of Gramps. If this succeeds, we will have to split up Gramps, so that we can install separately gramps.gen, gramps.core, gramps.gui. This new component will then require gramps.gen and gramps.core, and not gramps.gui which has the GTK requirement. But those are dreams for the future!
In part II I’ll show what my first experiments with this are leading to.