On 14 Oct 2003 14:35:14 +0200, Dominik Vogt wrote: > > 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 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.
I am happy that they don't work equally. Because in the second case the user definitelly wants to use the yellow background and recalculate the sh and bg colors to match yellow. I am tired to repeat this argument. The "sh" color is not independent from "bg" by its mere definition. Setting it in the separate line before the "bg" line and expecting it to work makes no practical sence. > > 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. I don't worry about fvwm-themes, it is clean and patching it for the new behaviour is trivial. It will use Clear anyway (either Olivier or me will add this option) and everything we discuss here will be irrelevant. But I worry about users that unlike you change colorsets constantly in FvwmConsole or similar. Ask them whether they want to specify "bg yellow" or "bg yellow, fg, sh, fgsh" (and maybe more of these in the future) to change the bg. Do you change colorset definitions defined in your configuration? If no, then why should you worry at all about one or another behaviour implemented by other developers? I would at least try to find a reason for it working this way. > > > 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. If you speak about FocusStyle, it is huge and full of backward compatibility issues. I don't think comparing FocusStyle with colorsets is very correct. FocusStyle values are not supposed to be changed often. > 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. I should agree that, yes, I feel you don't listen to my arguments. I do understand your arguments to make the code clean. I think that the "setting x resets y" logic does not make the code less clean if implemented correctly. There are 2 calls of reset_y(), that's all. It is much less clean _for_me_ to keep a global flag for y indicating that y was ever set by a user and have conditions based on it. Of course, you need such local flag so that "Colorset sh s, bg b" works equivalently to "Colorset bg b, sh s", so both behaviour implementations are more or less equivally clean/unclean. It ends up that for new things (without backward compatibility issues), we should choose one or another behaviour based on the user needs, not on the code issues. > 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. The situation is strange. Tim coded this logic in 1999. Olivier enhanced it to work with fgsh too. I try my best to convince you it is good. And you yesterday learned about it and want to break it without asking Tim, Olivier and me. Very constructive. 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]
