Thanks for the example.
What worries me the most is the amount of knowledge required to create such a widget.
(debian packaging,autotools,c programming ,gtk and glibc pragmas,hildon additions)

Lets create some more lightweight ways’ of doing this

@andre: sorry for the offtopic, but it was a fast thought about similar platforms like Nokia WRT (http://www.forum.nokia.com/Resources_and_Information/Explore/Web_Technologies/Web_Runtime/), Opera Widgets (http://widgets.opera.com) and W3C (http://www.w3.org/2008/webapps/) and Bondi (http://bondi.omtp.org/default.aspx) work on this area towards a standard…

@Murray, that’s what I am playing with (and with QtWebkit too)…

Then again, it shouldn’t be that hard to put a GtkWebKit widget in a Maemo Desktop Widget. Then you can do what you like.

@Manrique: That’s offtopic here. For explicit enhancement requests, feel free to file a ticket in bugs.maemo.org (though »“standard” xhtml+css+js widget framework« sounds very vague and might become a WONTFIX. I don’t think there’s something i’d call standard in this area yet).

I hope that next Maemo device would support “standard” xhtml+css+js widget framework, like the one that is provided with Nokia phones…

I’m working on some example code for Maemo 5 as standalone modules with full autotools files.

I now have Desktop Widget example code working in the Maemo 5 Beta SDK, showing a simple clock face, using the drawing code from Davyd Madeley’s cairo-based custom widget example, with his kind permission. Implementing a Desktop Widget is much like implementing a regular GTK+ Widget: You can draw in the expose-event handler, or add child GTK+ (or Hildon) widgets.

I’ve filed documentation bugs to make it easier for the next person to figure out how to implement and install Desktop Widgets, and a few bugs about the Hildon documentation in general.

I expect the final Maemo 5 version to have many standard Desktop Widgets, far more attractive than this:

In Desktop Edit mode, you can move the Desktop Widgets around by dragging them with your finger, remove them by touching the X icon, or configure them by touching the spanner icon. You can add extra widgets (if installed) by touching the “Desktop menu”. Note that you need to apt-get update and upgrade after installing the Beta SDK to see the X and spanner icons.

The rendering artifacts (such as the white line at the top) are just a known bug in Xephyr (on the PC). They won’t appear when running on an actual device.

Over the last few weeks, Daniel Elstner, Johannes Schmid and I have updated our Clutter tutorial to the latest Clutter 0.9 API and I think we are now finished. I think Clutter 1.0 will appear soon, without major API changes needed in the tutorial.

There’s a html version and a PDF.

This is our small collection of books.

The gtkmm web site also has a list of C++ books we recommend. David and Michael really liked Accelerated C++, confirming the good things I’ve heard about it.

I’d like to buy some Beagle boards for the trainees to play with. Does anyone know of some good general books about deploying Linux to arbitrary embedded hardware? I’d also like them to have some book about setting up custom Debian and/or Fedora repositories, as most embedded projects seem to do, ideally with a proper autobuilder. They should learn about OpenEmbedded and Poky too.

I recently took another look at boost::python. It was a much better experience than when I first tried boost::python for Glom in 2005, probably because my use of the Python C API in the meantime has helped me understand what boost::python is doing. I have a mostly-done patch to use it in Glom 1.12 (Glom 1.10 will be released soon). This should make the code simpler and much more robust, allowing me to add more Python API to Glom, allowing people to drive more of the Glom UI via scripts.

As a side-effect this will force us to enable C++ exceptions in the Maemo build for Glom 1.12, increasing code size, but that might be less of an issue by then.

I do find the boost::python documentation fragmented and unfocused, spending too much time congratulating itself about its use of various design patterns and generic programming techniques in the implementation, instead of just telling me how to achieve common tasks. It often assumes knowledge of the Python C API, as if it is based on original proposals or internal documentation. Many companies are using boost::python so I’m surprised that none have arranged for more useful documentation to be written. I’d be happy to do it if someone wants to pay for my time.

In fact, boost::python’s API maps closely to the C API, so you probably need to know both, though I hoped that boost::python would make it clearer and more explicit.

However, the people on the boost::python mailing list have been very helpful when the documentation has not been clear or where I have made silly mistakes.

Boost should install pkg-config .pc files

Getting the CFLAGS and LIBS for boost python in your configure.ac is insanely difficult and fragile. There are some .m4 scripts out there, but I can’t get any of them to work. Why on earth don’t they install a .pc file? They can’t all be Windows programmers.

And despite using unstable APIs, they don’t seem to allow parallel installs. For instance, on my Ubuntu Linux system, the headers are directly under /usr/include/ rather than /usr/include/boost-python-1.0/. GNOME gets this stuff right.

The need for parallel installs is even greater for boost::python because there are various possible incompatible configurations, any of which you are likely to find on your system. At the moment you will just get compiler or linker errors (which distro packagers don’t understand) instead of being able to explicitly depend on a specific version with a specific build (which distro packagers could understand).

This will make life difficult for Glom distro packagers, but I think it’s still worth it.

Over the last month or so our two trainees, David King and Michael (not Mathias) Hasselmann have made good progress getting familiar with GTK+ and associated tools on Linux. They are on an intensive schedule, but they have the time to learn how things really work, so they don’t have to feel that any part is a mystery. For instance, they know now how to create custom GObjects and GTK+ widgets rather than just how to put widgets together in Glade. Now they will move on to C++, moving through gtkmm and then to Qt, with detours through Maemo and Scratchbox.

We hope to offer training to customers in the near future and this is giving us a good idea of what to cover and how.

Beyond just coding, Daniel and I are helping them to form good open source habits, creating developers in our image, so they can be creators of quality and fighters against entropy. I’ve encouraged them to blog about the experience and generally get involved in the community as an important part of their training, so don’t hesitate to give your advice.

It’s also interesting to see how the move to Germany has been for David, registering for various things and finding an apartment. It seems easier in Berlin than in Munich, and easier now than when I moved to Germany 10 years ago. Daniel’s help has been a big time-saver, I guess.

I set up planet.openismus.com to show their blogs and all our others too.