Some further explanations below.
> > 3. It does not introduce a data type identifying a style, just
> > passes lists of arguments to the style functions.
>
> Not sure to understand. There is a new element in the window_style
> structure xid (!=0 if and only if the window_style was generated
> by the StyleById command).
When style identifiers become more complex than a simple string,
they need to have their own data type, e.g.
typedef struct
{
char *name;
XID window_id;
struct
{
has_name;
has_window_id;
} flags;
} style_id_t;
> > 4. It unnecessarily exports knowledge of style related design
> > choices to sub functions that do not need to know about them.
>
> Not sure to understand. As FocusStyle vs Style? Not a big issue
> IMHO.
See above. Passing all the possible style identifiers through the
function interface to functions parsing some of the styles is not
a good idea.
> > 5. Because id-specific styles are kept in the same list as the
> > normal styles, it will cause memory consumption by the style
> > list to explode under certain situations. Clean rules for a
> > new style preference order are needed first.
>
> Adding _a_ style by id is the same thing as adding a style with a name
> which do not already appear in the list. There is style list
> simplification/merging in between style by id. Only UseStyle is not
> supported by the patch (not a big issue, this can be documented).
You need to understand the problem the style list already has. If
you issue style commands in the wrong order, the list grows ad
infinitum because styles can not be merged or deleted. Configs
with many style changes (theme switching!) or styles tied to a
window id increase this probability a lot because they add
incompatible style identifiers to the list that prevent merging.
The reson for this is the notion that the last style always wins.
Yes, this is user friendly, but it is difficult to manage in the
code, and introduces a kind of memory leak. I'd prefer a
hierarchical style preference system
> > 6. It introduces inacceptably complicated if-conditions and code
> > duplication.
>
> The complicate if-condition is just a visual complication. We can
> add a macro STYLES_HAS_THE_SAME_IDENTIFIERS(*style1, *style2) and
> maybe a macro which test if a fw window "match" a style "identifier".
Ack, please no code in macros! That's what functions were
invented for :-)
> I do not see code duplication, but the way to safely do a
> strtoul (we can put this in one function somewhere).
>
> > 7. We will regret the ad-hoc syntax very soon:
> > - It is not flexible (mixing different kinds of style patterns
> > is difficult).
> > - The syntax does not help with state-specific styles.
> > - The syntax does not help with regexp style name matching.
> > - It may further complicate abstracting the style parsing
> > code to allow all style names in other contexts (e.g.
> > conditions).
> >
>
> As I said It is just a tmp command.
Then I agree with Dan: I see no reason to introduce temporary
commands into stable releases.
Bye
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]
