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!
The hildon-desktop Python support code is available, of course. We’ve written some really dummy example plugins with the new API and Python API just to give a taste of what is coming.
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.
6 thoughts on “Hildon UI Development News”
So, Does this work in 770 device? Nice!
Hi Rocha, nice post! Now, is there any blog (instead of svn changelogs) where we/me can keep up with the latest achievements on hildon-ui?
Tks, keep up. Cheers,
> even though the development happens in a public repository,
> sometimes we’re not very good in communicating about what
> we’re doing
You could help by correcting this page, and keeping it up-to-date:
At the moment, the branching policy is not clear.
Of course, you’ll probably want to create a new page for 4.0, or whatever you are calling the current work. Well, you’ll probably want to call it “next” or suchlike because the version numbers tend to be Nokia secrets.
UID and HID are two of my armchair passions. Learning how to get involved with the improvement the UI for internet tablets is something that I would really like.
A few points:
-I like that the OS2007 is more thumb friendly than the OS2006 was.
-We still need a way to rotate the screen coded into the hildon UI framework. Right now, FBReader really looks silly in portrait mode and not in full screen. and other programs could take advantage of this too: particularly ToDo lists.
-I’m very glad to hear that you are moving away from a hard coded resolution for the UI.
-It’s nice to see how you are methodically fixing inconsistent elements with more universal ones.
Keep it up.
Love the task list applet…any easy way to install it? thanks and keep up the good work!
Comments are closed.