On Tue, Nov 13, 2007 at 09:58:52AM -0500, Devin Mullins wrote:
On Mon, Nov 12, 2007 at 01:00:15PM -0800, David Roundy wrote:
I'm sold on the state thing (so long as it can be implemented cleanly), and you had me at hello with the Message thing, but I haven't budged as regards the Read/Show requirement.
Fortunately, that last also seems to me to be the least important. I'd lean towards including it, since it seems like if you introduce a read-failing event-hook, all you've lost is whatever was gained by introducing the Read/Show requirement. So you don't lose anything by introducing the change (so far as I know).
Grrr. Events were very easy to do -- just intercept the call to handle. Messages come from several places, but (the important ones?) pass through broadcastMessage. However, unhandled Events do, too. Double trigger seems bad.
True, it would require a bit of restructuring. Really, there are three ways messages should originate: either as an unhandled Event (currently broadcast), or via sendMessage or broadcastMessage. The latter two differ in that sendMessage sends it only to the focussed layout, while broadcastMessage sends the message to all layouts. I think we ought to be able to handle this with a minimal amount of restructuring. handle itself could trivially be rewritten as a messageHook. Then the main event look could simply call broadcastMessage on every X Event that comes down the pipeline. broadcastMessage would first supply the message to the messageHook (or messageHooks), and if it isn't handled would then supply it to all layouts. sendMessage (I imagine) would first give the message to the messageHook and then to the focussed layout. To me, subsuming handle in the messageHook framework sounds highly appealing. One advantage of this self-modifying hook framework would be that we ought to be able to eliminate the "dragging" field in XState, which is really just there to hold an eventHook. One advantage of *not* making MessageHooks readable is that it'd make it easier to write a self-removing hook, which would be what we'd want for something like a dragging hook: we'd want it to just disappear when the dragging is finished. I think we've got lots of good ideas here. Do you think you can code up a prototype? I have a feeling we could stick most of the code in contrib, so we could develop together and test it with only minimal changes to core. We could, for instance, replicate all of XMonad.Main in contrib, so that we (and other users) could simply call XMonad.Hooks.Main.xmonad instead of XMonad.Main.xmonad. I think that'd be an ideal testing ground, and would allow us to develop this in a leisurely manner without conflicting with core changes. Then acceptance into core would consist of a simple copy of XMonad.Hooks.Main to XMonad.Main and a redefinition of XMonad.Operations.broadcastMessage. I think handling sendMessage could be done subsequently. We might not even want sendMessage to go to messageHooks, since in a sense it is a "targeted" message, sent specifically to the current layout. In any case, we could wait on rewriting sendMessage to go throught the messageHooks. Have you (Devlin) got time to get this going? -- David Roundy Department of Physics Oregon State University