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.
In the o-hand tradition of stealing people’s thunder, I present to you the first screenshots of openmoko-dates running on the Neo1973.
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.
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:
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!