Category: themes

Christmas: It’s been way too long since I’ve updated this. Christmas is done with. It was fun, but short. I am not sure I know how to vacation anymore as I spent much of it worrying about various GNOME and Red Hat responsibilities. I knew I should relax, but wasn’t really sure how to. To make matters worse, a close family friend was struck by a car on Christmas day. We spent much of it in the hospital waiting room.

Christmas was also tempered by the fact it is likely to be my last one in Los Angeles. My dad recently got a job heading a new astrophysics facility at Stanford University. He’ll likely be moving to Northern California in the Fall. More info at:

http://news-service.stanford.edu/news/2003/january22/kavlifinal-122.html

This is great news for him, and I hope he is able to make the most of it.

toy: I got a danger phone for Christmas. This is a great, great toy! I love it!!! It is also obviously much closer to what the future of cell phones will be like then my Nokia. Good job guys.

themes: So, my theme capplet was basically a bust. I have gotten a lot of complaints about it — mostly private. People don’t like the way it acts, and quite frankly, I don’t blame them. The current UI is definitely a big compromise and it shows. I was very aggressive in trying to get it into GNOME and I probably should have backed off. Unfortunately, the old stuff wasn’t much better and wasn’t really worth reverting to. So what went wrong?

The big problem was trying to fit the theme capplet into ‘The Capplet Way’. Before I go on a little more, I should probably explain this as it has never been explicitly written down. When Bradford and I first started on the control-center for GNOME 2.0, we decided to make the capplets instant apply at the urging of Seth. Despite being a little dubious we gave it a shot. The results were surprisingly pleasant — especially for things like the mouse capplet. After playing for a while, we came up with the following rules:

1) Every update of the capplet must be triggerable externally. This means that the capplet can’t necesserily validate the data that gets set.

2) No change by the capplet can be limited to a local scope. This means that, if the user modifies the capplet, it must immediately propagate. Along those lines, capplets must be as stateless as we can make them. It must always be possible to close a capplet and restart it without it affecting the user.

3) Every change must be easily ‘revertable’ by the user. That is, if the user selects ‘left handed mouse’, they must be able to switch back to ‘right handed mouse’ just as easily. There is no need for a ‘revert’ button as they can just put the state back themselves.

Every capplet I’ve written thus far has followed these rules, and I have been extremely happy with the results. We have nice, maintainable code, some beautiful dialogs, and an understandable system.

Lets look at each of these in the context of the mouse capplet. This dialog itself doesn’t actually control the mouse — that’s done by gnome-settings-daemon. It doesn’t have any exclusive control over the settings either. I can have any number of mouse capplets running at any one time. It’s function can always be replicated by gconf-editor (or xset, in some cases). For simple boolean values (such as the handedness of the mouse) this is very straightforward. When the value changes, you update the UI. When the UI changes, you update the value globally.

(As an aside, one of the problems with this example is that people had trouble figuring out that they had to right click on the toggle button to switch back from left handedness. We solved this by making the button respond to both clicks. Even simple examples sometimes aren’t.)

Getting the theme capplet to fit into this mold was hard. It was also much more complex than any other capplet written thus far, with the possible exception of the mime capplet. I had all sorts of problems with it, most of which I’ll document later when I’m more awake and able to do it justice. Stay Tuned!!!