On 14 Oct 2003 10:16:25 +0200, Dominik Vogt wrote: > > 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
_I_ know what to do if you decide to make it harder to use. I know that fg only resets "fgsh", not "sh" and "hi". I would worry for other users. They should not be forced to _always_ do "fg xyz, fgsh" instead of just "fg xyz". Because the old fgsh will look bad with pretty much any new fg and they can't remember whether they changed fgsh previously in this colorset or not. The beginning users want to only change "fg" and "bg" and don't know about any small details, just know that all details are successfully recalculated for them. The advanced users in some cases want to use the autocalculated details and in some cases may want to adjust them. > > 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 Wrong, these lines are equivalent. Did you get my message about this? > > 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 behaviour does not make it easier for static setups. It makes it both hard and wrong for dynamic setups. Using the previous value of hi, when the new bg is set is _always_ wrong. And in the very rare cases when one wants to preserve it, it is possible. This is not like some global feel setting that you once set and don't want to change ever (like !MouseFocusClickRaises). This is colors. You can't say I want to fixate the sh color regardless of other colors. sh is not independent, it is very dependent on bg. The current bg-sh behaviour is ideal for users. Did you ever hear someone complaining? > > 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. You can't make any guess about the previous color theme, so you should ask everyone to modify their colorsets to the new incompatible behaviour. Note that this modification does not simplify things, it only adds the redundant resetting of _all_ details (and probably more in the future). Also note that I am not against reseting of all existing details on the _complete_ colorset change, this is why I need the Clear option. However I see no reason to introduce incompatibility with the current perfect "change of bg changes sh too" behaviour. > > 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. I would like you not to use such vague (and non-verifiable) arguments like "fvwm history shows" or "you have never stared at code for hours". Because I may say that "fvwm history shows" that the current bg-sh behavious is the best for the users and I don't understand you wanting to break it. As for the developers, I thought implementing nice usable solutions is supposed to be fun regardless of the difficulty. If you really want to improve fvwm, I will soon sit and compile the bug/annoyance list. :) Some seen bugs are hard to make reproducible. And speaking about bugs, Olivier is correct that the current colorset implementation is more or less bugless given the amount of the new code. 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]
