Subject: Colorset usability issues

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 12 Oct 2003 15:36:51 +0300

I suggest these colorset usability things:

1) New colorset option "Clear" or "NoEffects" depending on what it does
that removes all effects from a colorset, it may be aproximately
equivalent to:

  Colorset N NoDither, \     # not sure about this one
    Tint, fgTint, bgTint, Alpha, fgAlpha, IconTint, IconAlpha, \
    Plain, NoShape, fg, bg   # not sure about these 4

This is intended to be used in dynamical configurations as in:

  Colorset N Clear, fg .., bg .., VGradient ..  # set completely new colors

I.e. it either resets all effects leaving only fg/bg/image/gradient or
resets everything. Both are ok for me. Probably reseting everything is
preferred. In this case Clear may work like CleanupColorsets just on a
single colorset.

2) It seems to me that whenever I do "Tint color percent" I always want
to do "bgTint color percent" too, otherwise the sh/hi colors look
incorrectly. So I think, "Tint" should also set "bgTint". If someone
really wants the current behaviour (doubtly), he may always reset
"bgTint", i.e. "Tint cyan 20, bgTint". For most of cases bgTint will be
redundant with this proposal.

3) It seems to me that whenever I do "Transparent" or "RootTransparent"
I always want to do "bg average" after that. I remember the last time we
discussed this it was rejected, since it takes time to evaluate average.
However most of users will need to do it anyway, just explicitely.
I think "bg average" should be implicetely set after every background
image/gradient/transparent change.

I think this may be solved nicely in this way. Initially or after "Clear"
or after "bg average", bg is set to be "average"-ed on every background
change, hovewer after explicit bg setting, the auto-averaging is off.

Olivier, please comment.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 13 Oct 2003 00:03:10 +0200

> redundant with this proposal.

What about using fvwm functions

AddToFunc SetClearColorset
+ I Colorset $0 ... clearing ...
+ I Colorset $*
 
AddToFunc SetColorsetTint
+ I Colorset $0 Tint $1, bgTint $1

The colorset code is delicate. As we are in feature freeze I am not
very motivated to change some code which seems bug free (for some
minor feature).
 
> change, hovewer after explicit bg setting, the auto-averaging is off.

I disagree. "bg average" can be very slow and can use a lot of
(dynamical) memory. It can also reduce fvwm usability under certain
situation, e.g., FvwmBacker big bgs => 2 secs or more for switching
between desks (colorset FvwmBacker bg can solve this but you should
have all your bg in memory ...). I think that it is better that the
user set "bg average" itself (there is a "warning" in the man page, he
takes his responsibility).

By the way, I think we should fix this problem: when the bg is big
the average bg colour can be computed on a random subset of points
of the bg.

Regards, Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 13 Oct 2003 02:39:34 +0300

> + I Colorset $0 ... clearing ...

This is more or less practical except that it is hard to suggest this to
users and they will need this to ensure no previous Tint/Alpha is left.

> + I Colorset $0 Tint $1, bgTint $1

This is not practical at all, Tint is always only one of the several
options, doing it on a separate line does not help to what I try to
achieve, to minimize the syntax for a correct look.

> very motivated to change some code which seems bug free (for some

It is very difficult to argue arguments like these, I don't want bugs
myself, but I will try. :)

If we will always need to use such SetClearColorset function and never
the original Colorset command in fvwm-themes or other setups with dozens
of colorsets, then I feel it is not a minor feature, but a misfeature of
Colorset command, leading to an unneeded overhead (calling functions).
It will also lead to flickering, if it is done using 2 Colorset commands
like suggested above. (Yes, it may be done using one Colorset command.)

I feel that having different Tint and bgTing is almost always incorrect,
we should not default to this.

I would like to have both of these things built-in since they seem
essential to me (Clear option and making bgTint redundant).

> takes his responsibility).

Having to specify "bg average" explicetely is not very important for me.

I just wanted the novice user not to worry about anything when he
specifies Colorset Transparent. Currently when someone asks about
transparent menus or modules (this happens and will happen all the time),
the correct good looking answer is:

  Colorset 9 RootTransparent, bg average, Tint black 20, bgTint black 20

I hoped, the answer should be (with the same results) just:

  Colorset 9 RootTransparent, Tint black 20

This is more understandable, the previous line is less intuitive.

But again, exlicit "bg average" is not a real problem for me.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 13 Oct 2003 09:12:44 +0200

> preferred. In this case Clear may work like CleanupColorsets just on a

I prefer resetting individual options with the '!' prefix:

  Colorset n !bgTint, !fgAlphaa, ...

> image/gradient/transparent change.

@2,3:  This kind of automagically setting options when something
else is used has caused me great pain in the past:

  - The result depends on the order of commands:
      Colorset n Tint x, bgTint y
    is not the same as
      Colorset n bgTint y, Tint x
  - The above is confusing for the user
  - It's often impossible to enhance the featureset without
    breaking compatibility (e.g. see the new focus policy styles).
  - It's much more difficult to change later.

In my eyes, a big fat comment in the man page should do.

> change, hovewer after explicit bg setting, the auto-averaging is off.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 13 Oct 2003 15:03:23 +0300

>   Colorset n !bgTint, !fgAlphaa, ...

The resetting already works if you don't suply an argument in any
option like fgTint (reset to none), fgAlpha (reset to 0), fg (reset to
black), sh (recalculated from bg), fgsh (recalculated from fg+bg).
We don't need to invent new syntax here.

I only want a shortcut "Clear" instead of specifying a dozen of options
like shown above (and in the future we will have more such options).

>   - It's much more difficult to change later.

Such argument would be right if not one fact. In 99% of cases the user
does not want a separate bgTint. Having a separate bgTint is confusing.
It is much less confusing to always do just:

  Colorset n Tint blue 15

and get the needed result. Similarly this removes the tint (and bgTint):

  Colorset n Tint

So I suggest either to remove a separate bgTint option completely or make
it invisible to the user. If you are still not convinced, suppose that in
the future we add shTint and hiTint, and they are not autocalculated,
then it is "Tint red 20, bgTint red 20, shTint red 20, hiTint red 20"
just to tint anything, because the old code "Tint red 20, bgTint red 20"
does not now do what is expected for shadow colors. This is bad.

There are by definition fields (like sh, fgsh or bgTint) that should be
automagically set. The user usually does not worry about sh and fgsh, it
gets them for free. The same should be done with bgTint.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 13 Oct 2003 14:41:59 +0200

> We don't need to invent new syntax here.

I see.

> it invisible to the user. If you are still not convinced,

I am now convinced that "Tint" is a bad name and should have been
imageTint from the start.

> suppose that in
> does not now do what is expected for shadow colors.

Images don't have a "shadow" or "hilight" colour, so this can not
happen.

> This is bad.

But can be fixed with a conversion script.

> gets them for free.

This is wrong.  The sh and fgsh colours are *not* set by
specifying the fg, they just have a well documented *default* in
case they are not specified otherwise.  Automatically setting
bgTint would be quite different as it overwrites user preferences.

There is some similar logic in the menu code, and it's hell to
maintain.  As we can not provide a sensible default for bgTint
(for performance reasons), I am for simply documenting this.  I
mean, if someone is too impatient to read five lines of man page
to correctly configure tinting, there is little we can do.

> The same should be done with bgTint.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 13 Oct 2003 16:48:03 +0300

On 13 Oct 2003 14:41:59 +0200, Dominik Vogt wrote:
> > > > 2) It seems to me that whenever I do "Tint color percent" I
> > > > always want to do "bgTint color percent" too, otherwise the sh/hi
> > > > colors look incorrectly. So I think, "Tint" should also set
> > > > "bgTint". If someone really wants the current behaviour
> > > > (doubtly), he may always reset "bgTint", i.e. "Tint cyan 20,
> > > > bgTint". For most of cases bgTint will be redundant with this
> > > > proposal.
> > > 

No, it should be called "ImageOrGradientOrShapeTint" or just "Tint". :)

(I didn't actually check the relation between Tint and Shape.)

> Images don't have a "shadow" or "hilight" colour, so this can not

This is incorrect, images or gradients placed in a 3d frame (in menus or
modules) do have shadow and hilight colors. Use "bg average" to see that
these colors match the image well.

If you want an example:

  Colorset 40 fg white, bg average, TiledPixmap fvwm_icons/bckgnd1.xpm
  MenuStyle * MenuColorset 40, BorderWidth 3

Now, do this:

  Colorset 40 Tint yellow 20

Note how the shadow/hilight colors do not match the tinted image anymore.
For the correct look you also need (that I try to make redundant):

  Colorset 40 bgTint yellow 20

> bgTint would be quite different as it overwrites user preferences.

Sorry, Dominik, you are wrong again. Do "Colorset 1 bg gray" to see that
all of the "sh", "hi" and "fgsh" are recalculated. This is a great thing.
Otherwise the colorsets would be unusable.

> to correctly configure tinting, there is little we can do.

I think you mix here the default values with the "reset x if y is set"
logic. The default for Tint and bgTint is always "black 0". Of course
with my suggestion the default for bgTint will be the current Tint value.

It is not hard to maintain. This simbolic code is everything needed:

  if (option == "Tint")
  {
    new_value = argument ? argument : "black 0";
    tint_value = bgTint_value = new_value;
  }

  if (option == "bgTint")
  {
    new_value = argument ? argument : tint_value;
    bgTint_value = new_value;
  }

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 13 Oct 2003 16:04:47 +0200

> No, it should be called "ImageOrGradientOrShapeTint" or just "Tint". :)

Nope.  Maybe "AnythingButFgBgShOrHiTint".  I confess that I'm not
deep enough into the tinting code.

> these colors match the image well.

But the image still only has a foreground and background colour.
Anyway, we were talking about simple, out-of-the-box setups.
And with the same reasoning you'd have to demand that the "bg"
option is set automatically when the "fg" option is used.  As the
default bg is a light gray, using "fg white" results in an
unusable

[snip]

> Otherwise the colorsets would be unusable.

Argh!  This has to be changed - there is no excuse for it.  I'm
not against providing the same value as the default (which is
quite easy to code), but overwriting user preferences is bad.

>     bgTint_value = new_value;

Well, you can only claim it's not hard to maintain because you
have never stared at such code for hours, trying to come up with
an extension that does not change old behaviour and provides new
features at the same time.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 13 Oct 2003 18:12:07 +0300

> deep enough into the tinting code.

After Tint starts to work like I suggest, it could be named
"AnythingButFgTint" or just "Tint".

> default bg is a light gray, using "fg white" results in an

I will never want to create the "fg" and "bg" dependancy, because there
is a very legitimate reason to set bg and fg independently. There are
literally millions of fg colors that look well on some fixed bg. There
are much-much less sh+hi combinations that look well with some fixed bg
(and they are hard to manually calculate). And there is usually only one
bgTing value looking well with some fixed Tint value.

So, I would not mix this all.

> quite easy to code), but overwriting user preferences is bad.

Well, all fvwm-themes versions (3.5 years for now) depend on this feature
that bg overrides sh and hi, it is a very good and well defined feature.
There is no reason to leave the old hi when bg is changed.

The reason for one or another behaviour is to simplify the life of users.
The current behaviours does this. Your suggestion would make it tougher.
It is meaningless for me to _always_ do "bg something, sh, hi" instead of
"bg something". In rare cases when I want a non automatic "sh" I will set
it explicitely, and _never_ use the previous "sh" value.

> features at the same time.

I can't argue with this.

However I know that the "setting x resets y" is a very natural feature
where appropriate.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 13 Oct 2003 19:49:54 +0300

>   - The above is confusing for the user

I didn't comment on this previously, but there is no problem here.

Currently the following 2 lines are equivalent:

  Colorset 40 sh yellow, bg gray
  Colorset 40 bg gray, sh yellow

I.e. bg resets sh only if it is not specified in the same command.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 14 Oct 2003 10:16:25 +0200

> that bg overrides sh and hi, it is a very good and well defined feature.

Then you will have to adapt fvwm-themes to issue something like

  Colorset n fg xyz, sh, hi

instead of

  Colorset n fg xyz

> There is no reason to leave the old hi when bg is changed.

There is, as I already explained:

  Colorset n bg yellow, sh black, hi black

yields a different result than

  Colorset n sh black, hi black, bg yellow

> The current behaviours does this.

And the proposed behaviour does it too.

> Your suggestion would make it tougher.

No.  See below.

> It is meaningless for me to _always_ do "bg something, sh, hi"
> instead of bg something".

And of course you don't have to.  You need to reset sh and hi
*only* if you specified them before.

> In rare cases when I want a non automatic "sh" I
> will set it explicitely, and _never_ use the previous "sh" value.

[snip]

> However I know that the "setting x resets y" is a very natural feature

Fvwm history shows that it is almost never appropriate.  It is
usually confusing (order of statements does matter), and hard to
extend (e.g. menu item hilighting logic).  Using defaults that are
calculated on the fly yields better results almost all the time.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 14 Oct 2003 14:48:47 +0300

On 14 Oct 2003 10:16:25 +0200, Dominik Vogt wrote:
> > > > > > There are by definition fields (like sh, fgsh or bgTint) that
> > > > > > should be automagically set. The user usually does not worry
> > > > > > about sh and fgsh, it gets them for free.
> > > > > 
> > > > Sorry, Dominik, you are wrong again. Do "Colorset 1 bg gray" to
> > > > see that all of the "sh", "hi" and "fgsh" are recalculated. This
> > > > is a great thing. Otherwise the colorsets would be unusable.
> > > 

_I_ know what to do if you decide to make it harder to use. I know that
fg only resets "fgsh", not "sh" and "hi". I would worry for other users.
They should not be forced to _always_ do "fg xyz, fgsh" instead of just
"fg xyz". Because the old fgsh will look bad with pretty much any new fg
and they can't remember whether they changed fgsh previously in this
colorset or not.

The beginning users want to only change "fg" and "bg" and don't know
about any small details, just know that all details are successfully
recalculated for them. The advanced users in some cases want to use the
autocalculated details and in some cases may want to adjust them.

>   Colorset n sh black, hi black, bg yellow

Wrong, these lines are equivalent. Did you get my message about this?

> And the proposed behaviour does it too.

Your behaviour does not make it easier for static setups.
It makes it both hard and wrong for dynamic setups.

Using the previous value of hi, when the new bg is set is _always_ wrong.
And in the very rare cases when one wants to preserve it, it is possible.

This is not like some global feel setting that you once set and don't
want to change ever (like !MouseFocusClickRaises). This is colors. You
can't say I want to fixate the sh color regardless of other colors. sh is
not independent, it is very dependent on bg.

The current bg-sh behaviour is ideal for users. Did you ever hear someone
complaining?

> *only* if you specified them before.

You can't make any guess about the previous color theme, so you should
ask everyone to modify their colorsets to the new incompatible behaviour.
Note that this modification does not simplify things, it only adds the
redundant resetting of _all_ details (and probably more in the future).

Also note that I am not against reseting of all existing details on the
_complete_ colorset change, this is why I need the Clear option.
However I see no reason to introduce incompatibility with the current
perfect "change of bg changes sh too" behaviour.

> calculated on the fly yields better results almost all the time.

I would like you not to use such vague (and non-verifiable) arguments
like "fvwm history shows" or "you have never stared at code for hours".
Because I may say that "fvwm history shows" that the current bg-sh
behavious is the best for the users and I don't understand you wanting
to break it. As for the developers, I thought implementing nice usable
solutions is supposed to be fun regardless of the difficulty.

If you really want to improve fvwm, I will soon sit and compile the
bug/annoyance list. :) Some seen bugs are hard to make reproducible.
And speaking about bugs, Olivier is correct that the current colorset
implementation is more or less bugless given the amount of the new code.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 14 Oct 2003 14:35:14 +0200

> autocalculated details and in some cases may want to adjust them.

*Sigh*  We discussed that already for bg/sh/hi.  The beginning
user does *not* need to do any of this as he/she won't be changing
fgsh in the first place.

> Wrong, these lines are equivalent. Did you get my message about this?

**Sigh**  You're just arguing for the kicks, right?

  Colorset n bg yellow
  Colorset n sh black, hi black

and

  Colorset n sh black, hi black
  Colorset n bg yellow

are *not* equivalent.

> Using the previous value of hi, when the new bg is set is _always_ wrong.

Except in the cases where it's right.  See above.

[snip]

> You can't make any guess about the previous color theme,

I don't care one bit about the previous theme.  Maintaining
fvwm-themes usability is your problem, not mine.  Don't claim to
be talking about fvwm's usability when you're actually talking
about fvwm-themes, which is irrelevant to me.

> like "fvwm history shows" or "you have never stared at code for hours".

Then stop arguing and look at the several examples of code where I
had exactly these problems.  You constantly accuse me of not
reading what you write, yet you are too lazy to even consider what
I am saying, or even follow the pointers I give you.

> to break it.

> As for the developers, I thought implementing nice usable

Sure.  Because you don't do the maintenance

> bug/annoyance list. :) Some seen bugs are hard to make reproducible.

Well, I *you* really want to improve fvwm, why don't you just
*fix* these bugs instead of annoying me with vague hints to bug
lists that you have been to lazy to compile for more than a year.

[snip]

As always, this discussion is pointless.  I will commit the
patches I have in mind soon and end it this way.  You can continue
to worry about fvwm-themes, and I will continue to worry about
predictable, flexible, well documented sytax and behaviour in the
fvwm core.

Over and out

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 14 Oct 2003 17:54:46 +0300

>   Colorset n sh black, hi black

I am happy that they don't work equally. Because in the second case the
user definitelly wants to use the yellow background and recalculate the
sh and bg colors to match yellow.

I am tired to repeat this argument. The "sh" color is not independent
from "bg" by its mere definition. Setting it in the separate line
before the "bg" line and expecting it to work makes no practical sence.

> about fvwm-themes, which is irrelevant to me.

I don't worry about fvwm-themes, it is clean and patching it for the new
behaviour is trivial. It will use Clear anyway (either Olivier or me will
add this option) and everything we discuss here will be irrelevant.
But I worry about users that unlike you change colorsets constantly in
FvwmConsole or similar. Ask them whether they want to specify "bg yellow"
or "bg yellow, fg, sh, fgsh" (and maybe more of these in the future) to
change the bg.

Do you change colorset definitions defined in your configuration? If no,
then why should you worry at all about one or another behaviour
implemented by other developers? I would at least try to find a reason
for it working this way.

> had exactly these problems.

If you speak about FocusStyle, it is huge and full of backward
compatibility issues. I don't think comparing FocusStyle with colorsets
is very correct. FocusStyle values are not supposed to be changed often.

> You constantly accuse me of not

I should agree that, yes, I feel you don't listen to my arguments.

I do understand your arguments to make the code clean. I think that
the "setting x resets y" logic does not make the code less clean if
implemented correctly. There are 2 calls of reset_y(), that's all. 
It is much less clean _for_me_ to keep a global flag for y indicating
that y was ever set by a user and have conditions based on it.

Of course, you need such local flag so that "Colorset sh s, bg b" works
equivalently to "Colorset bg b, sh s", so both behaviour implementations
are more or less equivally clean/unclean.

It ends up that for new things (without backward compatibility issues),
we should choose one or another behaviour based on the user needs, not on
the code issues.

> predictable, flexible, well documented sytax and behaviour in the

The situation is strange.

Tim coded this logic in 1999. Olivier enhanced it to work with fgsh too.
I try my best to convince you it is good. And you yesterday learned about
it and want to break it without asking Tim, Olivier and me.
Very constructive.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 15 Oct 2003 10:32:18 +0200

> sh and bg colors to match yellow.

Breaking long lines must never change the result of the issued
commands.  All relevant commands that have the potential to
generate very long lines work this way (Style, MenuStyle, Colorset,
BugOpts, ...) and the ones that do not are scheduled for removal
(ButtonStyle, TitleStyle, BorderStyle).  There is one documented
exception in Style:  IconBox and IconGrid, and I am not happy with
it.  We already had mails from confused users because they split
their style lines.

> add this option) and everything we discuss here will be irrelevant.

I don't care about a "Clear" option, except that the syntax is
bad.  We have way too many different ways to reset complex user
defined structures already (Styles, MenuStyles, Decors, Functions,
Menus).  Other than that, the intended behaviour is perfectly
acceptable for me.

> or "bg yellow, fg, sh, fgsh" (and maybe more of these in the future) to

This is perfectly predictable for the user.  If she just set sh
and hi, then change bg, it's perfectly clear why the old settings
are kept.

> implemented by other developers?

I think you are confusing my part in the colour set
implementation.  And, by the way, in the past I have been the only
one who ever worried about syntax, so it comes naturally that I
talk about it in this case too.

> is very correct. FocusStyle values are not supposed to be changed often.

You may also look at the menu hilighting code.  Or the MenuStyle
logic when the mwm/fvwm style is set.

[snip]

> we should choose one or another behaviour based on the user needs, not on

I disagree.  Picking a different syntax and slightly different
behaviour for every new feature is short sighted.  The current
state of fvwm syntax shows why:  each command has its of, slightly
deviating syntax.  This makes it hard to learn the language and is
utterly confusing.  I have made some progress towards the ultimate
goal of a unified syntax, but there is a long way to go.  In 3.x,
there is no place for features with extravagant syntax and complex
interactions between separate options.

Some important characteristics of the future syntax are:

 1. Disabling an option always uses the same syntax ("!option")
 2. Same for reinstating the default value (how?)
 3. Same sor enabling an option and providing arguments
 4. Similar features use similar syntax
 5. No hard coded behaviour that can not be changed (e.g. the
    infamous "window loses focus when it is iconified" mis-feature)
 6. No hidden interaction between low level options
 7. No overriding of user preferences
 8. Sets of low level options may be configured by higher level
    convenience options (like "MenuStyle mwm" or
    "Style * SloppyFocus" we have now).

> it and want to break it without asking Tim, Olivier and me.

You may not have noticed, but I have been trying to unify the way
the fvwm syntax works in all areas for years.  Apart from the fact
that I was deeply involved in the development of colour sets.

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 15 Oct 2003 14:01:08 +0300

> it.  We already had mails from confused users because they split

The difference between our ideologies is clear.

You see Colorset as a static configuration command, this is why you think
the paragraph above is correct. I see Colorset as dynamical command and
this is why I don't think the paragraph above is correct for Colorset.

Think about this set of 2 ordered commands (I may find a better example):

  XMoveResizeWindow(window)
  XMoveWindow(window)

as opposite to this:

  XMoveWindow(window)
  XMoveResizeWindow(window)

Of course they yield different results. They are designed to.

I guess you will say that then we need 2 kinds of bg, one that resets all
details and one that does not. I think it would be really redundant here.
We should just document that Colorset behaves like script command, not
like configuration command.

> and hi, then change bg, it's perfectly clear why the old settings

I run fvwm for monthes without Restart. As a user I don't remember
whether I ever issued "Colorset 1 sh" after the last restart. Also as a
supporter I can't ever suggest "Colorset 1 bg" on the mailing list,
because I can't make any prediction about what user did previously with
this colorset. I must _always_ suggest "Colorset 1 bg yellow, fg, sh,
fgsh", to reset the old user details. The user very quickly becomes aware
of _all_ possible colorset details and their meaning. There is no
information hiding where it wants to be (one of the computer science
patterns).

I see no problem to have different behaviours for different commands.

I really like the dynamical behaviour of Colorset. The order between
options in one command does not matter. The order between commands may or
may not matter. A bit similar to how Style works. Not the same, sure, but
you may compare the way Style entry "a*" overwrites "ab*" entry defined
in the previous command with the way bg color overwrites sh color defined
in the previous command.

In the spirit of the current behaviour of Colorset the most natural
implementation of Clear for me would be this. This option resets
everything in this colorset that is not specified in the same command.
Just like currently these two commands are equivalent:

  Colorset 5 Tint green 15, bg average, hi gray90

  Colorset 5 hi gray90, bg average, Tint green 15

These two commands should be equivalent too:

  Colorset 5 Clear, fg white, bg average, hi gray90, VGradient ...

  Colorset 5 fg white, hi gray90, bg average, Clear, VGradient ...

Of course I want to hear comments from Olivier first about this.
Maybe he may even implement the Clear option for me. :)

Regards,
Mikhael.