
On Wed, May 23, 2007 at 10:09:56PM -0500, Spencer Janssen wrote:
David Roundy
wrote: Is there now any reason why we can't have sticky windows? I'd love to be able to show the same xclock on every workspace, instead of having to start N xclocks. Actually, I'd like something akin to dwm's tagging, I believe (although I've never used it). I want something like "copy this window to that workspace." Is there any reason this would be tricky? Or undesirable? I have no idea how it'd interact with Xinerama, since two visible workspaces could then both contain the same window.
Potential issues with multi-workspace windows in the current StackSet: - functions like findIndex and delete assume a window is on only one workspace. You'll have trouble after the window closes. We could probably change this behavior.
Makes sense. It also will make our QuickCheck properties more robust: we can allow the Aribtrary instance to generate configurations with duplicate instances of windows.
- multi-screen: when trying to view a window on two screens, the window will only be visible on the last screen rendered. There will be a gap in one screen, but perhaps that's not a big deal?
Hmmm. Better with no gap, but that'd certainly no big deal as long as it's in XMonadContrib, and we'll see if Xinerama users actually want sticky windows.
- insert will refuse to add a duplicate window. I'm convinced this is the right behavior by default -- multi-tagging should be a separate function.
I think I'd disagree here. It seems like anything that could be meaningful and isn't statically disallowed should have an effect. Perhaps we need to functions, move and copy? Both would have an effect when adding a duplicate window, but the effect would be different. I just don't see the point of an (exported) function that doesn't have an effect in some cases.
If we change the delete behavior, I think we can do this in XMonadContrib. What do you think?
That seems to be the way to go. -- David Roundy Department of Physics Oregon State University