On 22 Nov 2002 17:00:57 +0100, Dominik Vogt wrote: > > On Fri, Nov 22, 2002 at 02:48:47PM +0000, Mikhael Goikhman wrote: > > On 22 Nov 2002 14:35:54 +0100, Dominik Vogt wrote: > > > > > > On Fri, Nov 22, 2002 at 12:32:01PM +0000, Mikhael Goikhman wrote: > > > > On 22 Nov 2002 10:42:51 +0100, Dominik Vogt wrote: > > > > > > [SNIP SNIP SNIP] > > > > > > > > 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". > > > > > > Reducing the number of configurable actions limits flexibility > > > severely. When you don't have a "Mark" command, the module > > > response must be hard coded. The same is true for any actions > > > that should be run when the proxies are closed or aborted. > > > > > > > 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. > > > > > > I never said functionality would be missing. I said inexperienced > > > users will not be able to run FvwmProxy. Exactly like they are > > > not able to run FvwmEvent, FvwmForm, FvwmScript or FvwmButtons. > > > > > > The config just too complex. > > > > In this case I don't think that hardcoding the hide/show/mark/abort > > functionality is bad or will reduce any functionality. But maybe I am > > missing some usage. This is why I would like you to describe any missing > > practical (not theoretical) usage if this configurablity is dropped. > > Let's assume we have mark, unmark, hide, show, abort and select > commands (note that an unmark action does not exist yet). Let's > further assume the user wants: > > Alt-Tab: mark* next window, unmark* last window > -Alt: Select currently marked window, close proxies. > > * mark = bring window to the top of the top level layer > unmark = lower window to default layer > > With the predefined functions in ConfigFvwmProxyDefaults (plus > the hypothetical unmark function): > > key tab a m FvwmProxy_Circulate Next (currentpage) > key -Meta a a SendToModule FvwmProxy Hide > AddToFunc FvwmProxyMarkFunc > + I Raise > + I Layer <some options> > AddToFunc FvwmProxyUnmarkFunc > + I Layer <some options> > > Note that the user only needs some knowledge about key bindings > (basics) and how to add something to an existing functions (also > basics). Even a beginner should understand most of the config - > perhaps not the SendToModule part (which may be hidden in another > function FvwmProxy_Hide). > > With hard coded defaults: > > key tab a m My_Circulate Next (currentpage) > key -Meta a a SendToModule FvwmProxy Hide > *FvwmProxy: MarkCommand Function MyMarkFunc > *FvwmProxy: UnmarkCommand Function MyUnmarkFunc > AddToFunc MyMarkFunc > + I SetEnv FvwmProxy_S $w > + I Raise > + I Layer <some options> > AddToFunc MyUnmarkFunc > + I Layer <some options> > AddToFunc My_Mark > + I SendToModule FvwmProxy mark $w > AddToFunc My_Circulate > + I WindowId $[FvwmProxy_S] $0 $1 My_Mark > + I CondCase (Error) $0 $1 My_Mark > > You see the difference? In the latter case the user has to worry > about the internal communication between fvwm and the module which > makes it very difficult to understand. Even I get confused by the > complexity. With that, the user has to learn how to write > complete fvwm functions, configure a module, read the man page and > copy the contents of the default functions into her config file. > At the same time she will hopefully not get confused by all the > abstract stuff from the documentation. > > And just imagine what happens when you try to join the _Mark and > the _Circulate functions into a singe one. I had to split them > because they require no less than *seven* '$' characters before > the 'w'. > > Things may become a bit easier without keeping the marked window > id in fvwm, but also slower. > > I'd really welcome a way that allows to have a nifty, easy to > understand default configuration and not requiring to enforce the > config at fvwm startup for every user. It's okay if configuring > the module becomes rather complex when doing tricky things. The > most inexperienced user should be able to > > - add something to select and mark easily > - hide and show the proxies without configuring more than a key > or mouse binding.
It seems like you don't get or ignore my suggestion. With it your configuration above is as trivial as: Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage) Key -Meta A A SendToModule FvwmProxy Hide This is enough for most of the users. And if you think it makes sense to do something else (except for hilightling the proxy) on the "mark", the module may still have 2 options MarkCommand and UnmarkCommand (that are by default Nop). *FvwmProxy: MarkCommand Layer +1 *FvwmProxy: UnmarkCommand Layer -1 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]
