On 22 Nov 2002 10:42:51 +0100, Dominik Vogt wrote: > > 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 (?)
FvwmWindowLister currently does grouping by regular expressions. It has a configurable format like "%m%n%t%t(+%x+%y) - Desk %d". It will do submenus optionaly and other configurable things. I think it may be easily supported. WindowList should not go 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 just said that some private function _FvwmProxyPrivateFunc that should not be described in the man page may be overwritten if such function is needed (it is not needed). :) > > > > 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. You are right, sorry, it is already called ConfigFvwmProxyDefaults and not ConfigFvwmProxy like other example configurations. > > > > 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 Mark $$w" > > with the marked window context (or null context if no marked window). Actually it may be just "Next (CurrentPage) SendToModule FvwmProxy Mark", because M_STRING already contains the context window as the first argument. > > 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. In my suggestion there are no *Command options and no functions, just SelectCommand or as Jason suggested "Action Select". ConfigFvwmProxyDefaults file is not needed. Please describe the functionality that would be missing. I don't see any. Both "FvwmProxy_Circulate Next (CurrentPage)" and "SendToModule FvwmProxy Circulate Next (CurrentPage)" are equally intuitive (or not intuitive) for a user. 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]
