Re: Re-inventing Metatheme

[Bill Haneman <bill haneman sun com>]

On Fri, 2002-08-30 at 20:23, Lars Weber wrote:
> 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.

Cool!

> 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.)

That's my opinion too, FWIW...
 
>  * 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.

This is an interesting proposal, seems reasonable... but will we get
complaints about "where did the Font capplet go?", etc.?

>    (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.

That's an interesting idea too.  
Instead of asking every time, 
maybe the 'metatheme' capplet should have two more checkbuttons, "use
Theme Set's Font" or "Override User Font" or something,  
and "Allow Theme Set to change Background", (or "Keep User Background",
"Preserve User Font"....  we could discuss the wording).
 
>  * 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.

Yes, that's a great idea.  Calum and I were discussing this, we think
something that could wreak as much havoc on the desktop as this capplet
should have a "Cancel" button that would revert the state to whatever it
was when the dialog was posted, and maintaining the initial state in
that way would enable your suggestion.  Otherwise, you are quite right,
you'd get inconsistent or mixed sets.
 
> 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.

I agree, except that I am not sure what the "Individual Settings" tab
would do exactly.

The business of editing theme sets worried me; I really think it would
be preferable not to duplicate controls that might be in other
capplets.  Thus to 'edit' a Theme Set you'd go to the individual
preference dialogs (wherever they are), then just use a "Save Current
Settings As..." button that would snapshot the current settings.

The only additional control I see there is that you might want some
level of control over which settings were included in the resulting
snapshot, to address Seth's concern about users not wanting to include
background and font... but I am not sure that in this case, if the user
is snapshotting a theme for their own personal use, the same logic would
apply.
 
>   * 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!

Thanks!

-Bill
 
> Regards,
> Lars