On Fri, Nov 22, 2002 at 04:04:07AM +0000, Mikhael Goikhman wrote: > On 21 Nov 2002 11:49:21 +0100, Dominik Vogt wrote: > > On Wed, Nov 20, 2002 at 03:57:53PM -0800, [EMAIL PROTECTED] wrote: [snip]
> > > Referencing the previous email: > > > > Please quote the mails you are referring to. It is very tredious > > to cross read two emails. > > > > > 2) I don't see WindowListFunc in ConfigFvwmWinList or it's man page. > > > Not in the man page for FvwmWindowLister either. I hope that isn't > > > the convention we intend to follow. > > > > Too much to doo in too little time. We document everything, but > > not necessarily while we are fiddling with the design. > > I will mention that WindowListFunc is used in FvwmWindowLister. Off topic: what are actually the plans for that module? I thought we had agreed on *recuding* the number of window listing modules. Now it just looks like we get another of these modules without the internal WindowList going away (?) > > > 3) Unless I'm missing something, no one is suggesting overriding > > > user settings. > > > > Mikhael suggested that. > > I am not quite sure what does this mean. I would never suggest to override > user settings without an explicit command from a user. You said something about letting FvwmProxy install these defaults and put a warning in the man page that they are overwritten each time the module is started. > > > I think things like width should have defaults in > > > the module if no one has set it in any config. I don't see any good > > > reason for simple properties in the ConfigProxy file. > > > > Right. The "*FvwmProxy: ..." lines do not need to be in there. > > Ohh... > > Dominik, let's continue with the same meaning of all our Config* files. > They are examples, so they should include one example "*FvwmProxy: ..." > configuration. If you want to force some file to be executed (although > you should first describe why this is needed at all), name it differently. ConfigFvwmDefaults is no example, it is an essential part of fvwm startup to provide the defaults documented in the man page. Before this file was added, the lines were hard coded in fvwm.c. ConfigFvwmProxyDefaults works exactly the same. > > > 4) If the default behavior is to do nothing, then I don't really > > > see any problem with supplying a cut&paste in the man page. > > > I'd much prefer that to a config file the naive user may not enen know > > > about. > > > I really want to trim down the demonstrated config so that it isn't > > > a big deal. > > > > The point is that the average user should be able to use the > > module without worrying about configs at all. And just think of > > the default config file as the built-in default in a separate > > file. The situation is no different if the defaults are hard > > coded, except that you then can not change the defaults easily as > > a sysadmin. > > I am a bit disappointed why you still insist on the module defaults to be > defined in a file that uses fvwm functions that should be read on the fvwm > startup. It is so clear to me that this is a plain wrong design. > > I am not speaking about missing DestroyFunc in this file, I am not > speaking about this file removed by an accident and a module staying > without defaults. I am speaking about 3 things, each of which would > warrant we don't continue with this bad design. > > 1) Loading essential module configuration when fvwm is loaded is not > different than loading part of IE when Windows is loaded even if a > user never uses IE, but only Mozilla, Netscape or Opera. > This may not a very fair comparision, but this is what happens. > > 2) By adding several functions as an essential part of the module they > become the part of the module. Now the question is this. What should > a user do to change the defaults? To use HideCommand or to change > FvwmProxyHideFunc? Both are the parts of the module and both are used > to define the "hide" action. > > 3) Suppose a user decided not to use HideCommand and to change > FvwmProxyHideFunc. Now he does not have any default, he can't revert > to the default behaviour, because the defaults are not hardcoded. > The module knows nothing about its own defaults, so it can't restore > them by a user request. > > I already posted a solution to this. There are defaults hardcoded in > FvwmProxy.c, so the following command may restore the default: > > *FvwmProxy: HideCommand > > There are no functions that a user should destroy and recreate. Not even > FvwmProxySelectFunc, it's not needed, because unlike WindowListFunc there > is SelectCommand (or Action Select) here. He simply uses, say: > > *FvwmProxy: SelectCommand WindowListFunc $w > > If you want several sets of defaults there is an option or a dynamical > command that sets (by a user request) several predefined actions at once. > > Actually, I think the design should be even simplier. There is no global > state using SetEnv, the marked window is just stored in the module, then > instead of "FvwmProxy_Circulate Next (CurrentPage)" a user just uses: > > SendToModule FvwmProxy Circulate Next (CurrentPage) > > and the module resends "Next (CurrentPage) SendToModule FvwmProxy $$w" > with the marked window context (or null context if no marked window). > > Then I don't see a reason to have ShowCommand, HideCommand, AbortCommand > and MarkCommand at all, there is nothing useful to configure here. Sure, this would all work, and almost nobody would be able to use FvwmProxy because it can be configured only by experts. Enough said, do what you want with the module, I will retire from any further module design. 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]
