Sunday, January 29, 2006

Things about GNOME that Suck, Part One

Well, after GNOME.conf.au I have been re-invigorated. My desire to contribute to GNOME has risen, so here is my first concrete action. Unfortunately it isn't a patch or anything as concrete as that. What is it then? I have resolved to blog every second day about one and only one thing that bugs me about GNOME. On alternate days I will blog about things that I love about GNOME. When I have run out of those things, I will stop. ;-)

So, without further ado, here is Gripe Number One from me. UIs that block on I/O. In particular: yumex, Gaim and Evolution. I suspect that the reason why I notice this and it bugs me so much is that (at home) I am on a 56k modem connection. Waiting on a response from the network really exposes those "no-repaint" moments.



What to do about it? There has been discussion on this planet recently about multi- threading vs. not. Perhaps the one way to drive the point home is for people who develop network-using applications to dogfood their project using a network throttler. Have a fat pipe? Maybe that's why your application looks unprofessional.

Update: someone asked for evidence of Gaim blocking on I/O: here it is:

10 comments:

Anonymous said...

Well, you can add another point to the list;

memory usage with XFCE4 after login: 100MB
memory usage with gnome / fc5test2 after login: 380MB

Anonymous said...

@Anonymous:
memory usage with KDE 3.5 after login, starting 3x rxvt-unicode, FireFox with 4 tabs open and reading Mail/RSS-Feeds in Kontact: 142 MB (310 w/ caches) ;-)

Anonymous said...

also running an application with X forwarded through a ssh login with a high latency gives an interesting perspective. Some apps take a lot of round trips to draw their interface.

Anonymous said...

i agree with you. Thank you for bringing this topic up!

Firefox has a simular problem. For example if i start a download and the server need some time to response than the whole firefox ui freezes until the download has startet.

Hope this will be fixed in the future.

Anonymous said...

Amen!

On my huge list of programs to write in my copious free time is something to throttle various performance parameters, including the network, for testing purposes.

I have a related problem: I'm on a Wifi link which is fairly fast, but also pretty unreliable -- it drops dozens of times a day. I'm imagining a program that had sliders for "Bandwidth", "Latency", and "Reliability". Or perhaps two sliders for each parameter: average, and standard deviation.

One thing I've learned is that if it's not a requirement, and you don't have a framework for testing it, it probably won't get done. It would be great if GNOME nailed this.

Anonymous said...

I think will be great have a page in the gnome.org site where to put ideas and the loved/hated things...

Anonymous said...

i think gaim does never block on I/O. do you have any examples?

John Williams said...

Sure. I have added a new screenshot to the main post.

John Williams said...

Hi Aldo! See http://live.gnome.org/Feedback

Anonymous said...

Gaim blocks when you enter "huge" channels, like #gnome* on irc.gimp.org or #gentoo on irc.freenode.net.