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> 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: 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. 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.) > > example, with MapCommand windows will flash on the current screen > > first and be moved to the page specified with the "StartsOnPage" > > substitute only after that. So deprecating the styles would > > actually impair the functionality. > > Yes, the "flashing" is a possibility, although having tested this > quite a bit over the weekend, I can't say I have noticed it at all. > What would you suggest then? If we keep StartsOnScreen and friends as > separare entities, that doesn't provide a generic solution either. I suggest we just add the new style for now and leave all other styles as they are now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
