darcs patch: use a global IORef to keep list of urgent windows

Somebody asked for the ability to display which workspaces had urgent windows in them in the logHook.
Well, here it is. (Well, the core state-tracking functionality.) Please provide input on:
- If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.)
- If it's useful (whoever you were that asked for it)
Sat Oct 27 02:48:10 EDT 2007 Devin Mullins

On Sat, Oct 27, 2007 at 02:52:28AM -0400, Devin Mullins wrote:
- If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.)
Well, after looking at some of the relevant comments in GHC/{IOBase,STRef,ST}.lhs, I feel more confident that both are true. 1. The NOINLINE should eliminate duplicate newIORefs and order of ops is safe here. 2. IORef (at least in GHC) use STRef, which uses ST, which is strict in its state. However, I'm having some other odd problems (repeatable!): - If I mod-q xmonad while xchat is the current window, xchat no longer sends urgent events. Opening prefs and hitting ok (no changes) fixes it. - If I mod-q xmonad while I've got a child dzen process open (via XMC.Dzen.dzenUrgencyHook), the new xmonad no longer responds to keyboard events. It responds to mouse events (the border moves with focus). This is not the case for dzens spawned via: spawn "(date; sleep 2) | dzen2" In fact, the behavior is a little more nuanced. After I mod-q, while the dzen is still open, I can hit mod-j, and I see the focus temporarily move, and then snap back when I keyup. After the dzen goes, 'j' gets sent to the client window. Help! Devin

On Sat, Oct 27, 2007 at 02:52:28AM -0400, Devin Mullins wrote:
Somebody asked for the ability to display which workspaces had urgent windows in them in the logHook. Well, here it is. (Well, the core state-tracking functionality.) Please provide input on:
- If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.) Clarification: Those bugs I mentioned in the last email applied before this patch, too.
- If it's useful (whoever you were that asked for it) shachaf says he can make it work. He should submit a logHook helper (perhaps in UrgencyHook, because of the extra dependency on Config.urgencyHook) when he's done. :)
Any other reason this isn't applied? Devin

me:
On Sat, Oct 27, 2007 at 02:52:28AM -0400, Devin Mullins wrote:
Somebody asked for the ability to display which workspaces had urgent windows in them in the logHook. Well, here it is. (Well, the core state-tracking functionality.) Please provide input on:
- If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.) Clarification: Those bugs I mentioned in the last email applied before this patch, too.
- If it's useful (whoever you were that asked for it) shachaf says he can make it work. He should submit a logHook helper (perhaps in UrgencyHook, because of the extra dependency on Config.urgencyHook) when he's done. :)
Any other reason this isn't applied?
You expressed hesitation? :) -- Don

me:
Any other reason this isn't applied? You expressed hesitation? :) Point. ;) Well, for the record, consider me un-hesitating. I'd still
On Mon, Oct 29, 2007 at 10:08:32PM -0700, Don Stewart wrote: like input on those restart bugs, but they're orthogonal to the patch.

me:
me:
Any other reason this isn't applied? You expressed hesitation? :) Point. ;) Well, for the record, consider me un-hesitating. I'd still
On Mon, Oct 29, 2007 at 10:08:32PM -0700, Don Stewart wrote: like input on those restart bugs, but they're orthogonal to the patch.
Oh, that's an issue -- now you've hidden state away in a module, how are we going to get at it to serialise? This is why global state is bad. If the state was threaded through lambdabot, again, we'd be able to flush it out when restarting. So now I'm more hesitant about encouraing refs for state -- its inherently going to break serialisation/restart persistence. -- Don

On Tue, Oct 30, 2007 at 08:25:14AM -0700, Don Stewart wrote:
me:
me:
Any other reason this isn't applied? You expressed hesitation? :) Point. ;) Well, for the record, consider me un-hesitating. I'd still
On Mon, Oct 29, 2007 at 10:08:32PM -0700, Don Stewart wrote: like input on those restart bugs, but they're orthogonal to the patch.
Oh, that's an issue -- now you've hidden state away in a module, how are we going to get at it to serialise? This is why global state is bad.
If the state was threaded through lambdabot, again, we'd be able to flush it out when restarting.
So now I'm more hesitant about encouraing refs for state -- its inherently going to break serialisation/restart persistence.
There is certainly state that shouldn't be serialized. Mightn't the list of urgent windows fall in this category? -- David Roundy Department of Physics Oregon State University

On Oct 30, 2007, at 11:25 , Don Stewart wrote:
Oh, that's an issue -- now you've hidden state away in a module, how are we going to get at it to serialise? This is why global state is bad.
Urgency hints are ephemeral state, for which the window manager is *not* authoritative; you do not want to save it, you want to reconstruct it on restart by checking extant windows' urgency hints. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

allbery:
On Oct 30, 2007, at 11:25 , Don Stewart wrote:
Oh, that's an issue -- now you've hidden state away in a module, how are we going to get at it to serialise? This is why global state is bad.
Urgency hints are ephemeral state, for which the window manager is *not* authoritative; you do not want to save it, you want to reconstruct it on restart by checking extant windows' urgency hints.
Yes, which opens up the issue of how you initialise state on restart with extensions, as they don't provide setup or teardown methods. So while for this particular case, local iorefs will work, its not a scalable solution to extensions needing state. -- Don

dons:
me:
me:
Any other reason this isn't applied? You expressed hesitation? :) Point. ;) Well, for the record, consider me un-hesitating. I'd still
On Mon, Oct 29, 2007 at 10:08:32PM -0700, Don Stewart wrote: like input on those restart bugs, but they're orthogonal to the patch.
Oh, that's an issue -- now you've hidden state away in a module, how are we going to get at it to serialise? This is why global state is bad.
If the state was threaded through lambdabot, again, we'd be able to flush it out when restarting.
Did I say lambdabot? -- Don

me:
Somebody asked for the ability to display which workspaces had urgent windows in them in the logHook. Well, here it is. (Well, the core state-tracking functionality.) Please provide input on: - If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.) - If it's useful (whoever you were that asked for it)
Sat Oct 27 02:48:10 EDT 2007 Devin Mullins
* use a global IORef to keep list of urgent windows
This is the patch you want applied?

me:
Somebody asked for the ability to display which workspaces had urgent windows in them in the logHook. Well, here it is. (Well, the core state-tracking functionality.) Please provide input on: - If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.) - If it's useful (whoever you were that asked for it)
Sat Oct 27 02:48:10 EDT 2007 Devin Mullins
* use a global IORef to keep list of urgent windows
Applied. -- Don
participants (4)
-
Brandon S. Allbery KF8NH
-
David Roundy
-
Devin Mullins
-
Don Stewart