Re: Re-inventing Metatheme

[Bill Haneman <bill haneman sun com>]

Hi:

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.

The ideas so far sound good - but of course we have some comments:

* we agree with Maciej that the question "what is my current metatheme"
is a reasonable one, so it makes sense to have a metatheme gconf key;
this requires some way of persisting the metatheme/gtk-font-icon-etc.
key relationships.

* desktop background belongs in the metatheme, though of course it
should continue to be customizable

* users like to customize settings; I submit that if Jungle is selected
and the background image is then changed in the background capplet, user
should see "Jungle (custom)" as the current theme.

* we should have a "create new metatheme from current settings" button;
this also implies a requirement for a corresponding "delete" button.

* since there will undoubtedly be some apps that don't follow the gtk+
theme, there is still need to accommodate additional gconf keys in our
metatheme back-end implementation.  (using gtk+ themes and icon sets is
preferable but we need to build in extensibility and flexbility).

* the point of the metatheme is to group and simplify, thus the number
of UI elements should be kept to a minimum: we suggest

	1) scrolling list of metathemes by name, with "custom" 		indication if
user has further modified gconf keys
	2) 'create new' button that "snapshots" current keys and pops up
		"Name for new theme" dialog
	3) 'delete' button
	4) a preview/snapshot of the theme, when available.

	and possibly
	5) "revert" button that reverts a "custom" metatheme to the 	metatheme
defaults

pressing the revert button (or toggling the checkbox) would be the
equivalent of re-selecting a theme which has been customized. 
Alternatively the function of #5 and the 'custom' indication could be
combined into a single checkbox, if the resulting semantics were not too
confusing (i.e. the checkbox indicates whether the current theme is
customized, and un-checking it reverts the current theme).

Calum and I will try to post a mockup later today.

With respect to issues of back-end gconf key organization, it matters
less to us as long as the effect is achievable; however we do think that
some extensibility is important for including gconf keys other than
those for existing gtk+ themes, fonts, background, etc.  In other words,
a metatheme would be, in the most general form, a named collection of
gconf key-value pairs that affect various parts of the UI appearance and
behavior, which can be applied as a group via a simple dialog such as
the one we describe above.

best regards,

Bill