Re: REMINDER: GEP-2 discussion end date
- From: textshell neutronstar dyndns org
- To: GNOME Desktop Hackers <desktop-devel-list gnome org>
- Subject: Re: REMINDER: GEP-2 discussion end date
- Date: Sun, 29 Sep 2002 00:09:53 +0200
On Sat, Sep 28, 2002 at 08:48:35PM +0100, Bastien Nocera wrote:
> On Sat, 2002-09-28 at 20:37, Havoc Pennington wrote:
> >
> > 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.
>
> My main problem would be with the editing part. Ie. I have these 2
> themes I want to mix. I apply the first one without the background, the
> second one with the font, and I can then save a third theme without a
> problem.
>
> It goes especially true if we get more "parts" supported like you say
> below. This was the way the good ol' Window 9x themes panel worked, and
> I think it was very usable, and fits exactly in what we're trying to
> achieve.
>
Please don't do this. It's really a usablity nightmare. I tried to explain that
to a novice user (well not stupid, but coming from dos). It doesn't work. I'd
even say if that's a usage we want to support the editor should have a "copy
this part from another theme" button. Then your use case is easy and eligant.
Copy the theme that's mostly right.
Copy/merge some parts of other themes into it.
Be happy.
> > 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.
> >
Havoc is 100% right with this. Using unset or not wanted by the user as keep
previous setting is bad and impossible to explain in a UI (at least with
resonable about of programming work).
But if we havyly depend on theme changes by the users, it might be a good idea
to protect some (system) themes. If the user tries to change these themes his
changes are saved in a new copy (same name with personal appended for example).
This would ensure that there is good theme to go back in all cases.
Martin H.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]