On Mon, Nov 25, 2002 at 01:53:42PM +0000, Mikhael Goikhman wrote: > On 25 Nov 2002 12:18:53 +0100, Dominik Vogt wrote: > > On Fri, Nov 22, 2002 at 10:26:25PM +0000, Mikhael Goikhman wrote:
> > > > > Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage) By the way, this does not work at all. How would FvwmProxy know about the window that was matched with "Next"? The correct line is this: Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage) SendToModule FvwmProxy Mark $$$$$$$w (give or take a few '$'s) > (in another message:) > > Actually, I chose an example that needs two commands as the mark > > function on purpose. Then, your approach does not work anymore > > and you are back at writing the horrible complex functions I > > posted. > > This approach does work well and it is less horrible than others. Please take a look at the "Key Tab ..." line above and say that again. > A user is not limited to any function name, he may reuse his own > functions like MyRaiseOn and MyRaiseOff if he wants. I find forcing the user to fiddle with commands like "SendToModule" unacceptable. > > > > 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. > > Only if a user decides that internal Next/Prev are not good for him. > In the default situation there is the same number of messages. As I said, the internal Next and Prev will be removed as they are a pointless duplication of code. And when you originally posted your example you said that FvwmProxy would echo the command sent to it to fvwm. [snip] > > > > 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. > > fvwm should also be capable to perform such simple task as calling the > Next function and sending the window id to a module. If it is not capable > it just pointless to discuss any module communication at all regardless of > the number of requests (1 or 2) from a module. Fvwm should have a stable module interface, but it doesn't. Unless we rewrite it, we have to live with the limitations. > > > 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. > > Agree that a module communication should be improved in the core. > But this does not justify a non clean design. Oh, come on, the design is very clean, you just don't like it. It's goal is to make module configuration as simple as possible. > > Overwriting configs that may have been set by the user is a > > shooting offense. > > We never spoke about overriding user configs, only for supplying a default > when no user config (Action Select in this case) was supplied. Let me rephrase: Overwriting *any* configs that may have been set by the user is unacceptable. Users will hate it, maintainers will hate it. [snip] > > > 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. > > If we already have a global function WindowListFunc, it is consistent to > use it as the default for all window list modules, not just the core. > (And it is actually used in at least 3 modules now). It's not a window list module. > The FvwmProxy man page should explain how to set the Select action. > Having something different to define (another global function) instead > of configuring the Select action is confusing. Thank you! This is exactly what my approach prevents for a beginner. For a beginner, there is never a reason to change the configured module action. Instead, the complex function is changed. With the function-less default, a function has to be used in addition to the moduele resource almost immediately for any non-standard use. > Overall, I like how clean it is now. Well, I don't like it at all as it's user unfriendly and unnecessarily wastes resources. But I think I said that before. Oh, and with the current design it's difficult to bind "Abort" to a mouse button. You'd have to say *FvwmProxy: Action Click2 SendToModule FvwmProxy Abort Ugly. 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]