Entries Tagged 'General' ↓

teuf, you can stop bugging me now. It appears I’ll be coming to
FOSDEM this year. I’ll be *gulp* making
a presentation about maemo but I haven’t yet
decided what about exactly. If there’s something specific you’d like to hear
about, let me know.

I haven’t been to Brussels before so I’d be interested in hints about places to
visit just in case I manage to extend my stay an extra day or two.

Today I was stuck queuing for food for at least ten minutes. I’m still wondering whether that was a planned part of the Russian theme week our canteen is having…

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 🙂

Had a nice team building day by way of karting at VM Karting Center. I came in third after Karl and Jakub, but I had the best lap time \o/

Karl confessed being a seasoned pro so he doesn’t count. Jakub managed to get most track time by driving slow enough during warmups to drop into the B-finals, and then fast enough to get into A-finals as well. Damn him =)

Dinner was Mexican though a bit tasteless. If it doesn’t make your nose run it’s not spicy enough.

Speaking of plugins I was testing Jakub‘s load-applet (among all the INdT games) and felt it needed some tweaks. I was thinking about adding a trivial Screenshot saved infoprint for feedback and widening indicator bars a little to make them more visible.

But where is the source?! Come on!

Eek! I’m no longer even sure I’m allowed to install the plugin. Looking at the package contents shows in interesting copyright file:

Copyright: (c) 2005 Nokia Oyj

Confidential. You are not free to do anything with this package,
unless you have a permission from Nokia Oyj.

Jakub, maybe you should discuss with someone about the copyrights? Guillem and Marius can give you some pointers, I’m sure 🙂

PS. I’ve never been to Australia or have any affiliation to the university…

Just noticed an interesting bit in philipl‘s Gweather-Maemo README:

- Gconf schema is not properly installed - I'm not sure how this
  is supposed to be done on the device. I don't see other apps
  doing it.

As far as I’ve understood it, there’s no way to run any postinstall scripts for AI installed packages, so no schema installation is possible. The other alternative, pre-generating the xml-files, fails because GConf isn’t configured to look in /var/lib/install 🙁

Oh well, we all know AI is making mockery of package management anyway. A trivial update to /etc/gconf/2/path might make pre-generated schema installation work, but in the longer term you just need to keep kicking Marius to get the next generation AI actually work. Come to think of it you should to kick him even for a short term solution 🙂

Fortunately GConf will still work without the schemas, you’ll just lose the defaults set in schemas. The code must have defaults of its own to survive broken GConf anyway, right?

BTW, that dialogs only shrink when the input methods is shown and not grow back when the IM goes away is (broken?) as designed.

Also, the LD_PRELOAD trick is only meant as a fallback. maemo-af-desktop (including plugins) is supposed to not be needing it… (on related note, LD_PRELOAD disables any benefits prelinking would otherwise have)