On Thu, Oct 18, 2007 at 10:51:35PM -0400, Devin Mullins wrote:
On Thu, Oct 18, 2007 at 05:06:41PM +0200, Andrea Rossato wrote:
I do have an opinion on the subject... <snip opinion>
What Andrea said. I was thinking about some of the annoying hacks I had to do for UrgencyHook, and being able to configure a list of hooks that could be wired to listen on any event(s) would make the requirement for a new top level binding in Config.hs go away, and hence not require the user to mess with Config.hs-boot.
This, however, is orthogonal to Joachim's proposal. His proposal could reduce the pain for users of adding more hooks, but wouldn't reduce the danger of an over-complex API, which I think is our primary concern. But I agree, event hooks should go in. The question is in what form. e.g. we may find that reasonable uses of event hooks require the ability to store state, as layouts do. It'd be a shame to add a hook in a form that required non-trivial event-hooks to be implemented as layout modifiers after all. e.g. what if we want a hook that binds a key an event to focus the most-recently-urgent window. This is reasonably easily implemented as a layout modifier, but would require the use of unsafePerformIO to construct a global variable when implemented with Joachim's proposed hooks. Or perhaps using the X server to store the global variable (as the tags extension does)... but I'm not convinced that the X server is the best location for global variables. Maybe it is. -- David Roundy Department of Physics Oregon State University