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

On Fri, May 25, 2007 at 08:23:55AM +0900, Robert Marlow wrote:

On Thu, 2007-05-24 at 09:14 -0700, David Roundy wrote:

...

On Wed, May 23, 2007 at 10:09:56PM -0500, Spencer Janssen wrote:

...

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.

I had a look into this yesterday. Additional to what has been mentioned, it'd require a small change to Operations.refresh. Unfortunately much of Operations.hs and Main.hs depend on refresh so all these functions would also need to be rewritten to use any new implementation of refresh. So it's not something that can easily be put into Contrib. It would be much simpler to modify Operations.refresh directly.

The idea (I think) would be to modify Operations and StackSet to not barf on sticky windows, but leave the current behavior unmodified. Then the actual interface to make windows sticky could be developed in Contrib. -- David Roundy Department of Physics Oregon State University