I’ve mostly been working on non-ui related components for OpenMoko recently (working on the package management system, opkg and it’s associated packagekit backend), which gave me a chance to step back from the GUI applications and take a look at some of the areas that could be improved. I posted some of my thoughts on the openmoko-devel mailing list (thread here) and got some quite interesting and encouraging responses.
So, I set to work building some patches. Here are some screenshots of progress:
Phone numbers and contact photos in the address book contact list
Currently work in progress, implementing “Add to contact” in call log
I’m also hoping to get a few theme tweaks in as well. Here’s another game of spot-the-difference (hint, not anything in the number display). And it actually does make it look a lot smarter on the device’s small screen.
I need to find an artist to help me improve the GTK+ theme. Firstly the gradients really need to go because not only do they look ugly with the banding from the 16bit display, they also cause significant performance problems. If anyone wants to help me out, please do drop me an e-mail, or discuss on the openmoko-devel list.
Some good progress on Opkg and it’s PackageKit backend recently. New features such as autoremove and tags have been implemented in Opkg, and PackageKit can now take advantage of them. I’ve also increased the PackageKit method coverage by including description searching and group search, amongst fixing various bugs and improving internal feedback mechanisms.
Opkg now has a mailing list for discussion on future development and current issues.
Here are some screenshots of the GTK+ PackageKit frontend using Opkg as the backend:
Current method coverage shown by pk-backend-status:
Listing packages in a group using the gnome-packagekit frontend:
Searching on the description field and filtering to only view GUI applications:
Slightly off topic, but of interest to OpenMoko/OpenEmbedded developers, is the new Poky SDK, which Rob wrote about. The Anjuta plugin is particularly interesting, because it significantly shortens the development cycle when cross compiling.
I haven’t written about work things for a while, but I’ve been working on a couple of things, including Opkg (a new package manager based on the un-maintained Ipkg), and a PackageKit backend to use it with.
And this weekend (starting at the beer event on Friday night) I will be at Fosdem. See you there if you’re going!
Today I achieved a small milestone: I have managed to run and use gsmd reliably on a host computer.
This is really important because being able to use gsmd on the desktop dramatically reduces the development cycle of phone (gsm) based applications. Rather than having to code blind, cross compile, install onto the target device and then test and debug on the target, you can now do the entire cycle on the desktop.
I first tried the gsm passthrough features in u-boot, which effectively turns the u-boot terminal into the gsm terminal. Unfortunately there appear to be bugs somewhere in this process and it would not work reliably. However, with a bit of thought, this functionality is just as easy in user space.
Here are the instructions:
- Maks sure gsmd is not running on the phone: killall gsmd
- Run netcat on the phone to export the modem serial port: nc -l -p 5000 < /dev/ttySAC0 > /dev/ttySAC0
- Compile pty.c and run on the host with: ./pty 192.168.0.202 5000
- run gsmd on the host with (replacing 0 if necessary): ./gsmd -p /dev/pts/0
- run openmoko-dialer or any other application which interacts with gsmd
If gsmd from OpenMoko SVN doesn’t appear to work correctly, try Andrew’s git repository: http://folks.o-hand.com/andrew/gsmd.git/
(Update: if you’re wondering why I didn’t use a “proper” application to export the serial port, it is because nc is built into busybox. I did originally use ser2net to export the serial port, but using nc means no cross compiling or extra set up on the phone is needed to get this working.)
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…
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.
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…
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.
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).
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.
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.
|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.
|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.