On 08 Jul 2003 23:15:06 +0200, [EMAIL PROTECTED] wrote:
> 
> On Tue, Jul 08, 2003 at 04:53:48PM +0000, Mikhael Goikhman wrote:
> > 
> > What is more important for 2.6 is WindowStyle.
> > So a user has a full control on his windows individually, something that
> > is possible in most of the other window managers.
> 
> There may be an easy way to achieve overriding styles for a
> limited period of time.  Add a field to the style structure that
> can contain a unique style id.  Then throw in a couple of
> features:
> 
>   StyleWithId <envvar> <Stylename> <Options>
> 
>     Like Style, but assigns a unique id to the style and stores it
>     in the environment variable <envvar>.  Styles with different
>     ids can not be merged.  By default, all normal styles have the
>     id 0.
> 
>   DestroyStyleId <id>
> 
>     Destroys the style with the <id>.
> 
> Usage:
> 
>   AddToFunc foo
>   + I StyleWithId SID_$w $n HandleWidth 0, BorderWidth 0, NoTitle
> 
> and later:
> 
>   ThisWindow DestroyStyleWithId $$[SID_$w]

Let's see. :) This introduces 2 temporary commands that do not help at
all to implement invidual window styles. The style changes are still
applied to all windows with the same name, it relies on environement
variables and it still suffers from a problem that X assigns the same id
to different windows (close a window and open a new one).

WindowStyle and DestroyWindowStyle commands and their syntax was thought
and designed to be final, they do not need to be thrown away at all.
At least it is my impression that Olivier, me, Dan and Tim discussed it
and agreed that WindowStyle is good to be non temporary.

Anyway, if you can implement "WindowStyle <style-options>" syntax
differently than Olivier, it would be just fine with me. The point here
is to have individual window styles and thus to improve fvwm, not to have
an implementation that you don't agree with. Although I should say that
I think that the second Olivier implementation is good and clean.

If you don't agree with the WindowStyle syntax I would like to know why.
For me, regardless of how we may redesign (or not) Style command, the
minimal WindowStyle syntax working on window context will always remain
good and meaninful. Just what we miss for individual window styles.

> (The ThisWIndow call is necessary to force expanding variables
> twice - no idea how to do this in a functions.)

I thought about this problem too, and the best I can think is using
Schedule 0 command... I guest we need a dummy prefix Expand or similar.

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]

Reply via email to