Cooking, drinking a beer and web browsing
The number of GNOME-Platform-based user interfaces (or “Desktop environments” if you prefer) for embedded devices is growing. AFAIK, those are the guys in the field:
We have different focuses: OLPC (Sugar) on education, ACCESS on PDAs, Maemo (Hildon Desktop) on Internet Tablets and OpenMoko on cellphones. However, I’m sure we have a lot to share and learn with each other in terms of architecture, UI framework, plugin systems, standards, code, ideas, and so forth.
I saw that (probably) there will be some talks related to those projects in GUADEC. This means that we will all be at the same place, at the same time, It’s a good oportunity for us to get together and talk! So, what do you think?
Update 1: It seems that some very interesting discussion among OLPC, Maemo and OpenEmbedded guys already took place during Bossa Conference. Good to know we’re already talking. :-)
Update 2: Someone commented that I should add LiMo Foundation to the list. Does anyone know if there will be anyone from LiMo at GUADEC?
I added a service that implements the Desktop Notifications draft standard. It’s not complete yet, I still need do some changes on one of our widgets, but it’s working like a charm. Also, support for multiple notifications at the same time is pending. In practice, this means that applications using libnotify (or any other compliant client library) will have their notifications shown on Hildon Desktop! Here is the result:
Hildon Desktop showing a notification using libnotify.
Notification area (aka system tray)
Moises rocked our world by adding support for system tray standard in Statusbar. This means that if you use GtkIconStatus (or any other compliant implementation of the client-side) it will appear in Statusbar. Of course, still the usual Statusbar plugins can be loaded in Statusbar too. There are some pending issues with the theming of systray items (as you can see in the screenshot) but we expect to have it fixed soon. Here is a (mandatory) screenshot of Hildon Desktop running inside Scratchbox:
Statubar showing Gossip and Network Manager systray icons.
Update: Moises has just fixed the theming problem. Yay!
So, as I posted some days ago, one of our goals for the future Hildon Desktop releases is scalability. We want to be able to easily configure/adapt the desktop to different displays with different resolutions. As a proof of concept, I made some very small code changes and some adaptations on the development theme (aka Plankton) – created by MDK and tigert – and made Hildon Desktop usable on a 1024×768 resolution on my laptop. It would rock even more if I had a tablet PC here to use finger for interaction. Here’s the result:
Some weeks ago, I posted about how could it would be to have the GtkIconView selection looking like this. So, the first step was done: I cooked a patch. I guess when/if the patch is integrated into GTK (I’m still waiting for the feedback from the maintainers), the next step will be to do some rocking theming work in GtkIconView selection. Comments on this subject should go on bug #382544.
GtkIconView selection: first step for a potential selection eye-candiness.
Update 1: don’t pay too much atention to this checkbox in this screenshot. This is just part of GtkIconView test program with some weird layouts.
Update 2: for those interested, the rounded borders will come the theme engine, not in GTK itself.
As you probably (don’t) know, we, from the Hildon UI Framework team, have been working hard in the new code for the next releases of Maemo (The “don’t” is because even though the development happens in a public repository, sometimes we’re not very good in communicating about what we’re doing). Now, the heavy development work of maemo-af-desktop is taking place in a separate branch called hildon-desktop (the new name of maemo-af-desktop).
Our main goals for the next releases is flexibility, scalability, maintainability and developer-friendliness. The code of “maemo-af-desktop” received a lot of improvements for the N800 and Bora release (As you with a N800 in hands have probably noticed!) but still it has some serious problems. The layout of the UI is hardcoded (is was done for a specific display with specific resolution) and the plugin infrastructure is fragmented and (kind of) duplicated for each UI component (Home, Statusbar and Tasknavigator). Also, the plugin API is not very developer-friendly because it doesn’t take full advantage of the GNOME Platform knowlegde that developers interested in Maemo already have (this is my personal opinion). So, what are we doing to target those issues? Let’s see!
Separating the generic parts from the specific ones
We detached the “generic” parts of the UI into a library called libhildondesktop. This lib has things like different kinds of panels, a generic widget for Home, and interfaces for different kinds of desktop items that will reside in the panels and Home. The window management code has been put into a library called libhildonwm which is intented for very specific cases where the developer need some control over the windows behavior. For example, libhildonwm is used by application switcher to show the list of active windows in the Task Navigator panel.
So, what does this mean? This means that out future UI will be just a specific application of libhildondesktop and libhildonwm for a specific device. In hildon-desktop branch, we’re about to finish the UI (based on libhildondesktop and libhildowm, of course) that reproduces exactly what you have in N800. Also, it’s good to remark that this aproach makes it easier/faster to prototype different UIs and increase the hacking possibilities for the UI! Yay!
New plugin system
We now have a common plugin system for all UI components. The new plugin system is based on plugin loaders. Each type of plugin loader is reponsible for loading desktop items from different “sources”. For example, we have a plugin loader that loads (Task Navigator, Statubar and Home) plugins written with the current plugin API (To keep backwards compatibility). However, we’ll have a new GTypeModule-based API for developing desktop plugins so obviously we have a plugin loader for this kind of plugin too. This aproach give us flexibility enough to even have plugins written in different programming languages. We already have a Python plugin loader and the bindings for libhildondesktop (libhildonwm bindings yet to come).
Task List plugin written in Python running in hildon-desktop
Plugin loaders can be dynamically loaded without needing to rebuild hildon-desktop. We did this way because in the case of plugin loaders for plugins written in programming languages other than C, we cannot ensure that the runtime requirements will be available in the device by default. For example, the Python loader resides in a different module together with the libhildondesktop bindings so that in the future, if you want to add support for Python desktop plugins, you just need to install the bindings, the Python loader and Python debian packages. That’s it!
Any suggestions, comments, ideas, construtive critics and (specially!) patches are welcome. Get the code from Maemo repository and play, brake, adapt, change, etc. If you want to use the latest pre-built packages, you can always use Sardine.
This is unstable-under-heavy-development code. You should not rely on this code for anything. At this moment, hildon-desktop should only be used by courageous developers who want to contribute/use the very latest UI framework stuff.
After, reading a lot about digital cameras, I’ve got a new camera today: a Canon EOS 350D. Of course this nice camera doesn’t make me a good photographer at all (I really suck as a “photographer”) but I’ll give my best to improve that with this new awesome toy. :-) Big thanks to Ross, Hub, Tiago and Tassia for the suggestions and tips. Thanks to tigert for telling me about that nice camera store in Helsinki.
Canon EOS 350D: nice!