On Tue, Jul 08, 2003 at 11:22:10PM +0000, Mikhael Goikhman wrote: > 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).
I thought it was clear that this isn't a proposal but a sketch of the idea. > 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. I disagree. Separate commands will lead to matrices of commands plus options they have to support. > 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. See above and many other mails I wrote about this topic. It's inflexible and hard to extend. > 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. Yes. 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]
