New Stuff in OpenMoko (with screenshots)

On the OpenMoko front, I have mainly been doing boring things such as bug fixing the Dialer, Address Book, themes, icons and related framework libraries. On the other hand, Chris has been doing exciting work with cairo, clocks and world maps. Apart from looking cool, these components will be forming the basis of the world clock and stop watch applications, as well as the alarm functions, including alerts from the calendar. Oddly enough, this is one of the most important features for some people. I asked someone what they used their phone for and they reply was “Calling people, sending text messages and waking me up in the morning”. As it happens, I think those are also the functions I use most often on my phone too. I’ve also heard that teenagers are replacing their watch with the mobile phone as a way of telling the time…

screenshot-today-analog-clock.pngscreenshot-world-map.png

One interesting thing I have done recently was to port the original application manager to the new 2007.2 framework. This means you will be able to upgrade and install packages straight from a GUI interface.

screenshot-appmanager-update.pngscreenshot-appmanager-details.png

I also added colour scheme support to the moko-gtk-engine, so it is possible to change the orange to a different colour if you are using this. I also wrote a little application called openmoko-appearance that can be used to set a new colour through a GUI. I’m hoping it will also be a good example application for people getting started in GTK+/OpenMoko programming. Chris has also already added support for changing the background of the home screen to openmoko-appearance too. Openmoko-appearance isn’t quite finished yet, but you should be able to get the general idea…

screenshot-openmoko-appearance-colours.pngscreenshot-openmoko-appearance-background.png

As you can see, the titlebar is not yet updated and the icons look rather out of place. We are going to look at recolouring the icons on the fly, but we need to work round a few issues first, and performance will be a factor.

The Parsing

I’ve been a bit quiet on the theme editing front lately, but I have been making progress. I realised that at some point people are actually going to want to edit existing pixmap themes, so rather than making bold decisions to make creating and editing easier I have decided to concentrate on making something that will be immediately useful. So I sat down and ripped off most of the theme parsing code from the pixbuf engine. I also rearranged the internal data storage of the theme editor to use the same structures as the pixbuf engine. The result is that I can now load and display all the information from an existing theme. There are still a few odd quirks, but when it works it does work…

screenshot-gpte-2.png

I have even added recent files support with a little guidance from Emmanuele (I got tired of navigating to ~/.themes/foo/gtk+-2.0…). Next thing on my to do list is to clean up the source file structure, autotool it and then have a go at creating my own Subversion repository on svn.gnome.org. Of course, that is also dependant on finally picking a name for the project. I liked “Artisan” from the previous suggestions, but I am not sure it has quite the right feel to it. Following the discussion I had about micro branding with Emmanuele, Chris and Rob at work, I now feel obliged to call it something like “ThemeKit” or simply “Theme Editor”, but that may be a little too generic. Seeing how I just announced a proposal for OpenMoko and named it PhoneKit, I could also be accused of being rather unoriginal in my naming.

Two Neo1973s calling each other

Met Will Lai from OpenMoko on Sunday at mobileCampLondon. Gsmd has become much more reliable recently, so we attempted to get two Neo1973s to call each other. Will filmed our experiment for posterity!

If you’re wondering, the Neo1973 on the left is running my new (as yet incomplete) gtk-engine, which is why it has white dialer buttons.

Also met some people developing applications for OpenMoko for the first time. Will filmed a demonstration by John Moore of his thumbtribes project. It would be great to hear about more people developing applications for OpenMoko.

Also found out that the UK was the second highest country for sales of the Neo1973. OpenedHand have several debugging boards, so if you accidentally brick your Neo1973, drop me an e-mail and we can arrange to fix it for you. If anyone is interested, we could even organise a user group for Neo1973 owners in London (and maybe the UK).

(Partial) TV Fame

Apparently, ABC local news did a short story that included the new OpenMoko user interface we at OpenedHand designed and implemented. I guess that’s sort of fame by proxy, as long as you are in the know!

But hot on the heals of the pixmap theme, I’ve already started work implementing a GDK based theme engine for OpenMoko. The main reason being that the Neo1973 lacks an FPU so performance is hit by scaling all the pixmaps. I could use cairo rather than GDK, but unfortunatly cairo performance isn’t much better than the pixmap performance. It’s still in very early stages, but it makes for a much snappier user interface. If anyone has any tips on reducing the banding in the gradients, I’d be interested to hear them (the display on the Neo1973 is only 16bpp).

screenshot-1.pngscreenshot-5.pngscreenshot-4.pngscreenshot-3.pngscreenshot-2.png

libmokoui2 documentation

100% symbol docs coverage.
72 symbols documented.
0 symbols incomplete.
0 not documented.

Hoorah! I’ve just added gtk-doc support to libmokoui2 and completed documentation for the existing widgets. Most importantly, this means you can now browse and search the documentation using devhelp.

libmokoui2 is a set of widgets useful for implementing user interfaces for the OpenMoko platform. We’ve taken a slightly different approach to other UI libraries and rather than create a frame work with lots of abstraction and overhead, we’ve created a light and flexible companion to GTK+ that helps application authors match the OpenMoko style. Keeping the library and style of OpenMoko within the limits of GTK+ has meant that we have kept the learning curve to a minimum and have not had to create nasty hacks and workarounds to implement the design.

The number of widgets and functions in libmokoui2 is currently fairly small. We are only adding widgets and functions once it becomes apparent that multiple applications would take advantage of them. This way we can keep the size of the library down and we will have more experience of the real world application of widgets or functions before they are added. As well as keeping programming overhead down, this approach has also been really successful in keeping our code maintenance and bugs to a minimum, saving on the time and money invested.

OpenMoko Dates – First shots!

In the o-hand tradition of stealing people’s thunder, I present to you the first screenshots of openmoko-dates running on the Neo1973.

screenshot-openmoko-dates-1.png  screenshot-openmoko-dates-2.png  screenshot-openmoko-dates-3.png

Kudos to Chris for getting this major re-factoring working in just a few weeks. We’re still waiting for a few more icons from the OpenMoko designers, but everything apart from the week view is now in place. If you would like to test openmoko-dates yourself (assuming you have a build set up), just run “bitbake openmoko-dates2” then copy and install the resulting ipkg onto your Neo1973.

Confusing Styles

I’ve had to think fairly hard about the UI for my little editor. GTK+ widgets are not as simple as they may seem, and can be fairly inconsistent about how they are drawn. All drawing operations have state parameter and some have a shadow parameter, although not all widgets use the shadow parameter.

Buttons for example, do not use the shadow parameter, and are drawn based solely on the state value (Normal, Prelight, Active, etc). Check boxes use the shadow parameter to determine if the box is ticked (shadow in), un-ticked (shadow out) or inconsistent (etched in). There are five possible states and five possible shadows, so simple maths would tell you that a check box could have up to 25 different images. However, only three of the shadow types and only four of the state types are relevant to the check box, so actually there only 12 possible images for a check box.

On top of this, some widgets are drawn with several drawing operations. For example, the scrollbar is drawn with the box operation (to draw the trough) and the slider operation to draw the slider. So to correctly identify where to use a particular image in your theme, you need to know either two or three values (operation, state and sometimes the shadow). Each of these images for a widget is then combined in a group, called a style, which is applied to particular widgets through a style rule.

Now try applying all this information to a GUI. So far this is what I’ve come up with:

screenshot-gpte-1.png

Many thanks to those who suggested a name for this project. My favourite so far was Neil’s suggestion of “Artisan”. Well done to Tko for guessing the current name correctly!

LinuxWorld London, 2007

There has been some discussion on the gnome-uk list about what we’d like to do at LinuxWorld, London. I’m not going to be organising it this year as having done it for the last few years, I want to give someone else the opportunity. So if you live in or around London and are passionate about GNOME, please consider organising this little event! Just drop an e-mail along to the gnome-uk mailing list to let people know you want to help out.

OpenMoko 2007.2

Sean has made his announcement, so I’ll take a little bit of time to explain what happened.

We (myself and assorted others) at OpenedHand have been working with OpenMoko for the best part of a year now. We have been porting applications such as Contacts and Dates and helping develop new applications and libraries such as the Dialer and libmokojournal (an interface to the journal component of iCal, via ECal in Evolution data server).

About three or four months ago we noticed there was growing concern within the OpenMoko community about the GUI design. We had already noted some of the issues that were being raised, so we had a meeting at OpenedHand and discussed all the various problems and design issues and came up with some possible solutions.

Problems:

layout_stylus_template.png
Old style UI
  • The theme was over complicated and caused serious performance problems. We had already looked into various patches and workarounds, but it was still difficult to get good performance from it.
  • The GUI design was not adapted for small screens with very high DPI. There was lots of padding and spacing between elements in the UI, which meant small hit target areas and an increased sense of clutter. There were also a lot of lines and borders which again meant the interface looked very cramped on a small screen.
  • Most of the interface was not usable with a finger input method, it had to be used with a stylus. This was a particular problem because the Neo1973 does not have a stylus holder.
  • The top and bottom panels were very small and not very effective. The footer was also redundant most of the time since very few applications used the “status” area.
  • Scrolling was supposed to be implemented with a “scroll wheel”, but most users didn’t understand how this worked. Otherwise traditional scroll bars were used, which are often difficult to use on touch screens.
  • The design for stylus applications was split into two panes, displayed on the screen at the same time with a toolbar through the middle. This meant that neither pane was very useful because it ended up being too small to fit on the screen once you included the on screen keyboard. The toolbar buttons were also small and it was unclear what they should apply to.
  • Task management was difficult, as there was no way to switch between windows of a current application and there was no standard way of switching applications.
  • The application framework was difficult to maintain and we often spent more time fixing the extra widgets rather than building our own applications.

Solutions:

today-1.png
New style UI

One of our primary aims was to reduce the amount of extra widgets and framework built upon GTK+. Therefore, the theme design pulls on the strengths of GTK+ and the interface design can be implemented without using any custom widgets. This improves performance and cuts down on the amount of maintenance and bugs in the framework. We also worked on creating a set of guidelines, that would explain how developers should design and layout their applications in a consistent way.

  • The theme was redesigned and made more suitable for the high DPI of the target screen. It was also made simpler which improves performance. There is also the possibility of using a custom GTK+ engine in the future to improve performance even further.
  • Each application was split up into “pages” which represent a single interaction point such as browsing a list of contacts or dialing a number. This reduces the amount of information on the screen at once, providing a simpler and clearer interface.
  • The toolbar was moved to the top of the screen and increased in size. This provides access to functions relevent to the current page
  • A “switcher” was placed at the bottom of the screen that allows the user to switch to a different page. This is actually a standard GtkNotebook with the tabs displayed at the bottom.
  • Scrolling would be possible by dragging a thumb or finger up and down the list. Chris has already mentioned his work on this.
  • A new Today application that would incorporate a central place to start and manage applications as well as giving the normal overview on missed calls, unread messages, etc. This is quickly accessible from a hardware button on the Neo1973.

Over the last two months, we have re-written the Contacts, Dialer and Today applications to fit the new design. We are also working on a new version of Dates.

So now all the applications should be reasonably accessible with either using a finger or a stylus. The conversion path for “desktop to phone” should be a lot simpler and it will be fairly easy for anyone with GTK+ knowledge to start developing applications that will look and feel like they belong in OpenMoko.