droundy:
Hi all,
This is a change that's more pervasive than I'd originally intended. The idea is to move away from the dependence on workspace tags being integers from 0 to size s, so that we can easily have more friendly tags, such as String.
This also could move us in directions of putting extra information in the tag. e.g. if we stored the (Layout, [Layout]) in the tag itself, then we'd be able to eliminate one additional data structure, and we'd have the benefit that the pure StackSet code could track our layouts for us. I'm not sure this is worthwhile, but the idea came to me, as I was trying to figure out how you'd recognize which Layout went with which Stack, and realized that they're tracked totally separately, which seems more than a little silly.
This seems particularly relevant as dons is talking about creating a Stack for the float layer (which makes lots of sense to me), and I'll be voting for allowing custom layouts to the float layer: part of my grand scheme to make the float layer an equal citizen with other layout systems, but also useful for people who want tabs on their windows so they can see titles and drag them around with the use of only one hand.
Anyhow, it's a sort of pervasive change--mostly in terms of the number of quickcheck tests that required modification because they call new--but I believe it's basically a simple and safe change also, and amenable to code review--which is why I didn't change any functionality, except that the tests no longer assume that workspaces are numbered 0..n-1.
Seems eminently reasonable. Though I wonder how we allow layouts to specify, combine, or override the tag type? How do we take advantage of a more liberal tag type, or are we not looking that far ahead yet? -- Don