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: > > I prefer resetting individual options with the '!' prefix: > > > > 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 see. > 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). > > > > 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. > > > > @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. > 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 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. 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 ^_^ ^_^ -- 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]
