(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!