On 22 Mar 2009 10:48:55 +0100, Viktor Griph wrote: > > 2009/3/22 Mikhael Goikhman <[email protected]>: > > > > 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.
Well, the need of Send_Reply is not disputable. I only thought why to invent a new event type when we already have one. But I ended up with the same justification (easier to identify/monitor/parse own requests). > > 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. Yes, synchronization with fvwm is one of the main purposes, I even gave an example for this, with "Send_Reply end". :) > > 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.) Well, the Scheduler tracker in perllib assigns a random base number to be 8000000 + int(rand(900000)) that is increased on every usage, so the collisions are very unlikely. Please consider the range 8000000-8999999 to be reserved for perllib modules. :-) Of course it would be better if Schedule command could operate on 2 ids (so one may be a module id), or maybe on double/float instead of integer. This would reduce collisions drastically, although the current situation is not very bad too. There are other solutions of course. Add special support for modules in Schedule, so that a schedule id is only unique inside one subject (fvwm or any module). This is a part of the larger task: make the currently global state (like the last menu or function for "+" command) to be module aware, so that use of "+" or $[cond.rc] or even $[schedule.next] from different modules would never collide (fvwm should store separate global state structures for itself and each module). Another current solution is to request "Send_Reply $[schedule.last]" after each Schedule from a module (this id is needed for Deschedule). But this means adding one more synchronization with fvwm just for this, that is a bit of an overkill. > > 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. Regards, Mikhael.
