Re: Re-inventing Metatheme



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]