I sent this to the gconf-list as well, but I’m posting it here in case someone has some generic code that I can steal, or has some better idea.

Say I have an intensive process that should be rerun in response to changes in any one of twenty GConf configuration keys, how might I prevent my application from re-running that process 20 times instead of just once, when changing all the keys at one time?

At the moment, I think the only solution is to append each notification key to a GList, and use a g_timeout handler to notify my application about batches of changes, if anything changed, at regular intervals. That would not avoid all excess notifications, but it could avoid most.

Note that you can’t just turn off notification while making the changes, because the notification happens later, after you’ve turned notification back on again. It’s asynchronous.

Openismus now has another part-time developer: Christian “gicmo” Kellner, a gnome-vfs maintainer who has also worked for Scalix on their Evolution connector, currently a student at Passau University, Germany. He’ll be doing roughly similar work for Openismus, getting stuff done that wouldn’t get done otherwise. If only we could get the rest of the GNOME couch.

And Marcus Bauer joins us internetically as a full-time freelancer for at least the next couple of months, hopefully more if the work is there. Marcus is an accomplished coder, living in Nice, France, who is most well known within GNOME for his work on the LiveCDs for previous releases. He promises he’ll have a blog soon.

I received several other good applications this time, but few from Germany. Even in the EU, employing residents of other countries is a legal/bureaucratic/language problem that I’m trying to avoid, but will probably have to deal with eventually for outstanding candidates. I’m sure there’s lots of information out there but, like many location-based things, it doesn’t yield to Google searches.

When you specify glib idle callbacks to g_idle_add_full() with different priorities, there is no guarantee that they will be called in the order that you added them. But it’s normal that you’d want, for instance, progress callbacks to have a lower priority than the callback that does the work itself. But you probably need to know when the last callback has been called (so you can release state information), and you probably don’t want to show progress information after the work has actually finished.

I added this generic TnyIdleStopper API to tinymail to help us avoid this problem: It’s a kind of a weak-ref smartpointer thing. It seems to stop the crash, and passes the valgrind test, but I worry that there’s a far simpler solution that I’m overlooking.

I’m looking for one or two more part-timers for Openismus, possibly a full-timer. It’s a chance to do work that people will actually use, about half of which is released as source code.

It’s much easier to employ residents of Germany, but I’ll do the extra work to employ in other EU countries if necessary. I wish the EU made this easier.

You’ll need GTK+ experience, usually in an open source project. gtkmm experience is a plus, but we’ve got that mostly covered for now. We work from home for now. I jump at the chance of employing people who’ve demonstrated ability to deal responsibly with well-defined tasks without too much micro-management. Email me please.

I’d love more people like we have already. The other Openismus guys really get the job done. We are doing pretty well at the moment, expanding slowly and safely, as a natural evolution of my freelancing days. This month we reached the point of financial safety for the year, which reduces the pressure and might even let me take a break. I hope the GNOME Mobile and Embedded group can create more opportunities for growth now that it’s announced publicly.