On 13 Oct 2003 16:04:47 +0200, Dominik Vogt wrote:
>
> 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.
After Tint starts to work like I suggest, it could be named
"AnythingButFgTint" 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.
>
> 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
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.
> [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.
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.
> > > 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.
I can't argue with this.
However I know that the "setting x resets y" is a very natural feature
where appropriate.
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]
