On Mon, Oct 13, 2003 at 06:12:07PM +0300, Mikhael Goikhman wrote: > On 13 Oct 2003 16:04:47 +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. > > > > > > > > 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.
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 reason for one or another behaviour is to simplify the life of users. > 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 > where appropriate. 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 ^_^ ^_^ -- 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]
