Archive for the ‘GNOME’ Category

Step back in time

Tuesday, October 14th, 2008

Slightly crummy name, but great to see the first phase of the ZFS Time Slider project that Erwann, Niall and Tim have been working on coming together in time for our OpenSolaris 2008.11 release next month.

It works a bit like another company’s product of a similar name, except right now ours only takes regular snapshots to the same disk, rather than backing up to removable media (but we’ll probably end up doing that too). It’s not quite the auto-save function that Federico was talking about last week and at GUADEC, but it’s certainly nice to see some of the power of ZFS in use on the desktop at last.

HIG 2.2

Friday, September 26th, 2008

I just bumped the stable version of the HIG to v2.2.  

Really it’s more of a 2.0.1 release, as none of the content has changed apart from the illustrations, which have all been updated to use the Clearlooks theme.  But given the number of people involved (Mihai Anca, Denis Anisimov, and Wouter Bron did the bulk of the illustrations) and the length of time it’s taken me to integrate them (about 9 months!), 2.2 seemed more appropriate…

(Unfortunately, nowadays you don’t get to see new versions of the HIG online until there’s a new release of gnome-devel-docs, and I know I just missed 2.24.0. But hopefully there’ll be another one along soon.)

Of course, this doesn’t address the more fundamental issue that the HIG now lags several years behind the curve of GNOME development. I’d like to think we’ll get around to doing something about that before the year is out.

On app-specific themeable icons

Friday, September 19th, 2008

So, we’re attempting to follow this advice for a couple of OpenSolaris applications we’re working on.

It works fine for the hicolor icons, but the advice for themes that want to over-ride them is rather vague: “You can also provide icons for other themes in here [$pkgdatadir/icons], by installing them into a subdirectory for that theme.”The question is, who’s responsible for installing them? The theme or the app? Seems to me there are problems either way.

If the theme installs them, first it has to find out where that app installed its hicolor app-specific icons. It will usually be /usr/share/appname/icons/hicolor, but there’s no guarantee about the value of $pkgdatadir for any particular application.

Once over that hurdle, the theme is now stomping in the application’s territory. At best, uninstalling the app will leave a $pkgdatatdir/icons directory on your disk, containing a bunch of icons that aren’t going to be used any more. At worst, the app uninstall might just lazily blow away the $pkgdatadir directory altogether, wantonly deleting files that were installed by another package (the theme).

On the other hand, though, we surely can’t expect each app to be responsible for installing icons for every theme that wants to override them. Distros can of course patch those apps downstream with their branded icons du jour, but that will soon become cumbersome when there are more than two or three such apps. And independent theme artists, such as those who contribute to art.gnome.org, don’t have the luxury of patching any apps at all. So their themes would never be able to override app-specific icons.

So what to do? The more I work with themes, the more I wish they’d all go away and we’d just use a single, identifiably-GNOME look-and-feel like the grown-up desktops do :P  

Tab frenzy

Friday, July 11th, 2008

Have to admit I cringe every time somebody adds tabs to an application. Not because I have anything against appropriate use of tabs (and I’ll reserve judgment on which of the recent additions are appropriate for another day), but because it’s such a wasteful duplication of effort, with each instance doubtless having its own inevitable little bugs and inconsistencies.

The HIG advises against document-level tabs in an app, largely because at the time, the usability team hoped GNOME would have a tabbed window manager in its not-too-distant future. The tab-related activity in the past week has me thinking me that we need this more than ever! App developers shouldn’t have to implement basic window management features, and (perhaps more importantly) users shouldn’t be restricted to grouping documents from the same application into tabbed windows–with a tabbed WM, they could still do so if they wanted to of course, but they’d also be free to group windows by task or project, or indeed any other way they wanted.

Is it worth starting to think a bit harder about how a tabbed WM might work (I don’t think we’ve ever sat down to try to design one for GNOME, although I know at least one tabbed WM has been implemented before)?  Or is it just something that’s just never likely to happen?

Cruisin’

Thursday, July 10th, 2008

There probably aren’t many better places to have a beer and talk about GNOME, the universe and everything.

EDIT: Bit of a poor show on the communications front though– we knew nothing about the cake until it was finished (and have only just learned from Michael’s blog what it was for), or that we only had a few minutes to get off the boat the first time before it headed out again…

River cruise

A handful of my other photos of the evening on Flickr.

T -1 day

Saturday, July 5th, 2008

Like many of you, I’m sorting myself out tonight to fly to what will be my seventh GUADEC in Istanbul tomorrow. (I’ll actually be there for two weeks, as my wife is flying out after the conference to join me for a week’s vacation.)

Pleased that there’s a very healthy crowd of Sun desktop folks attending this year (18 at last count), and rumour has it we’ll have some OpenSolaris 2008.05 LiveCDs to be giving away, so you can play along live with John Rice’s talk :) Hopefully I’ll also find a few interesting things to snap with the Lomo Fisheye camera I got for my birthday last month…

Rockstars and decadence

Saturday, June 7th, 2008

I started writing this as a comment on Andy’s post, but it ended up quite long so I decided to blog it instead :)

From a user’s perspective, I’m inclined to agree—to put it bluntly, I can’t really recall the last major innovation I saw on my GNOME desktop. After all these years, we’re still mostly working on things that Windows and, more recently, OS X, can do for us already if we’re prepared to pay Apple or Microsoft for the privilege.

Clutter is one such example—it’s a promising technology for developers, and maybe it will turn out to be a “way out” of the “decadence” Andy describes. But if we just use it to write clones of Front Row or CoverFlow or any of Apple’s other CoreAnimation-based apps, then Apple will have moved on again by the time we’re finished and we’ll just be playing catch-up again.

In any case, Clutter is just a toolkit, and toolkits don’t help us with the vague lack of coherence and integration on some parts of our desktop today, or the need for more clarity of purpose going forward. For that I applaud Havoc et al.’s vision of an online desktop—while it’s not one that desperately excites me personally, I don’t have anything better to propose, and having everybody focusing on something is surely better than nobody focusing on anything :)

As for the HIG—I really don’t believe that it stifles creativity any more than (say) Apple’s HIG stifles theirs, but it probably has been a victim of it’s own success to some extent. It was written six years ago, and as such, it describes the best practices for six-year-old GNOME apps. We do have plans to substantially revamp it, but it won’t happen overnight.

That said, the HIG shouldn’t drive major changes in GNOME’s UI, it should reflect them. But at the same time, the gtk guys (and others) need to know what changes to make for 3.0 that will support the sort of changes we might want to make going forward.

Everybody probably just needs to get talking and generate ideas to move that process along again, but I also wonder if maybe we don’t have enough rockstars in our community right at the moment—it’s much easier to reach a goal when two or three people are driving you there, than when a hundred people are all trying to make their own way.

I suck

Saturday, May 3rd, 2008

I’ve been pretty badly neglecting my community duties recently… I have a backlog of ~2000 usability and HIG bugzilla emails to get through, and haven’t fixed any gnome-themes bugs in months. (I have at least started updating all the HIG images with the ones we got from the GHOPpers at the turn of the year, but still a good bit of work to do there, too.)

Sorry about that. I started making a bit of an effort this week to try and get through at least 10 of those bugzilla mails a day, and uploaded a few more of those HIG images last night too. I hope to continue in that vein for the next few weeks, at least…

Red cheese

Wednesday, April 23rd, 2008

Daniel, I suppose the first question is “why does it need to be red?” Anything that animates is going to catch the user’s attention anyway, so I don’t see any great harm in keying the background to the theme.

That said, since gtk+ 2.10, haven’t themes been able to support additional named colours, to highlight things like ‘errors’ and ‘warnings’ where appropriate? So shouldn’t Clearlooks and the other themes be providing these now? Or did we just never decide what the standard list of named colours should be? :/

CHI 2008

Monday, April 14th, 2008

Back in Dublin after spending last week at CHI 2008 in Florence. I posted a few entries over on Sun’s design blog while I was there: [Day 1] [Day 2] [Day 3] [Day 4]

Main takeaways of GNOME interest, in no particular order:

  • I/we really need to get the HIG moving again, preferably in a less monolithic fashion
  • It will be really cool to see what sort of insight the InGimp data analysis gives us, and whether it would be feasible/worthwhile transferring the idea to GNOME.
  • There still really aren’t many people working on open source usability projects, even in academia :/