Re: Clarius

On Tue, 2006-08-29 at 10:01 +1200, Glynn Foster wrote:
> Hey,
> Shaun McCance wrote:
> > I'm going to coin a new term: key churn.  This is when people
> > make frivolous and unnecessary changes to GConf keys or their
> > default values.  It sucks for large deployments.  Gnome is
> > bigger than your personal desktop.
> I don't really care too much about the name change, but what I do care about is
> the migration story between themes as new engines/icons/whatever are dropped in
> and out. This stuff isn't as smooth as it should be - hopefully Calum can
> provide details of what currently happens [we documented this for an ARC case
> recently].

It seems to go something like this (at least on the 2.15 machine I was
using to experiment with it):

1. If you're using an installed theme, and its index.theme file
disappears as a result of an upgrade, your current theme will become a
"Custom Theme" in the theme capplet.  If you then drill down into the
theme details dialog, it will initially show as still being comprised of
the gtk, icon and metacity components that originally made up that
theme, even if they're no longer installed either.  But... if you then
select a different gtk, icon or metatcity theme, the list is refreshed,
and any non-existent components then disappear, which could be a bit of
an unpleasant surprise for the unsuspecting user.

Assuming you don't try and edit the theme in that way, you'll just get
console errors whenever an application tries to render something that
would have used any of the now-non-existent theme components, and the
default theme will be used instead. Which seems to mean 'gnome' for
icons or controls, and 'Simple' for metacity-- *not* the defaults
defined by the gconf schemas.

2. If a theme's index.theme file remains after an upgrade, but one or
more of its three components are no longer installed, on opening the
theme capplet your theme is shown as selected, as if nothing was wrong.
When you drill down into the details dialog, though, the behaviour is
the same as case 1... the 'phantom' theme components are shown as
selected, until you select an alternative instead, at which point they

3. If a theme engine disappears, you're given no warnings at all in the
theme preferences UI, just a console error every time something tries to
use the non-existent engine.

I guess the 'phantom component' behaviour is actually intentional-- you
wouldn't want to permanently switch the user's settings to some
different component when the previous one couldn't be found, because
they might just be temporarily logged into a machine that doesn't have
that component installed.  However, the theme capplet UI could probably
do a much better job of indicating that the selected component wasn't
currently available, and that a fallback was being used instead.


CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            Java Desktop System Group                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]