2009/3/22 Mikhael Goikhman <[email protected]>: > I don't remember a discussion when the new event type MX_REPLY was > added, so I will tell my observations now.
There was no discussion. I introduced it to get rid of the extreme delay in motion when moving around the viewport by dragging button 2 in FvwmPager. > > At the very first I thought, why do we need this event type when we > already have M_STRING. But of course the answer is clear. When a module > requests SendToModule back, then the event is sent to 0 upto N modules, > and when it requests Send_Reply instead then it is sent exactly to one > module, to itself. Exactly. When I added Send_Reply I were using a config with two pagers, so using SendToModule would have required the modules to be able to identify SendToModule replies issued by themselves, or my other modules using the same name. While this can be done by adding some instance unique identification string, the modules would still have to deal with any string sent to them, since SendToModule can be used by anyone be it another module, or the user. MX_REPLY messages on the other hand are known to originate from the same module, and may therefore be parsed in a less tolerant way by the module. > > So a module should usually avoid the SendToModule technique in favor of > Send_Reply. Of course, anywhere outside the module, SendToModule is > still currently the only way to communicate. > > There are several interesting use cases for Send_Reply: > > 1) To ask fvwm to expand internal fvwm variables or translations: > [...] > 2) To ask fvwm to select a window for a module to operate on: > [...] Don't forget the case it was implemented for: 3) To let the module know when fvwm has processed commands sent to it. (FvwmPager sends Scroll commands to fvwm followed by a "Send_Reply ScrollDone", and while waiting for the ScrollDone reply it will aggregate any additional Scroll requests internally and send them when the ScrollDone is received. > > However, there is still one case when the module can't avoid > SendToModule, when it asks fvwm to alarm itself in 10 seconds: > > Schedule 10000 898989 SendToModule ModuleNameOrAlias alarm > > Unfortunately this does not currently work: > > Schedule 10000 898989 Send_Reply alarm > > I think this is quite useful and may be considered as a bug. I'll see > how to fix this use case in Schedule. Yes, it could be useful to allow for that. Of course using a schedule id from within the module might be a bad idea, since it would introduce a collision risk with user configs and other modules. (Or other instances of the same module.) > > Maybe later we should have a module context just like a window context, > anywhere, not only in Schedule. So even if there are several modules of > the same name running, it would be still possible to target the correct > one. Think ModuleId (WindowId), $[module.id] ($[w.id]), NextModule > (Next), AllModules (All) and so on. Then "SendToModule ModuleName" > would be just another way to say "AllModules (ModuleName) Send_Reply". > This is not a complete proposal, just a material to think. After 2.6. I like the idea of a module context, but not before 2.6. /Viktor
