My GEP 2 (metatheme) thoughts
- From: Owen Taylor <otaylor redhat com>
- To: desktop-devel-list gnome org
- Cc: bill haneman sun com
- Subject: My GEP 2 (metatheme) thoughts
- Date: Wed, 25 Sep 2002 17:19:07 -0400 (EDT)
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 188.8.131.52 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.
+ 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
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
For reference, what Windows includes in the theme
Standard desktop icons (which functions, what icons are used)
Color scheme (custom or precanned)
Mouse pointer scheme
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
+ 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
(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:
184.108.40.206 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
220.127.116.11. 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
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 18.104.22.168 ... if all
options set have to be exposed indivually as well, then they
are by definition visible.
22.214.171.124 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 126.96.36.199 seems to be:
+ Themes should be able to configure the size of text and
icons as well as settings which are strictly "graphic art"
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.
] [Thread Prev