[Xmonad] sticky windows?

David Roundy droundy at darcs.net
Thu May 24 12:14:09 EDT 2007


On Wed, May 23, 2007 at 10:09:56PM -0500, Spencer Janssen wrote:
> David Roundy <droundy at darcs.net> 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


More information about the Xmonad mailing list