On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote:
> Should the StyleById patch be applied before 2.6? Please cast
> your votes here.
>
I vote "yes". But maybe the patch should be applied later.
I recall my intention: style by id is a great feature, with a simple
_hack_ we can get it, so it is difficult to me to do not wrote such
code. Yes it is a "hack" it is not the new great "WindowStyle"
command we want (which needs more discussion and an enormous code
reworte). Yes it is just a simple piece of code with some theoretical
problems, but ok I think in practice.
About the code: a style in the style list is identified by its name.
With the StyleById patch a style in the style list is identified with
either by the XID used (generated by the StyleById command) or the name
(generated by the Style command) not both. The only change in the
earth of the style code is the test "these two styles have the same
"identifier"". The rest of the code is basically obvious ("decoration"):
parse and use already written function.
> I vote for "no" because
>
> 1. It will even further delay delay the 2.6 release.
> 2. It will destabilise the code because of the delicate nature of
> the style to window propagation.
About this two it is difficult to be sure of something. I think that
the patch will cause only very few problems. If we want to do a
"perfect" WindowStyle command, then this surely delay a lot 2.6 and
destabilize the code. But StyleById is not perfect by nature.
> 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).
> 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.
> 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).
> 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".
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.
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]
