On 13 Oct 2003 14:41:59 +0200, Dominik Vogt wrote:
> 
> On Mon, Oct 13, 2003 at 03:03:23PM +0300, Mikhael Goikhman wrote:
> > On 13 Oct 2003 09:12:44 +0200, Dominik Vogt wrote:
> > > 
> > > On Sun, Oct 12, 2003 at 03:36:51PM +0300, Mikhael Goikhman 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.
> > > 
> > > @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.
> > 
> > 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,
> 
> I am now convinced that "Tint" is a bad name and should have been
> imageTint from the start.

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

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

> > 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.
> 
> Images don't have a "shadow" or "hilight" colour, so this can not
> happen.

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

> > This is bad.
> 
> But can be fixed with a conversion script.
> 
> > 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.
> 
> 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.

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.

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

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;
  }

> > The same should be done with bgTint.

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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]

Reply via email to