On 15 Oct 2003 10:32:18 +0200, Dominik Vogt wrote: > > On Tue, Oct 14, 2003 at 05:54:46PM +0300, Mikhael Goikhman wrote: > > On 14 Oct 2003 14:35:14 +0200, Dominik Vogt wrote: > > > On Tue, Oct 14, 2003 at 02:48:47PM +0300, Mikhael Goikhman wrote: > > > 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. > > Breaking long lines must never change the result of the issued > commands. All relevant commands that have the potential to > generate very long lines work this way (Style, MenuStyle, Colorset, > BugOpts, ...) and the ones that do not are scheduled for removal > (ButtonStyle, TitleStyle, BorderStyle). There is one documented > exception in Style: IconBox and IconGrid, and I am not happy with > it. We already had mails from confused users because they split > their style lines.
The difference between our ideologies is clear. You see Colorset as a static configuration command, this is why you think the paragraph above is correct. I see Colorset as dynamical command and this is why I don't think the paragraph above is correct for Colorset. Think about this set of 2 ordered commands (I may find a better example): XMoveResizeWindow(window) XMoveWindow(window) as opposite to this: XMoveWindow(window) XMoveResizeWindow(window) Of course they yield different results. They are designed to. I guess you will say that then we need 2 kinds of bg, one that resets all details and one that does not. I think it would be really redundant here. We should just document that Colorset behaves like script command, not like configuration command. > > 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. > > This is perfectly predictable for the user. If she just set sh > and hi, then change bg, it's perfectly clear why the old settings > are kept. I run fvwm for monthes without Restart. As a user I don't remember whether I ever issued "Colorset 1 sh" after the last restart. Also as a supporter I can't ever suggest "Colorset 1 bg" on the mailing list, because I can't make any prediction about what user did previously with this colorset. I must _always_ suggest "Colorset 1 bg yellow, fg, sh, fgsh", to reset the old user details. The user very quickly becomes aware of _all_ possible colorset details and their meaning. There is no information hiding where it wants to be (one of the computer science patterns). I see no problem to have different behaviours for different commands. I really like the dynamical behaviour of Colorset. The order between options in one command does not matter. The order between commands may or may not matter. A bit similar to how Style works. Not the same, sure, but you may compare the way Style entry "a*" overwrites "ab*" entry defined in the previous command with the way bg color overwrites sh color defined in the previous command. In the spirit of the current behaviour of Colorset the most natural implementation of Clear for me would be this. This option resets everything in this colorset that is not specified in the same command. Just like currently these two commands are equivalent: Colorset 5 Tint green 15, bg average, hi gray90 Colorset 5 hi gray90, bg average, Tint green 15 These two commands should be equivalent too: Colorset 5 Clear, fg white, bg average, hi gray90, VGradient ... Colorset 5 fg white, hi gray90, bg average, Clear, VGradient ... Of course I want to hear comments from Olivier first about this. Maybe he may even implement the Clear option for me. :) 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]
