Re: Re-inventing Metatheme
- From: Lars Weber <lars brokenbits de>
- To: Bill Haneman <bill haneman sun com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Re-inventing Metatheme
- Date: 30 Aug 2002 21:23:27 +0200
Bill Haneman <bill haneman sun com> wrote:
> Since the accessibility team has some requirements around Metatheme,
> including a couple which we think argue strongly for the existance of a
> metatheme mechanism as part of the core desktop, I thought I'd try to
> summarize our perception of what a metathemer needs to do.
[...]
A little over a month ago, just after installing the current metatheme, I
also started wondering about what the best way of integrating such a
mechanism into the desktop might be. The ideas and requirements I came up
with at that time do to a large extend correlate to those ideas offered in
your and also many other peoples posts.
In addition to thinking about the general concept I also created a
Glade-prototype of what I thought might be a good interface for
theme-selection and editing.
Some general points:
* While it might be worthwhile to try to unify the storage and
distribution of theme-related files (as was proposed in the first post
of this thread) I tend to agree with Havoc that the implementation of
the dialog should be independent of such conventions and simply use the
current (and future) GConf-keys instead. (The themes themselves would
then likely be defined through a simple xml file listing the name, a
short description and the individual settings of the theme.)
* To me personally, the favorite way of integrating the theme
functionality into the current settings menu is to make the generic
theme-selection dialog the main entry-point to all (or almost all)
appearance-related settings. This way there would still be seperate
dialogs for the individual settings but there would only be a single
appearance-related settings item in the menu (my personal take on the
name is "Desktop Appearance") and the other appearance-related dialogs
would only be accessible indirectly through the same.
(The above, however, isn't meant to rule out other indirect ways of
accessing certain appearance related dialogs in a similar way to what
is currently possible with the background-settings through the
context-menu of the desktop.)
* While I decided to use an extensible list of theme-settings in my
design I can also see the problems related to changing things like
backgrounds or fonts in such a dialog. Asking the user in such
situtations whether he also wants to apply these changes might be a
good idea.
* Another problem related to extensible theme-sets is that if a user
first selects one theme and then another one which only uses a subset
of the settings that were used by the first theme, the result is a
desktop that uses a mixture of both themes. A workaround might be to
always apply a themes' settings to the settings as they were before
opening the 'Desktop Appearance' dialog.
The dialog:
* The dialog I came up with only contains a notebook with two pages: one
page for the defined themes and one page for the individual settings.
* The theme-selection tab is extremely simple and only contains a list
of defined themes and two buttons: `Add New Theme' and `Remove Theme'.
However, the list of defined themes does not only contain the
theme-names, but also a short description of the theme and a small
icon giving at least a quick idea of what the theme might look like:
http://brokenbits.de/lars/cruft/metathemes-themes.png
(Yes, the design of this page is basically copied from the
theme-selection setting of Nautilus.)
* As you can see in the screenshot I decided to go with an instant apply
dialog (and therefore also left out a theme-preview as it doesn't make
that much sense for instant apply).
At the time I created the dialog I didn't even know that a special
"1-second-until-changes-take-effect" criteria for choosing instant
apply existed. But even while I don't feel as confident now about
this decision as I did before, I still tend to prefer instant apply
personally. The reason is that, while it definitely will take some
time until all changes have been made, it will likely not be that long
until changes *start* to appear (and also likely to appear in a pretty
visible way) and from what I can tell this mostly cancels the bad
effects of instant apply with dialogs that take a long time to apply
their changes.
* As for the situation where a customized version of a previously
selected theme is used I came up with basically the same idea as has
been mentioned here as well, that is, to either display a seperate
"Custom theme" entry in the theme list (maybe also mentioning the
original theme in the description; e.g. "This is a modified version of
theme FooBar."), or to display something like " (customized)" next to
the name of the modified theme (and then also have a 'Revert' button
on the 'Individual Settings' tab).
Thinking about the two choices I personally tend to prefer the second
one. Saving all changes previously made to all themes (without
explicit saving) and giving a way to restore the original settings
seems like a a nice way for such a dialog to behave.
* The design of the editing-interface was a little bit more tricky.
Leaving the layout aside for a moment, the central element of the
interface will be the list of available sub-settings. As I think the
number of possible sub-settings should not be fixed, the list should
only show the settings defined by the current theme so as to allow for
many different themeable settings without forcing a huge list of
unused settings down the users throat. For this reason there also
needs to be something similar to 'Add setting' and 'Remove setting'
buttons in addition to the list.
Other needed interface-elements are: a way to configure the setting
currently selected in the list and a 'Save...' button to save the
current settings as a new theme. Depending on how changes to themes
are handled a 'Revert' button is also needed.
Nice would also be a preview of the currently selected setting because
with individual settings the instant apply happens only in the dialogs
launched by the 'Configure...' button. Alternatively there could of
course also be a mini-"preview" on the left-hand side of each setting
just as in the list of themes on the first tab. In this case,
however, I personally think it would be better to use generic icons
instead as I also did in my mockup below.
A last thing I used in my design is a short description of what the
currently selected setting does.
Anyway, here is the screenshot:
http://brokenbits.de/lars/cruft/metatheme-edit.png
* One of the problems I see with my current layout is that it isn't
completely obvious what exactly the 'Save...' and 'Revert' buttons do.
Ok, that's it for now. Sorry for the long mail!
Regards,
Lars
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]