On Mon, Oct 13, 2003 at 04:48:03PM +0300, Mikhael Goikhman wrote:
> 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". :)
Nope. Maybe "AnythingButFgBgShOrHiTint". I confess that I'm not
deep enough into the tinting code.
> (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.
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]
> > > 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.
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.
> > 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;
> }
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 ^_^ ^_^
--
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]
