On Tue, May 20, 2003 at 08:32:03AM +0200, Dominik Vogt wrote:
> 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.
>
I've wrote a "Styles" subject to the PrintInfo cmd which count the
styles in the style list and print the style names (I can commit this
if you want). With fvwm-themes theme switching does not increase the
number of styles! This is probably because fvwm-themes is well written
... and __simplify_style do a very good job!
In fact, it seems to me that you should have to be careful (and do
strange things) for making the style list growing and growing (say
with two style name).
Anyway, maybe style by id should be prioritary vs style by name:
apply style by name and then apply style by id?
> >
> > 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.
>
If we add this command and in the future re-design the styles cmds,
it will be surely possible to warp style by id to one of the new
command?
Regards, Olivier
--
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]
