My GEP 2 (metatheme) thoughts

[Owen Taylor <otaylor redhat com>]

Sorry for the last minute response here; I haven't had
a lot of time recently with GTK+-2.2 work and other stuff.

First thought - 

 * Themes are about making your desktop look pretty

Right now, the use case of selecting a pre-canned theme that
was created by a graphics artist isn't even in the GEP!
(Requirement 2.1.1.3 sort of gets at this issue, but other
than that, it seems to be an afterthought)

That's not to say that that selecting accessibility options
isn't important, or that it isn't related to themes, but if
we distort the idea of a theme too much (as a straw man, say
having a theme that starts up the magnifier) then we've
created a serious usability problem for users without
special accessibility themes.

Proposed requirement:

 + The theme selector interface should not be surprising
   to users who simply want to choose a pretty look
   for their desktop.

Second thought -

 * The simplification in the user interface that you
   get by saying that all themes have the same elements 
   is huge.

If you have a chance, compare the Windows XP theme 
dialog and the KDE theme dialog. I literally could
not figure out what some of the options in the second page 
of the KDE dialog did without reading the docs.

It's OK to include the font in the theme. It's OK
not to include the font in the theme. But if you
include the font in some themes, but not other themes
then you've made your user interface a lot more complicated
and confusing.

For reference, what Windows includes in the theme
is:

 Desktop background
 Standard desktop icons (which functions, what icons are used)
 Screen saver
 Widget style
 Color scheme (custom or precanned)
 Font size
 Font choice
 Mouse pointer scheme
 Sound events

How does this relate to the idea of having the theme system
extensible so, say, Mozilla or OpenOffice can participate?
I think it's very reasonable to say that if Mozilla is
participating in the theming, and the current theme doesn't
correspond to a Mozilla theme, then Mozilla should reset
itself to the default Mozilla theme.

The user expected the Mozilla theme to change. If there isn't
a Mozilla theme for the currently selected look, than is
it better to get the default Mozilla theme, or the 
MozillaImpressionist theme that was part of the last global
theme the user was trying out?

What does this mean for a requirement? Well, I'd say
under the UI section, we should have:

 + Effect of choosing a new theme should be predictable 
   to the user.

A corollary to this requirement is something that may be
more controversial:

 + Themes should be limited solely to visual aspects of
   the operation of the desktop. Characteristics of the
   desktop such as keyboard options, and the of running 
   applications should be unaffected.

If we view themes as arbitrary sets of arbitary options, 
than a good user interface is impossible. The user needs
to understand what a theme is. 

Although the examples in section 3.3 are all visual 
appearance, the word "look-and-feel" is used. If user
profiles including "feel" are needed, they need to be
done elsewhere. 

(KDE contains 'kpersonalizer', which is meant for 
selecting an initial set of settings, including both
look and feel.)


OK, now to turn to some of the particular items that are
currently in the GEP:

 2.1.1.2  Project should not introduce readily-exploited security problems.

The concern here is legitimate, but I think this is too
vague to be useful. (And how not-readily-exploited is OK? :-)
I think the generic text is "Project should not introduce
security problems."  But the specific issue that should be
mentioned in this GEP is:

 Consideration should be paid to possible security concerns
 resulting from installing untrusted theme packages.

If we consider installing theme packages as outside the 
scope of this GEP, then I don't see security as being an issue at
all.

 2.1.2.1.  Project must not make it easy (possible?) for the user 
 to take actions that cannot be reverted either via the project's 
 own UI or other dialogs.

I don't understand this exactly. Actions that can't be
reverted through the theme dialog are typical. What actions
would you expect that can't be reverted through other
dialogs?

I'd be tempted to make this stronger and say:

 + Themes should be solely a collection of options that 
   can be set elsewhere in the user interface.

(You might claim this is a constraint on a solution rather
than a requirement, but all requirements are constraints on
the solution. This one is just a bit more specific.)

The primary reason for this constraint is that if an option
can only be set by selecting a theme, then it means you
can't selecting it without destroying all the other options
for the user, and you also can't select two such options
in arbitarya combinations.

The above would also cover handle 2.1.2.2 ...  if all
options set have to be exposed indivually as well, then they
are by definition visible.

 2.1.2.3 Should support use case of switching physical displays,
   i.e. "LCD-to-projector" case.

I'm not quite sure why this use case ends up in the
requirements as well as in the use cases. Does this add any
extra constrains beyond the the requirements for
accessibility? The meat of this and 2.1.2.4 seems to be:

 + Themes should be able to configure the size of text and
   icons as well as settings which are strictly "graphic art"
   choices.

Use cases make poor requirements, because you can always find
more things that are needed for a particular use case
("I want to use different panel layouts the projector and
on the laptop screen")

 2.3.1 seems out of place in a requirements GEP.

In general, I think the GEP looks very reasonable. The main
point I've tried to make above is that if we want to come
up with something that is going to be easy to understand
for the user and feasible to implement, then we really have
to make sure that we very explicitly delimit the scope
of what we are trying to do with themes.

Regards,
                                        Owen