Re: REMINDER: GEP-2 discussion end date

[Havoc Pennington <hp redhat com>]

Seth Nickell <snickell stanford edu> writes:
> http://www.gnome.org/~seth/theme-set-editor.png
> http://www.gnome.org/~seth/theme-set-selector.png

The nice thing about this setup, to me, is that it can just replace
the current Theme dialog (and the current dialog is well on its way to
having too many tabs and generally sucking as we add new component
themes). We could move toward making "theme" mean "metatheme."  That
beautifully answers the question of how much extra clutter this adds
to the menu - none.

Bastien - do you need to say "don't apply a certain part of the theme"
when you could just duplicate the theme, change the relevant part to
what you want? e.g. if you want all of a theme but keep your current
icon theme, you Duplicate the theme, edit it, change icon theme to
your current one, then apply the theme. Seems workable.

One reason metathemes as the main theme concept is nice is that it
means people can move between say Bluecurve and Default GNOME and
Keramik and Gorilla and whatever with only a single click.

Is the set of "component themes" and the set of "suggestions" (font,
background) extensible? I would say both should be extensible in the
sense that we can add more items while still supporting old themes,
but not extensible in the sense that themes can make up new items to
add that aren't known to the theme control panel.

What do you do if a theme is missing a given theme component?  I'd
suggest that the theme be presented as containing some default theme
component. For example, all themes not containing a GTK+ theme
component show up as containing the default GTK+ theme. The other
option is that the given component is "unset" and will not be affected
when choosing the theme; I don't like that because it means the order
in which you move through the themes affects what you see. Also, it's
hard to explain in the GUI.

How do we present "foreign" themes? For example, we would want to
allow changing Mozilla, Qt, XMMS toolkit themes. Do those get lumped
into Controls (and the various theme implementations are linked by
identical name), or do they get broken out somehow? I think the former
is right.

If this dialog is instant-apply, why have the preview?  Or is the
preview only if instant apply turns out to be a bit too slow?

Are "Apply Font" and "Apply Background" OK from an accessibility
standpoint? If we had more than two items there, what if there were an
"Apply All Suggestions" button? Or how about an "Automatically Apply
Theme Suggestions" check box that, if checked, would make theme
suggestions auto-apply when you selected a theme?


There seems to be quite a lot of implementation work here, if you
start looking at it. Export Theme should IMO actually _copy_ all the
component themes into one big tarball, and the Theme control panel
should be able to install a giant tarball like that, and also be able
to install single component themes. The implementation should know
about Qt themes, XMMS themes, etc., not just GTK themes.  And there's
a gmarkup or XML parser to write for the theme format itself.

If we get extensibility right so we can add things in the future and
support all the various backend theme types, and get install/export
theme right, and make the whole thing robust with nice error handling,
it's looking like a ton of work. Someone needs to sit down and bang
out the first draft in the next few weeks if we're going to make 2.2.

Havoc