On 26 Sep 2002 16:08:34 +0200, Dominik Vogt wrote: > > On Thu, Sep 26, 2002 at 12:16:40PM +0000, Mikhael Goikhman wrote: > > On 26 Sep 2002 12:14:02 +0200, Olivier Chapuis wrote: > > > > > > On Thu, Sep 26, 2002 at 10:17:07AM +0200, Olivier Chapuis wrote: > > > > > > > > I think we need a lot of new icon styles: > > > > > > > > IconTitleColorset > > > > HilightIconTitleColorset > > > > IconBackgroundStyle [Colorset cset] [Frame x] [Padding x y] > > > > > > > > and maybe a HilightIconBackgroundStyle. > > > > Maybe. It seems to be needed. But then maybe incorporate IconSize into > > this as well? Something like: > > > > Style * IconStyle \ > > TitleColorset cs, \ # defaults to Colorset > > HilightTitleColorset cs, \ # defaults to HilightColorset > > FrameColorset cs, \ # defaults to Colorset > > HilightFrameColorset cs, \ # defaults to FrameColorset/HilightColorset > > [!]Transparent, \ # defaults to True, for *FrameColorset > > Padding x y, \ # defaults to 0 0 > > Relief n, \ # defaults to 0 > > Size [x y [x2 y2]], \ # defaults to -1 -1 -1 -1, now IconSize > > > > But this is only a way to group options. I think you suggest to divide > > this differently if hilight icons may have another size, something like: > > > > Style * IconStyle \ > > TitleColorset cs, \ # defaults to Colorset > > FrameColorset cs, \ # defaults to Colorset > > [!]Transparent, \ # defaults to True, for FrameColorset > > Padding x y, \ # defaults to 0 0 > > Relief n, \ # defaults to 0 > > Size [x y [x2 y2]], \ # defaults to -1 -1 -1 -1, now IconSize > > > > 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. 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]
