Tag Archives: Gnome

www.gnome.org

g_idle handlers in unexpected sequences

General,

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.

Openismus hiring

General,

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.

GNOME Events Box: Mini-PC?

General,

The Events Box schedule shows that it will be used next for LinuxTag in Berlin at the end of May. We need to do some restocking before then. Our donation/sponsoring hopes for this have fallen through so we’ll probably need to buy. We’ve chosen May 1st as the final decision date.

The PC has taken quite a battering and the hard drive is now dead, so now would be a good time to replace it with something smaller. It was small, but not mac-mini-small. I chose it because we needed a 3MHzGHz PC for GUADEC streaming and 3GHz mini PCs were much more expensive. But now we have dedicated PCs for streaming, and it’s obvious that something lighter could save us on shipping costs.

So what are your suggestions for a good-enough mini PC? Note that I insist on x86 to have the most chance of everything working very easily. I also guess that Intel graphics would give the best chance of working 3D effects.

We need one new flat-panel screen too.

As ever, we are very open to the idea of donations and/or sponsorship from hardware vendors or resellers. This should be a fantastic opportunity to put your product next to GNOME heroes.

gtkmm approved for GNOME Desktop modules.

General

While I wasn’t paying attention, and without me asking, gtkmm was approved as a dependency for official GNOME applications, which is a nice surprise. Python was approved before, and Mono will be allowed on a case-by-case basis. I still think it’s unwise to have a desktop implemented in too many different programming languages, but I guess C++ is the closest thing to C, and C++ is already used partly by some official GNOME applications without gtkmm, and doesn’t present a big threat used wisely. I like C++.

GNOME Summer Of Code 2007: ranking.

General

As the April 9th deadline approaches, I am becoming more brutal with my ranking of the summer of code applications. The Google web application is still not a big help with managing them, but Lucas Rocha and Vincent Untz are doing the hard work to keep us organized.

We have approximately the same number of applications as last year, but there are some signifcant differences:

  • Last year (and before) a very large number of applications were complete crap, either being copy-pastes of our own project proposals, or one-line applications. This year we seem to have very few of these.
  • We have more than zero female candidates, though still not an acceptable amount. But it’s hard to guess at the gender of some of the names.

I think these changes are down to our poster drive this year, and the summer of code process being more familiar to people now. It means that we have a lot more text to read, and many more difficult decisions to make.

Hopefully it will allow us to choose some more genuinely useful projects than we have sometimes in the past. I’d like our students to learn to consider user goals and usability, and I’d like them to become involved with the community by writing code that others actually care about.

GNOME visions: More needed

General

As a follow up to my people post:

I was pleased to be reminded how many people are already working in this direction, such as Gimmie’s People menu, gossip-telepathy, and Project Soylent. I’m not claiming to be original. I’m convinced that we can get this done technically, and that we can get it done faster by encouraging people to work towards a coherent vision.

But this people thing is just one vision. Where are the others?

And I wonder, once someone has written these up sanely, how should we go about giving a plan an air of respectability? Can we brand a plan as official? I doubt that, but I think that’s OK. I’m sure we don’t need unanimous consent, but it would be nice to have some consensus, and it’s important to try to avoid clashing with alternatives if there are any. At the moment, I guess it would be enough for someone to just say “Here’s an XYZ plan for GNOME. Who’s thinks that would be good?” but maybe I’m being overly optimistic.

As always, I’m not under the illusion that anyone can make something happen by just saying it should happen. But a shared vision can make things more likely to happen.

Nautilus 2.18 bug whine: Name column still annoying

General,

The fix to the incredibly-small-name-column bug in nautilus has introduced a new bug. The name columns are often still too small, and they have to be resized even when reopening the same folder. At the moment it looks like this is going to be in Ubuntu Feisty to annoy me for the next six months.

I feel sure that the column sizes were remembered before. If not, I guess they just had better defaults before, and I guess that the name column resized with the window before so it was enough to just increase the window size, which was remembered.