Sunday, January 30th, 2011 at 10:42 pm by Benny

In the previous post I explained my intentions and the technology I choose to try some things. In short, the aim is to see how best the core of Gramps can be reused to create a mobile interface.

For people who track the development code (trunk), you can see this experimental interface by running Gramps with the –qml flag, eg in the main code directory:

python src/gramps.py –qml

Edit: You need to install python-pyside for this to work.

You are greeted by a screen that allows selection of a family tree, and creation of a new family tree:

The difference with a normal desktop list is that in a mobile interface rows expand to see details, and allows interaction. In this case it shows the last access date and allows to rename by typing something different (enter to store it). It looks like this:

On opening a family tree, a central view is offered that allows several interactions. At least, that is the intention. For now, it only offers to open the list of all people. This list is just a simple list:

Not visible is the nice kinetic scrolling. Not very usefull yet, as you eg cannot go back to the family tree selector, but a good first try.

So, what have we learned? As a nerd it is always nice to experiment with new techniques. And this is quite a different way of doing things. My main observations:

• There are no controls yet in QML. So one has to design everything. It seems one needs some website designers as QML is much like javascript. A programmer offers functionality, and a designer makes a nice interface. It took me quite a lot of effort doing the simple layout you see here. Let’s hope experience makes it easier.
• There are not many controls, eg, if you want a checkbox, you need to create one with rectangles and images! This should improve with QML components in the future, but licensing of these is not clear yet. Eg Colibri is really nice but has a strange license, and Nokia is creating Meego controls but they are not yet be distributable (but probably will be LGPL, so usable once Meego is released).
• The experimental interface shows how Grramps code can be reused to quickly do things: encapsulate objects to show in QML, callback to update data (like the family tree name), … . So, once you succeed in creating an interface that looks nice, everything is available to make it quickly work.
• A small screen is …. wel small. There is a huge amount of functionality you might want to cram in it. Not easy to decide what is important, what to leave in, what to leave out, and how to offer the functionality without the interface becoming cluttered.

What now? Well, let’s see what others think of this experiment. Many ideas on how to go forward, but probably good to first make sure the fundaments are good: how to go back a screen, how to switch screens, how to give the central view a meaningfull layout, … . My idea to go forward would be

• build out the person view so it becomes usable. A find bottombar? Expand a row on click to show all overview? Edit data on screen or a details button for a new screen?
• factor our reusable components. Eg, a class like the base class for all windows in normal GTK
• create a gui.core where pieces of current gui can be stored that do not need the GTK component. Eg, the person list uses the nodemap of the basemodels, but loading that means loading the GTK part that is part of the same file.