On 07 Jun 2003 14:17:41 -0400, Dan Espen wrote: > > Olivier Chapuis <[EMAIL PROTECTED]> writes: > > 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. > > > > Seems that there is no conclusion here. It seems that there is two > > votes for it (me and Mikhael) one vote against (Dominik) and one > > unclear vote (Dan). So I ask for more votes and clarification > > (Dan?). For that I send an other version of the patch (attached). > > I've followed all the advice (I can follow) that I get in this > > thread. In particular, I've followed all the remarks (as I can) of > > Dominik regarding the code. So, Dominik I even hope you revert your > > vote (very little hope ...). Also: the cmds are named WindowStyle and > > DestroyWindowStyle and act on the selected window and there is the > > doc and some tests in purify.fvwm2rc.
Can you please clarify one thing. You previously said that after applying many WindowStyle commands and switching themes the style list didn't grow. Do I understand you correctly? Because it is the Dominik's reason against the patch (you seem to cover several other reasons with your new patch). > There was same talk about StyleById being temporary and you chose > WindowStyle instead of > using a null pattern to select the context window: > > You used: > > Next (window*) WindowStyle BorderWidth 7 > > instead of: > > Next (window*) Style [] BorderWidth 7 > > I think I prefer the null pattern, but only slightly. I started to write an answer some weeks ago, but I didn't have a time to complete it. I don't have the time now too. But I will try. There were ideas 2 years ago to have powerful conditions, but instead of duplicating them in both conditional commands and Style command, to get rid of Style and introduce WindowStyle instead. I.e. currently unexistent Style (Class XTerm) NoButton 6 is replaced with: Next (Class XTerm) WindowStyle NoButton 6 that is placed in StyleFunction and applied to all new windows. So, at least by these ideas, it is not clear whether to have Style command at all in the long run. On the contrary, having WindowStyle that does not receive any condition parameters, but works on the context window instead is a good and complete thing. The second reason against 2 different cases of Style (one that works on window context and one that ignores it) is no well-defined behaviour. I understand that you want to have class/resource patterns in Style. Then what should this command mean for you: Next (XTerm) Style (Resource mozilla) TitleAtBottom 1) Only windows that are both "XTerm" and "mozilla" are affected. 2) Any mozilla is affected if there are some xterms on the screen. I would prefer to leave the current Style as is, i.e. to ignore any window context for the sake of consistency. The third reason to have a separate WindowStyle command is that it may eventually replace all state commands, i.e. "Stick" is the same as "WindowStyle Sticky". But this is not really a separate reason, because you may say that "Style [] Sticky" will do it. It is possible, but not as clean as "WindowStyle Sticky" for me. 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]
