[xmonad] Issue 543 in xmonad: StackSet: non-positive argument to StackSet.new with mroe monitors than workspaces

[c***@google.com]

Status: Accepted
Owner: ***@gmail.com

New issue 543 by ***@gmail.com: StackSet: non-positive argument to
StackSet.new with mroe monitors than workspaces
http://code.google.com/p/xmonad/issues/detail?id=543

At http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706149 this bug was
reported (Version 0.10):


My xmonad configuration only sets up a single workspace: I create the
rest dynamically as I need them. I use a laptop, and sometimes have an
external monitor. If I have a single workspace when I attach the second
monitor, xmonad fails to start.

A minimal .xmonad.hs that exhibits the problem:

--- 8< ---
import XMonad
import XMonad.Config.Gnome

main :: IO ()
main = do xmonad $ gnomeConfig { workspaces = ["GTD"] }
--- 8< ---

Procedure for reproducing:

* Use the above .xmonad.hs.
* Log into a GNOME+Xmonad session in wheezy.
* If there are two monitors, xmonad fails to start.
* If there is a single monitor, this works. If I attach a second monitor,
xmonad does not crash. However, re-starting it (e.g., due to a
change to .xmonad.hs) doesn't work.

The error message xmonad gives when starting up:

xmonad-x86_64-linux: xmonad: StackSet: non-positive argument to StackSet.new

I am probably unsual in liking to create my workspaces dynamically on
demand. However, it would be good if xmonad would at least start even
if it can't have something on every monitor.

[c***@google.com]

Comment #1 on issue 543 by ***@gmail.com: StackSet: non-positive
argument to StackSet.new with mroe monitors than workspaces
http://code.google.com/p/xmonad/issues/detail?id=543

Here's the relevant code from XMonad.StackSet:

-- | /O(n)/. Create a new stackset, of empty stacks, with given tags,
-- with physical screens whose descriptions are given by 'm'. The
-- number of physical screens (@length 'm'@) should be less than or
-- equal to the number of workspace tags. The first workspace in the
-- list will be current.
--
-- Xinerama: Virtual workspaces are assigned to physical screens, starting
at 0.
--
new :: (Integral s) => l -> [i] -> [sd] -> StackSet i l a s sd
new l wids m | not (null wids) && length m <= length wids && not (null m)
= StackSet cur visi unseen M.empty
where (seen,unseen) = L.splitAt (length m) $ map (\i -> Workspace i l
Nothing) wids
(cur:visi) = [ Screen i s sd | (i, s, sd) <- zip3 seen [0..] m ]
-- now zip up visibles with their screen id
new _ _ _ = abort "non-positive argument to StackSet.new"

As you can see the comment even explicitly states the precondition that
there must be more workspaces than screens. Unfortunately a fix for this
is not trivial because of the way we keep track of screens in the StackSet,
where each screen is actually a wrapper around a visible workspace. So if
we don't have enough workspaces we are literally unable to construct the
required Screen objects.

Perhaps changing the definition of Screen to include a Maybe Workspace
would work, though I am not sure what other changes that would require.

[c***@google.com]

Comment #2 on issue 543 by ***@gmail.com: StackSet: non-positive
argument to StackSet.new with mroe monitors than workspaces
http://code.google.com/p/xmonad/issues/detail?id=543

Given that we already support dynamic workspaces, maybe the easiest fix is
to just generate the necessary workspaces on the fly.

[c***@google.com]

Comment #3 on issue 543 by ***@gmail.com: StackSet: non-positive
argument to StackSet.new with mroe monitors than workspaces
http://code.google.com/p/xmonad/issues/detail?id=543

That would be easiest, perhaps, but I think it kind of misses the point.
For one thing, what should those workspaces be called? And presumably OP
does not want some auto-generated workspaces hanging around to be cycled
through or switched to etc., they want just one workspace. Having fewer
workspaces than screens seems like a perfectly reasonable edge case to me.

[c***@google.com]

Comment #4 on issue 543 by ***@gmail.com: StackSet: non-positive
argument to StackSet.new with mroe monitors than workspaces
https://code.google.com/p/xmonad/issues/detail?id=543

Has there been any progress on this one? I stumbled on this issue when
setting up dynamic workspaces. XMonad failing to run still while compiling
made me think that this is not very elegant, and unintuitive towards new
users.

[c***@google.com]

Comment #5 on issue 543 by ***@gmail.com: StackSet: non-positive
argument to StackSet.new with mroe monitors than workspaces
https://code.google.com/p/xmonad/issues/detail?id=543

Maybe the auto-generated workspaces should be prefixed somehow that when
creating a new workspace, it first just renames or deletes/creates one of
those?