On Tue, Oct 14, 2003 at 02:48:47PM +0300, Mikhael Goikhman wrote: > 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.
*Sigh* We discussed that already for bg/sh/hi. The beginning user does *not* need to do any of this as he/she won't be changing fgsh in the first place. > > > 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? **Sigh** You're just arguing for the kicks, right? Colorset n bg yellow Colorset n sh black, hi black and Colorset n sh black, hi black Colorset n bg yellow are *not* equivalent. > > 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 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. Except in the cases where it's right. See above. [snip] > > > 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, I don't care one bit about the previous theme. Maintaining fvwm-themes usability is your problem, not mine. Don't claim to be talking about fvwm's usability when you're actually talking about fvwm-themes, which is irrelevant to me. > > 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". Then stop arguing and look at the several examples of code where I had exactly these problems. You constantly accuse me of not reading what you write, yet you are too lazy to even consider what I am saying, or even follow the pointers I give you. > 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. Sure. Because you don't do the maintenance > 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. Well, I *you* really want to improve fvwm, why don't you just *fix* these bugs instead of annoying me with vague hints to bug lists that you have been to lazy to compile for more than a year. [snip] As always, this discussion is pointless. I will commit the patches I have in mind soon and end it this way. You can continue to worry about fvwm-themes, and I will continue to worry about predictable, flexible, well documented sytax and behaviour in the fvwm core. Over and out 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]
