Desktop Summit
Briefly – let me say it was great to talk to everyone I did at the Desktop Summit! I had a lot of fun. And thanks to Openismus for loaning us their offices for a successful introspection hackfest.
Clocks – maybe not so easy
So a little over 10 years ago, I wasn’t really a GNOME contributor. Actually at that time, I was becoming a Debian developer. I was making Debian run better on my (then PowerPC) MacBook, helping Debian/GNOME integration, and then after that moved into upstream GNOME where basically more interesting things happen than packaging (except for installers which sadly we haven’t pulled into GNOME and fixed yet, but that’s another story).
One thing I remember that really resonated with me a lot in 2001 was when Sun Microsystems contributed a Usability study to GNOME (the link there is obsolete, the study now lives here for the curious). Specifically, the section on clocks.
The usability study in general created a big collective realization for the GNOME project that we were basically just doing a lot of stupid and pointless things like having 4+ different clocks. That realization led to a big push for usability and simplicity, and you can find the results in things like Havoc’s preferences page and of course in the GNOME 2.0 release which followed.
A lot of Internet dwellers seem to interpret the cultural aversion in GNOME to excessive settings/preferences as us just being sadists, but what it really means to me is that there are real bugs to fix. And GNOME to me is really about that – people who believe in Free Software, but also making something usable and not buggy. Having a willingness to solve hard problems.
What does this have to do with clocks? Well, you see, it turns out clocks are a bit hard. During the Summit, Dave Airlie was complaining the GNOME 3 clock didn’t show the right time immediately after unsuspending, which honestly is pretty embarassing. Another example is leap seconds. If we can’t get the clock right, we should probably just give up =)
So I fixed it with a quick hack, but in reality there are other situations which the clock display needs to be aware of – for example, if the user changes the time via the Date & Time panel. We could bodge around this in userspace, but it turned out that relatively recently the Linux kernel had gained exactly the API we need. I spent some downtime after the summit working on it, the resulting bug for the curious lives here. One of the nice things with this approach is that when we’re showing an HOUR:MINUTE clock, we no longer need to wake up the display process once a second just to see if the system clock got set from underneath us, which is useful for power saving.
It’s just exactly the kind of thing that GNOME means to me – the tradeoff for us not working on supporting a combinatiorial explosion of options is that we spend our time making the core good. Are there more important issues to fix than the clock? Yes, but it’s a visible one and I was offline while traveling so it was something I could easily do then. Oh and also to continue to prove Linus wrong that no one uses Linux-specific interfaces by using them in GNOME =)
Colin Walters 
Nice, the delay after suspending is annoying.
And while you are at it, could you move it to the right where it belongs? (just kidding, I realize it is a lost cause)
As is using the ‘Delete’ key to… delete files in Nautilus (and no, that is not changeable in Behavior settings tab. I have a feeling that tab will be gone away with soon, because goodness, developers know way better what’s best for all of the users).
Not much reason to be happy in the Gnome land, unfortunately.
If I recall correctly, it’s planned to go back to just the delete-key once proper undo is implemented in Nautilus.
Here is the related discussion [1], just using del was a long standing problem [2] for a lot of people and popping up a dialog on every delete would have been worse for everyone. It might go back to del once we some kind of delete animation (or something) and proper undo implemented in Nautilus.
Developers don’t know what’s best for all users but tries go get it right for as many as possible (and sometimes gets it wrong), we do however wants as few moving pieces as possible because it makes new development much easier (less amount of “but what if that pref is set, and then if that pref is set…”, hardware gives us enough of that already 🙂 ).
1. https://mail.gnome.org/archives/nautilus-list/2011-March/msg00018.html
2. https://bugs.launchpad.net/nautilus-elementary/+bug/738616/comments/3
“(except for installers which sadly we haven’t pulled into GNOME and fixed yet, but that’s another story).”
We’re doing a revamp of the anaconda installer in Fedora and would love GNOME folks’ help. We started in June / http://mairin.wordpress.com/2011/06/16/making-fedora-easier-to-use-the-installer-ux-redesign/
Sweet! Sounds like this doesn’t cover changing timezone, though? I was always bothered when I thought I’d changed timezone, but it wasn’t reflected in the displayed clock.
Eric, that’s right, it lives in /etc/localtime on Linux, and the kernel doesn’t know about that.
We went back and forth a lot on how that should work with GLib’s GDateTime class.
Would you expect an important data file like /etc/localtime to be cached forever after the process starts up, and you have to call some magical API to update the cache, and there is no guidance on when/how to call that API?
If you were Ulrich Drepper and implementing gethostbyname() for glibc, you might do that. We originally were going to do something similar in glib but came to our senses =)
I just decided for now that we just stat() /etc/localtime every time you ask for the current time, and in every process with a wall clock we can just inotify on /etc/localtime. I will likely eventually change the glib API to do the inotify internally but for now just decided to punt it to the component implementing a clock.
Colin, thanks for pointing this out, we’ve been waiting for this in KDE too 🙂
John.
KDE Date/TIme maintainer.