On Fri, Nov 22, 2002 at 10:26:25PM +0000, Mikhael Goikhman wrote: > On 22 Nov 2002 13:27:59 -0800, [EMAIL PROTECTED] wrote: > > > > On Fri, Nov 22, 2002 at 05:13:29PM +0000, Mikhael Goikhman wrote: > > > 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 Actually, the proper key name is Meta_L. > > > > > > 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 > > > > So, this would mean that Circulate implies a Show if not shown. > > That's fine by me. These two lines are easy to explain on the man page. > > > > I really like this how clean this looks. How slow is "slow" for using > > two messages vs one? Four insted of two. > > I don't want to neglect older HW, for which fvwm > > lightness is even more appealing. Even if each message takes 100ms, > > we're only going from one to two. I remember in another module I was > > prototyping, I was streaming tons of move commands, perhaps a dozen for > > each step of a mouse drag. > > I would naively expect that a couple > > messages would be less time than it takes to redraw two proxies. That is not the point here. Redrawing is done by the X server which can handle any amount of incoming data at any speed. > I don't think it is slow. Probably 100 bytes transfered over already open > pipes vus 50 bytes transfered plus expanding and executing a complex > function. A slowness should not be an argument here. Then perhaps you should do some profiling of the module interface. Its performance is horrible. The performance of this one module isn't this interesting here, but it adds to the overall communication. Thus it further increases the chance of pipe overflows and modules being killed due to timeouts. My machine is certainly not slow, but it does have these problems when I start more than just a few modules. > > So does this scenario mean no FvwmProxyDefaults, or is Action Select set > > to a secret _FvwmProxyDefault which is not generally appended to, but > > outright replaced. Overwriting configs that may have been set by the user is a shooting offense. > > So I might have, for my unpopular config, something like > > > > Key Alt_L A N SendToModule FvwmProxy Show > > Key -Alt_L A A SendToModule FvwmProxy Hide Actually, the proper key name is Meta_L unless you have set up your X server in a non standard way. [snip] > > Instead of _FvwmProxySelectDefault, we can define the conglomeration of > > commands into the hard defaults. Is there a one-liner syntax like: > > > > *FvwmProxy: Action Select Iconify off; FlipFocus; Raise; WarpToWindow 5p > > 5p No, that does not work in other modules and it does not work in this. Fvwm does not guarantee to execute these commans in a single batch. Other things might be done in between. For example, the focus might be switched. > This is exactly WindowListFunc. I think WindowListFunc is a good default > for Select and it does not require any hidden _FvwmProxySelectDefault. I think that is no valid reason for recycling WindowListFunc in FvwmProxy by default. It should still has its own copy of the function for readability. 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]
