Re: Re-inventing Metatheme

[Lars Weber <lars brokenbits de>]

Bill Haneman <bill haneman sun com> wrote:
> >  * 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.?

Almost certainly. :)

But perhaps the more interesting questions are how people will like it
once they discover where these settings are, how fast that would be and
how fast they would adapt to it's usage.  And of course it would also be
nice to know what the experience of people without any prior
desktop-experience would be.

As for the fonts I think that this is actually one of the settings for
which there should also be a seperate menu entry.  Not only are fonts to
at least as large an extent an issue of usability as they are of nice
appearance, I also think that, even with an extensible metathemer, it
should in the general case be highly discouraged to include custom fonts
in a theme (for reasons that have already been mentioned elsewhere in this
thread).

Themes that are shipped with Gnome for example should never include a
custom font (except maybe in the special case of accessibility themes) I
think.

If you now also leave out the background setting, which is also (and even
more intuitively) accessible from the context menu of the desktop, then
the settings that remain are mostly ones which users don't want to change
individually in most cases I think.  Therefore, grouping them all together
in a `Desktop Appearance' dialog, which makes it easy to set them all at
once, and optionally allows to tweak the individual settings of the theme
(as a nice bonus feature), seems to be a quite natural thing to do.

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

This would of course be another option.  However, I think it is desirable
to keep the interface of the dialog as simple as possible; and given the
fact that backgrounds and fonts are only optional (or even discouraged)
such checkbuttons might not only be unnecessary but even a little bit
confusing for the user.

If backgrounds or fonts are only used in a very small number of themes I
think a pop-up dialog might just be the best thing to do.  Whats more, it
might actually even serve as a reminder for theme-authors that including
backgrounds or fonts in a theme is usually a bad thing to do :-)

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

Yes, maybe.  But unless the user starts tweaking the individual settings,
restoring the original theme is usually only a single-click action.

Additionally I think unusable themes should be considered a bug as any
other software bug -- and people that download their own themes from the
net should be expected to at least basically know what they are doing.

But that's a pretty idealistic point of view I guess.  Many distributions
will likely include all kinds of broken themes, and adding a cancel button
doesn't really add that much of complexity to the dialog either.

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

Was that only before, or still after you have seen the screenshot below?
In which way are you unsure about what it does?

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

This seems like it would also be a workable design, and maybe far better
than what I'm proposing.  But it's also in many crucial ways different
from my current idea, so for the rest of this mail I'm still going to
focus on what I've written about earlier.

In general it seems to me that the really important thing to discuss at
this point (and then also to eventually decide upon) is the broader
context of how the integration of a generic theming mechanism into the
desktop should be.  This is unfortunately also the most tricky part :)

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

If things like xmms- or mozilla-themes are integrated into the overall
theming mechanism, then I guess not being able to restore a basic
theme-set without also changing all these other settings might become a
little bit annoying even for personal use.

Another downside of this approach when compared to my (and also Seths)
proposal is that there would still need to be seperate entries in the
settings menu for things like gtk+ and window-manager themes; "degrading"
these settings to be only part of a broader (and much simpler) concept is
what I actually consider one of the biggest benefits of our designs.

But still, maybe what you propose is really the more intuitive and in the
end better way of integrating meta-themes.  I really have to think about
this a little bit more.

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

Under the following URL you can now find a slightly modified version of
this second screenshot in which I changed the description of the selected
setting to a description of what the Revert and Save buttons do (moving
the buttons also inside the frame while doing so).  Instead of the
replaced long description the earlier description of a settings' current
configuration (which wasn't that useful anyway) now shows a short summary
of what each setting does.

  http://brokenbits.de/lars/cruft/metatheme-edit-2.png

Regards,
Lars