Entries from December 2005 ↓

Pushing more stuff to the other side of the firewall, little by little.

In order to cover up for some of the past design decisions we’re now in the process of rewriting the HildonApp and HildonAppViews. The task is pretty straightforward copying of existing design and code, but if you’ve got frustrated with the current API for one reason or another here’s your chance to influence getting the next generation better than ever. Remember. if we don’t tell us what’s bugging you we can’t really go about making things better either.

Another, much larger issue is the scalability of the maemo UI. We don’t really want to remain limited to the current screen size and hardware configuration, so we need to look at how to make the UI more flexible. While simple widgets can be scaled all the way down to 0x0 pixels, some widgets have hardcoded pixel measurements in the code, and more complex widgets (e.g. file selection or maemo-af-desktop) might even require almost complete redesign when scaled down enough.

Therefore we’re exploring various limitations in the current codebase and ways to overcome those limitations. We’ll update the wiki page shortly as it’s quite terse currently, but the complexity of tasks can vary a lot. Replacing hardcoded values with style properties is trivial, adapting content to be shown in GtkTreeView based on screen size (multiple vs. single line, Wednesday December 21st vs. 12/21) in a generic way is probably going to take quite a while.

Comments are welcome! We wouldn’t mind sharing the effort either, but we can start small… =)

Well, slapping rambokid around a bit with a troutsome memory consumption figures had the positive effect I was hoping. Now the amount of free memory after device bootup should be about the same as before, so now we just need to revise the use cases to consider the longer term benefits just mentioned. Oh the work never ends…

Now where did lemody hide those pango performance results showing 1.10 is consistently a bit slower than 1.8 on 770. Maybe if we slapped federico and others with those we’d get even better pango as result… One can always hope, eh? 🙂

(Maybe better to double check we had all the optimization patches backported first, though.)

It’s a bird, it’s a plane, it’s the osso-email sources!

For those of you not paying attention the osso-email sources have been uploaded to the svn repository on stage. Now you can start fixing all your favorite bugdesign decisions in email =)

Just uploaded the detailed memory usage reports (guest/guest) to stage.

Run some SMAPS measurements on the new GSlice memory allocator in glib. It is supposed to be both faster and more efficient than the current GMemChunks used all around in glib and gtk+ code.

Well, at least my measurements showed the memory consumption in the system after booting up the device increased by 600kB. All other use cases I tried also showed only increasing memory usage 🙁

OTOH rambokid mentioned GSlice enables many optimizations not done yet, so there’s still hope 🙂