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.
> 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.
I don't care about a "Clear" option, except that the syntax is
bad. We have way too many different ways to reset complex user
defined structures already (Styles, MenuStyles, Decors, Functions,
Menus). Other than that, the intended behaviour is perfectly
acceptable for me.
> 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.
> 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 think you are confusing my part in the colour set
implementation. And, by the way, in the past I have been the only
one who ever worried about syntax, so it comes naturally that I
talk about it in this case too.
> > > > 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 may also look at the menu hilighting code. Or the MenuStyle
logic when the mwm/fvwm style is set.
[snip]
> 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.
I disagree. Picking a different syntax and slightly different
behaviour for every new feature is short sighted. The current
state of fvwm syntax shows why: each command has its of, slightly
deviating syntax. This makes it hard to learn the language and is
utterly confusing. I have made some progress towards the ultimate
goal of a unified syntax, but there is a long way to go. In 3.x,
there is no place for features with extravagant syntax and complex
interactions between separate options.
Some important characteristics of the future syntax are:
1. Disabling an option always uses the same syntax ("!option")
2. Same for reinstating the default value (how?)
3. Same sor enabling an option and providing arguments
4. Similar features use similar syntax
5. No hard coded behaviour that can not be changed (e.g. the
infamous "window loses focus when it is iconified" mis-feature)
6. No hidden interaction between low level options
7. No overriding of user preferences
8. Sets of low level options may be configured by higher level
convenience options (like "MenuStyle mwm" or
"Style * SloppyFocus" we have now).
> 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.
You may not have noticed, but I have been trying to unify the way
the fvwm syntax works in all areas for years. Apart from the fact
that I was deeply involved in the development of colour sets.
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]
