On Mon, Nov 25, 2002 at 05:04:48PM +0000, Mikhael Goikhman wrote: > On 25 Nov 2002 16:00:29 +0100, Dominik Vogt wrote: > > > > 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) > > It works because M_STRING packet contains the context window id as the > first parameter. Definitely, it is not the first module using the current > window context in fvwm->module and module->fvwm communication.
Whoa, I see it now. Appending "SendToModule FvwmProxy Mark" is hard coded. You're not serious about this, are you? What if the user wants to do something else but just send "Mark"? This severly limits the kinds of functions that can be bound to FvwmProxy actions. > > > 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. > > I can't agree here. It is intuitive to send commands to modules, like > start, stop, show, hide. We just should worry these commands are clean. [snip] > > > > > > 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. > > I don't think Next and Prev should be removed, they are just an intuitive > notion to move to the next proxy using some method, say, left to right. > But it is really not important for me whether you want to remove anything > in the code as long as the interface is the same (read: clean) as now. Well, perhaps you should think a bit about who does 90% of the maintenance. We go happily about adding redundant functionality (just the though of what is happening with FvwmWindowLister makes me angry). And in the end I do almost all the maintenance. > > And when you originally posted > > your example you said that FvwmProxy would echo the command sent > > to it to fvwm. > > I said this about the Circulate messages only. > > I think Jason understood me. Together with the idea that the user should > not worry about something that a module should worry about, i.e. adding > the actual command to be recent back: "SendToModule FvwmProxy Mark". Shudder. > > > > > 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. > > Most of the things you do in the core I like very much. > > But here the design is not clean and makes a module configuration complex. > If the authors of FvwmEvent, FvwmTaskBar, FvwmIconMan, FvwmIconBox, > FvwmWinList, FvwmAuto that all enable for a user to configure callbacks > would use your approach we would now have dozens of global functions like > FvwmAutoRaiseFunc, FvwmEventNewDeskFunc or FvwmTaskBarClick1Func. Yes, exactly. And on the other hand we wouldn't have users constantly whining "I want double clicks in module xyz", "why can't I just bind any abc to module FvwmFoo". Now tell me, what is bad about global functions? They simply work better than the feeble attempts to fake them inside the modules. > FvwmForm, FvwmGtk, FvwmButtons and FvwmBacker also have many callbacks, > but noone thought to use global functions FvwmFormExecuteThisWhenConfirmed > or FvwmFormExecuteThisWhenCanceled. It works out for FvwmProxy because it's an extension of the core, that does nothing on its own. > Did you ever think that FvwmProxy like half of our other modules may > support aliases? So it is possible to run 2 modules and configure one > configuration for one set of keys and another for another set of keys. > Then it is immediately clear that global functions like FvwmProxyMarkFunc > or FvwmAutoRaiseFunc are bad. Yes, I actually thought about it. On one hand, running it twice make absolutely zero sense, on the other hand, as I said before, configuration becomes complex as soon as you run it in a non-standard way. > There are much better solutions that are used in other modules. The only two modules that I can think of that have a clean configuration syntax are FvwmCpp and FvwmM4 and the other modules that don't accept module config lines. > > > > 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. > > Actually the proper solution for this is to be able to send to fvwm a > bunch of commands. I thought about this for some time. If a module sends > a string that contains more than one line, fvwm should create an anonymous > function for these commands and execute it. Or to execute them like within > Read/PipeRead. The command line parser does not allow to separate multiple commands and will never do so because it just wasn't planned. Many commands just take the rest of the line and treat it as if it all belonged to the current command. The right solution is and has always been to use complex functions. That's what they were designed for. The module interface is already unstable at best. Adding even more features that require synchronization is not a good idea. Fvwm already freezes way too often because of deadlocks with the modules. > > > > > 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. > > It keeps an internal window list and applies some actions to windows. > Just like FvwmWindowLister is a window list module although it does not > show a permanently visible list of windows. I don't know how you would work with it, but I would never use the WindowListFunc with FvwmProxy because it works totally different that the other window listing modules. (I chose a copy of WindowListFunc only to not have to worry about it for a moment). > > > 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. > > See above how other modules solved this. Yes, I know how other modules solved this: they didn't. They are simply hell to configure for a beginner. > > > 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. > > Looks acceptably good and modular to me. Well, if that is your opinion, I think I am maybe working on the wrong window manager. I am struggling hard to improve fvwm's usability and to clean up the most screwed interfaces, and all I ever hear is that the current state is nice and changing it is useless. Fvwm will never grow beyond it's "flexible maybe, but too hard to configure" image this way. > It is possible to make it shorter: > > *FvwmProxy: InternalAction Click2 Abort > > But I am not sure adding alternative ways to achieve one thing is needed. Huh? Who is adding alternative ways to what? 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]
