droundy:

On Mon, Jun 25, 2007 at 02:54:05PM +1000, Donald Bruce Stewart wrote:

...

droundy:

...

Sorry, I forgot to send this earlier. These are the changes needed to support sticky windows.

David

Sun Jun 24 07:48:54 PDT 2007 David Roundy * simplify StackSet.delete

Sun Jun 24 07:59:31 PDT 2007 David Roundy * make delete work when window is in multiple workspaces.

Sun Jun 24 08:02:08 PDT 2007 David Roundy * fix apparent memory leak when floating windows are deleted.

In retrospect, I think this last one may be broken. I'm not sure when floating windows have their RationalRectangle deleted, but perhaps delete is not the right time. I'd really rather we didn't store these silly things...

...

David, can you talk about why/what is needed to support sticky windows, how the current semantics have to change, and any consequences that might result from these changes? Are there some quickcheck properties that can establish the stickyness works?

The current semantics only need to change is: (i) when a window is closed we need to delete it from all workspaces and (ii) when layout out workspaces on the screen, we'd like to ensure that each window is handled just once. This second change is really optional (and debateable). It's not too bad having gaps where sticky windows are located, and has the nice property that changing focus from one screen to another doesn't change one's layout.

Neither of these changes affect any of the behavior of core xmonad when copy is not used, because in core xmonad you can never place a window in two workspaces at the same time.

I'm not sure what you mean by the stickiness "working". It just means a window exists in multiple workspaces. I guess you might want to check that after deleting a window it isn't present in the stackset, even if it's present in multiple workspaces to start out. The second property involves code in the X monad which isn't currently quickcheckable.

How does it interact with Xinerama, if we're viewing multiple workspaces simultaneously?

...

More discussion please!

To actually *use* stickiness (rather than just allowing it), you need two more functions... well only one really, depending how flexible you want to be. You need a function to add a window to a second (or third) workspace, which I call copy, and which behaves almost like shift. Or you could forget flexibility and only allow a window to be made 100% sticky, but that seems less nice. And you'd also like to have a function to remove a window from a given workspace without closing it (unless this is its only incarnation). I called this kill1.

Basically, stickiness is almost trivial with the design of xmonad. All you really need is to ensure that delete gets rid of all copies of a window, and that change doesn't affect the non-sticky semantics at all.

I think, given there's no discussion with the core devs about these changes, you should propose 'sticky windows' or something like that, as a feature request on the bug tracker, so we can consider it. It's hard to appraise, and apply, large patches that land on the mailing list, without first planning the design with the core team -- particularly if they change basic invariants (like no-duplicates in the stackset). So, usual 'please give us a compelling use case' and 'assurances nothing breaks' :-) -- Don

dons@cse.unsw.edu.au (Donald Bruce Stewart) writes:

How does it interact with Xinerama, if we're viewing multiple workspaces simultaneously?

My suggestion is to order the screens, and if a window is potentially visible on more than one screen, then we display it on the first screen in that order. I think it is better not to always display these windows on the screen that has focus, since often sticky windows are intended to contain information that one refers to from time to time, and that one wishes to have visible at all times, but not necessarily so much in one's face. Then the only "bad" consequence from sticky windows is that displaying workspace A sometimes shows window B and sometimes doesn't, depending on which other workspaces are also visible at that time. Also, it may be that switching workspaces on screen X changes which windows are visible on screen Y. Not that nice, but can't be avoided. Kai