On Thu, Sep 26, 2002 at 06:04:47PM +0000, Mikhael Goikhman wrote: > On 26 Sep 2002 16:08:34 +0200, Dominik Vogt wrote: > > [snip] > > > Style * HilightIconStyle \ > > > TitleColorset cs, \ # defaults to HilightColorset > > > FrameColorset cs, \ # defaults to IconStyle/HilightColorset > > > [!]Transparent, \ # defaults to IconStyle/True > > > Padding x y, \ # defaults to IconStyle/0 0 > > > Relief n, \ # defaults to IconStyle/0 > > > Size [x y [x2 y2]], \ # defaults to IconStyle/-1 -1 -1 -1 > > > > Oh, no no no! Please no nested style definitions. That's > > unparseable and unreadable. > > Well, I only tried to discuss the needs (structures to be used) first, not > the syntax. The syntax may be just "Icon" and "HilightIcon" prefix to all > the fields if we decide we don't need external (not inline) structures. > > But even if we only need flat Style options, I am not so sure the flat > syntax is the best thing. Style command is already polluted. Grouping > would not hurt. For me the following: > > Style * IconStyle TitleColorset 8 > Style * FocusPolicy FocusClickModifiers CS > > is not less readable or parsable than: > > Style * IconTitleColorset 8 > Style * FPFocusClickModifiers CS > > But the first has some advantages like to actually _reduce_ the syntax, > since usually all options inside one group are defined in one place, so > they may be grouped. Additionally, operations like copying the FocusPolicy > style group from "XTerm" to "gnome-terminal" would be possible, not only > CopyStyle. The man Style entry would be more structured. > > I think Tim suggested in the past some solution to split Style. > Is this solution still relevant, Tim? > > > The "Decor" stuff already proves that it is the wrong way. > > I don't say that flat Style options is a bad thing, it is good for > performance, but syntax should not be flat. Decors are fully irrelevant. > > But my thoughts are, when we move TitleStyle/ButtonStyle/BorderStyle > commands to Style, we will need these Style groups, yes.
I think the grouping is on the wrong level. It does not matter if the styles names are IconStyleTitleColorset (could be augmented with an "IconStyle" command that is the same as Style but prefixes all style names with "IconStyle" first). or IconStyle TitleColorset (although it is much more difficult to parse) The biggest flaw is the current style syntax is that there are too many places that define the same GUI elements. I proposed that before: Style * IconTitle GuiStyle WindowTitle Style * Title WindowTitle GuiStyle WindowTitle Title Colorset 8, ReliefWidth 2, ... Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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]
