2009/1/26 Dominik Vogt <[email protected]>: > On Mon, Jan 26, 2009 at 10:06:07AM +0000, Thomas Adam wrote: >> 2009/1/26 Dominik Vogt <[email protected]>: >> > On Sun, Jan 25, 2009 at 11:28:51PM +0000, Thomas Adam wrote: >> >> 2009/1/22 Thomas Adam <[email protected]>: >> >> I've also deprecated StartsOnPage/Desk/Screen in favour of: >> > >> > I'm unsure whether this is a good thing to do. There should be a >> > consistent way of having many commands as styles, including all >> > arguments, but the MapCommand is not a general solution. For >> >> Hmm -- but then you have to go down the route of: >> >> Style foo MapCommand A, MapCommand B someoptions, \ >> MapCommand C optionA optionB >> >> Which is fine I suppose, but might get confusing since the ordering is >> then enforced on the user. Is this what you were referring to when >> you said many commands? > > What I actually meant is that we have a lot of commands that > should be present as styles at window startup only, for example > > Iconify, Layer, Move, Maximize, Shade, Raise, Lower, etc. > > The MapCommand style is - in my eyes - only a (temporary) > workaround for allowing > > <Command> <args> > > as well as > > Style * <Stylename corresponding with commandname> <args>
Indeed -- something which meets this halfway, if only temporary might still be useful. > e.g. > > Maximize 50 100 > Style * Maximized 50 100 > > Fvwm has no clear concept behind styles and commands. I rather > think of it as window state that affects how windows look and > behave. We have > > * initial window state (upon mapping the window) > * current window state > * default or custom window state > > Default state means that a specific facet of the window state has > not been changed and that a change of style will affect this > window whereas custom state means that whis feacet was changed > for this window only and that the window is now unaffected by > style changes of this facet. Example with some hypothetic > commands: I like this idea, actually, but the changes involved would be vast -- however certainly very interesting to work on for the future. Would you and others be willing to flesh this out further? I really like the idea, and having a design for this, if only for the future would be cool. > InitialWindowState * Maximize off, Shade on > Next (foo) SetWindowState Shade off > > Note that "Next (foo)" is just a way of specifying a set of > windows (one window in this case), just like > "InitialWindowState *" selects all windows. This concept simply > boils down to a stack of state definitions of which the most > specific one wins (separately for each facet of window behaviour). > States could be stored in some kind of database that allows > efficient search algorithms for a specific facet of a given > window. Agreed -- the principle seems sound. > Since this would entail a complete rewrite of huge amounts of code > it will probably be never implemented. (And of course it would > completely change fvwm's syntax.) If this idea is taken seriously long-term, I would really like to help implement something like this, FWIW. :) Squashed into this is the idea of having styles match specific subsets of a window's name or class as in: Style (class=MyWindow,Name=Bob) SomeCommand Although that in itself is a fair chunk of rewrite. (Something like this does already exist, although I don't know how far off the ground it was ever taken -- it's in CVS on a branch anyway.) > I suggest we just add the new style for now and leave all other > styles as they are now. You mean clean up my abomination^H^H^Hpatch (making the suggestions about StaysPut, etc)? If I went and did that and wrote some documentation for it, I suppose it might help. I am still apprehensive about what to do with the styles I've proposed as deprecated. I know I took a bulldozer attempt at that, but could I get a concrete answer on this? Putting a warning about their deprecation is fine -- but do we still have them as valid styles anyway? (Which might cause some interesting conditions with using MapCommand) I know 2.5.X is experimental, etc., etc., but this is potentially a big change and would break almost everyone's config. Thanks for your feedback and ideas, they're really rather interesting. :) Kindly, -- Thomas Adam
