On 19 Nov 2002 13:46:49 +0100, Dominik Vogt wrote: > > On Tue, Nov 19, 2002 at 12:12:59PM +0000, Mikhael Goikhman wrote: > > On 19 Nov 2002 12:35:32 +0100, Dominik Vogt wrote: > > > > > > On Tue, Nov 19, 2002 at 11:04:26AM +0000, Mikhael Goikhman wrote: > > > > On 18 Nov 2002 12:34:03 -0800, [EMAIL PROTECTED] wrote: > > > > > > > > > > > - Changed some defaults (not META_L binding by default; no default > > > > > > font; use mouse selection). > > > > > > > > > > Does everyone actually want the proxies to be auto-selected by moving > > > > > the mouse > > > > > over them and not even clicking them? I found it really annoying, > > > > > but I'd be > > > > > willing to put it up for a vote. > > > > > > > > If you speak about ConfigFvwmProxyDefaults, it is only an example > > > > configuration, it may include anything to help a user to > > > > understand the usage, but it is not going to be included (read > > > > forced) for everyone, just like we don't include any configuration > > > > for our 30 other modules. > > > > > > > > I suppose Dominik only temporarily forced this file for everyone. > > > > > > Actually, no. In the case of FvwmProxy, I wanted to provide a > > > neat interface for module/fvwm communication. We can hardly > > > expect that a normal user can write this on her own or copy it > > > from the man page. Think of it as part of the deafult interface. > > > > > > ----------------------- snip --------------------- > > > AddToFunc FvwmProxyShowFunc > > > + I UnsetEnv FvwmProxy_S > > > > > > ... > > > > > > AddToFunc FvwmProxy_Mark > > > + I SendToModule FvwmProxy mark $w > > > > > > AddToFunc FvwmProxy_Circulate > > > + I WindowId $[FvwmProxy_S] $0 $1 FvwmProxy_Mark > > > + I CondCase (Error) $0 $1 FvwmProxy_Mark > > > ----------------------- snip --------------------- > > > > > > But that does not mean I want this for every module. > > > > As much as one likes some module (FvwmAnimate, FvwmBanner, FvwmTheme, > > FvwmBacker, FvwmProxy) fvwm should be able to start naked without > > requiring/configuring anything like this. The more configuration we force > > for everyone the more an experienced user should undo for his own setup. > > It is also unexpecting that the man page says something about the defaults > > and a user gets something different. > > That's exactly what we have in the fvwm core already. Some > documented defaults just come from ConfigFvwmDefaults and do not > work when executed without it. The idea is to hard code only the > settings that are absolutely necessary and rely on a proper > installation to get the rest. > > > If FvwmProxy can't work without > > defining some functions, it should ask fvwm to create them, > > That does not work. A module can not guess what fvwm has already > defined. > > > but if these > > functions are optional and configurable, one example implementation should > > not be forced for everyone. > > It is only the default. With the same reasoning, FvwmAuto should > not provide a default behaviour (raise on focus), and neither > FvwmAudio, FvwmWinList, FvwmTaskBar, FvwmIconMan, FvwmIconBox and > probably other modules that I am missing. I postulate that every > module should come with a default configuration that allows using > the module. In case of FvwmProxy you will still have to set up > some key or mouse bindings, but that should be all. > > > I think the good solution is to mention in > > the man page that to get one predefined FvwmProxy configuration a user > > may include 2 lines to his config (but do not force these lines for him): > > > > Read ConfigFvwmProxyDefaults > > AddToFunc StartFunction I FvwmProxy > > To be usable for anybody but experts, FvwmProxy *needs* that > configuration. I would have hard coded it into FvwmProxy, but it > needs interaction with fvwm. Of course not everybody needs these > functions, but on the other hand not everybody needs > WindowListFunc or UrgencyFunc either. Unfortunately these configs > have to be executed at startup in order to not overwrite user > modified functions.
First of all ConfigFvwmProxyDefaults is incorrect, it should include DestroyFunc and DestroyModuleConfig to be ready to be included twice. Second, I don't think the way you took is the best one. There are more clean ways without requiring anything to be defined for every user. And more intuitive for a user to define. If we take FvwmEvent as an example you require now to include a file that defines 40 functions (as the number of events) that look like: # this is the default for FvwmEvent callbacks, but a user may change it AddToFunc FvwmEvent_new_page + I echo new_page AddToFunc FvwmEvent_add_window + I echo add_window $w Compare this to the way FvwmEvent works now, which is better? I really hope you understand my point, because I don't want to expand it. What is the reason to have AbortCommand if you don't expect a user to use it to change the defaults? Here is how I would solve it. The module keeps the default commands internally, if he needs a function (this is not really needed, but anyway) such function with a name like _FvwmProxyDefaultAbortFunc may be created on FvwmProxy startup, the names of these functions don't need to be documented, because a user should not use them (they will be overridden). Instead a user should define his own function or maybe just include the full command inline: *FvwmProxy: HideCommand UnsetEnv FvwmProxy_S *FvwmProxy: MarkCommand WindowListFunc $w *FvwmProxy: AbortCommand MyAbortFunc The default callbacks should be hardcoded in FvwmProxy.c. Another possible solution/addition would be to have something like *FvwmProxy: UseDominiksDefaults that sets alternative defaults. 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]
