On Wed, Jun 13, 2007 at 11:50:37PM +1000, Donald Bruce Stewart wrote:

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?

I'm not thinking that grandly (although it'd be exciting). I was just thinking that we could refactor the existing code so that instead of storing data XState = XState { ... , layouts :: !(M.Map WorkspaceId (Layout, [Layout])) -- | Virtual workspace indicies newtype WorkspaceId = W Int deriving (Eq,Ord,Show,Read,Enum,Num,Integral,Real) we define something like (and this is a sketch, not a proposed naming scheme) data WorkspaceId' = Tag WorkspaceId (Layout, [Layout]) so that we don't need the layouts field in XState. Then we have type WindowSet = StackSet WorkspaceId' Window ScreenId and when we want the layout for a given workspace, it's right there in the tag. We'd need to be careful when comparing tags (e.g. when selecting a given workspace) to only compare the WorkspaceId portion of it. But we could do this with no change in functionality and almost no change in layouts code. We'd eliminate one field from XState and have one less Map to keep in sync with the rest of the code. With the cleaner data structure, we could introduce dynamic addition and deletion of workspaces in a way that is completely implementable in the pure StackSet and checkable by quickcheck tests. Of course, we could also just be mundane and switch the tag to a String, which I imagine would enable simplifications and beautifications in your status bar extensions, since users could just specify in their Config file once and for all that they want workspaces ["mutt","iceweasel",...]. Even with this minor feature, we'd be tempted to add similar functionality to StackSet to what we'd want for the ambitious Layout idea above: the first feature I'd be interested in (or second) would be the ability to change the tag of a workspace, since I don't know in advance what I'll be working on. This wouldn't be hard. -- David Roundy http://www.darcs.net

On Wed, Jun 13, 2007 at 09:43:39AM -0500, Spencer Janssen wrote:

On Wed, 13 Jun 2007 06:44:01 -0700 David Roundy wrote:

...

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.

I've wanted to get layouts into StackSet for some time now. However, we need to figure out how to serialize layouts before we can make that change.

Hmmm. I've thought about this and have two ideas, which work out to almost the same thing. I assume we'll have to add a field or two to the Layout record, something like: data Layout = Layout { ... , showL :: String , readL :: String -> Maybe Layout } then writing out the layouts is trivial (we could even define a Show instance for Layout itself). Reading is trickier, since we have not one readL function but many. Still, reading isn't too hard: readLayouts :: [String] -> [Layout] readLayouts ss = concatMap readLayout ss where readLayout s = take 1 $ catMaybes $ map (\l -> readL l s) defaultLayouts With a little care to avoid troubles with getting an empty list, we've got a working solution. If two Layouts claim to be able to read a single serialized Layout, we accept the one that's first in the user's list. There are fancier ways we could do this, if we wanted to respect the order of layouts which is in the user's Config file, but those would break features (which could be added) in which the user adds or removes layouts from a workspace on a dynamical basis. e.g. if a given application behaves very poorly (and not easily reversibly) when put into a given layout, I might want to remove that layout from the workspace I use with that application. We could also create a function to make a very simple show/read: serializeLayout :: String -> Layout -> Layout serializeLayout uniqueToken l = l { showL :: uniqueToken, readL = r } where r t | t == uniqueToken = Just l | otherwise = Nothing so that it'd be easy to wrap up existing layouts. They wouldn't preserve their layout state, but they'd work as well as they currently do. -- David Roundy Department of Physics Oregon State University

On Wed, Jun 13, 2007 at 03:15:03PM -0700, Stefan O'Rear wrote:

On Wed, Jun 13, 2007 at 09:43:39AM -0500, Spencer Janssen wrote:

...

...

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.

Yes, this is a good idea. After all, a floating layout is just a layout that happens to listen to windows requested sizes.

Sadly, xmonad's current floating layer is NOT such a floating layout because it is stateful - it allows you to resize windows.

Layout-level state is not an option because then the windows would forget their size when moved between workspaces.

The only reasonable approach I can think of (_XMONAD_USER_SIZE properties) is probably unacceptable because it is deeply untyped.

That's something I've wondered about. Why do we need to store the size and position, doesn't X store the size of windows, even when you've hidden them? I imagine that it has to do with Xinerama, and have speculated as to solutions, but would rather not bore you with my speculations without knowing why exactly we feel the need to store those RationalRects. -- David Roundy Department of Physics Oregon State University

On Wed, Jun 13, 2007 at 05:03:32PM -0700, Stefan O'Rear wrote:

On Wed, Jun 13, 2007 at 04:57:41PM -0700, David Roundy wrote:

...

On Wed, Jun 13, 2007 at 03:15:03PM -0700, Stefan O'Rear wrote:

...

On Wed, Jun 13, 2007 at 09:43:39AM -0500, Spencer Janssen wrote:

...

...

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.

Yes, this is a good idea. After all, a floating layout is just a layout that happens to listen to windows requested sizes.

Sadly, xmonad's current floating layer is NOT such a floating layout because it is stateful - it allows you to resize windows.

Layout-level state is not an option because then the windows would forget their size when moved between workspaces.

The only reasonable approach I can think of (_XMONAD_USER_SIZE properties) is probably unacceptable because it is deeply untyped.

That's something I've wondered about. Why do we need to store the size and position, doesn't X store the size of windows, even when you've hidden them? I imagine that it has to do with Xinerama, and have speculated as to solutions, but would rather not bore you with my speculations without knowing why exactly we feel the need to store those RationalRects.

It definitely has nothing to do with Xinerama. Probably it has a lot to do with the fact that we used to hide windows by moving them offscreen; this needs to be re-evaluated. As such I'm CC-ing the deciders.

Ah, then an easy solution would seem to be to move windows offscreen by a fixed distance (chosen perhaps to be larger than any reasonable viewable area, or perhaps chosen at runtime to be larger than the actual screen area). But why is it that we can't just unmap the windows? (possibly displaying my ignorance...) -- David Roundy Department of Physics Oregon State University

On Wed, Jun 13, 2007 at 06:02:53PM -0700, Stefan O'Rear wrote:

...

...

It definitely has nothing to do with Xinerama. Probably it has a lot to do with the fact that we used to hide windows by moving them offscreen; this needs to be re-evaluated. As such I'm CC-ing the deciders.

Ah, then an easy solution would seem to be to move windows offscreen by a fixed distance (chosen perhaps to be larger than any reasonable viewable area, or perhaps chosen at runtime to be larger than the actual screen area).

But why is it that we can't just unmap the windows? (possibly displaying my ignorance...)

Indeed. :) I used past tense, because unmapping is what we do now.

Ah, yes, I see that you did use the past tense... so presumably we no longer would need to store and restore those positions? -- David Roundy Department of Physics Oregon State University

On Wed, Jun 13, 2007 at 06:12:00PM -0700, Stefan O'Rear wrote:

On Wed, Jun 13, 2007 at 06:08:01PM -0700, David Roundy wrote:

...

On Wed, Jun 13, 2007 at 06:02:53PM -0700, Stefan O'Rear wrote:

...

...

...

It definitely has nothing to do with Xinerama. Probably it has a lot to do with the fact that we used to hide windows by moving them offscreen; this needs to be re-evaluated. As such I'm CC-ing the deciders.

Ah, then an easy solution would seem to be to move windows offscreen by a fixed distance (chosen perhaps to be larger than any reasonable viewable area, or perhaps chosen at runtime to be larger than the actual screen area).

But why is it that we can't just unmap the windows? (possibly displaying my ignorance...)

Indeed. :) I used past tense, because unmapping is what we do now.

Ah, yes, I see that you did use the past tense... so presumably we no longer would need to store and restore those positions?

Right.

Hmm. Consider: Suppose you have some windows on screen 1, and you hide that workspace. Later, you make that workspace visible on a different scren. Now to position the floating windows correctly, you have to check if they are on a different screen, and if they are, translate their coordinates to the current screen. Remember that screens can be different sizes. Moving between workspaces would be fairly easy: You could just move them there in the StackSet, and then it would get moved on the screen on "refresh". You would need to always be able to figure out which screen a window was on: What would you do if the upper-left corner of the window got moved off the screen? Just not allow it? You could end up with some weird states if you weren't careful. (Not that the current code is any better: You can "lose" windows by dragging them across screens because xmonad still thinks they're on the same workspace, so they get drawn under the tiled windows of the other workspace) It seems workable, but I have doubts as to whether it's actually better. Jason Creighton

xmonad:

Jason Creighton writes:

[...]

...

Hmm. Consider: Suppose you have some windows on screen 1, and you hide that workspace. Later, you make that workspace visible on a different scren. Now to position the floating windows correctly, you have to check if they are on a different screen, and if they are, translate their coordinates to the current screen. Remember that screens can be different sizes.

It would also be nice if windows remembered their dimensions when tiled in ordinary layouts, so you could tile a transient for a little while, then float it again with its previous dimensions. I'm not sure how critical that would be, though.

Yes, I think we can do that. Its part of my floating stack branch.

Another possibly useful feature would be to respect ordering of floating windows. transient is a relation, not a boolean so a collection of floating windows is partially ordered by it, which I don't think is respected in any way by xmonad.

On the other hand, it's sometimes really annoying when window managers *do* respect that, and refuse to show you the dialog under the topmost window. And probably it doesn't matter greatly. It's not bothered me so far since the floating support came in.

Good to know. I like xmonad's 'disrespectful to clients' philosophy too :-) Client windows don't know what's good for them! -- Don

On Wed, Jun 13, 2007 at 10:40:14PM -0600, Jason Creighton wrote:

Hmm. Consider: Suppose you have some windows on screen 1, and you hide that workspace. Later, you make that workspace visible on a different scren. Now to position the floating windows correctly, you have to check if they are on a different screen, and if they are, translate their coordinates to the current screen. Remember that screens can be different sizes.

Moving between workspaces would be fairly easy: You could just move them there in the StackSet, and then it would get moved on the screen on "refresh".

You would need to always be able to figure out which screen a window was on: What would you do if the upper-left corner of the window got moved off the screen? Just not allow it? You could end up with some weird states if you weren't careful. (Not that the current code is any better: You can "lose" windows by dragging them across screens because xmonad still thinks they're on the same workspace, so they get drawn under the tiled windows of the other workspace)

It seems workable, but I have doubts as to whether it's actually better.

The current code seems rather flawed also: it doesn't preserve window size or aspect ratio when float windows move between screens. The window will still be visible, but I'd say that preservation of window dimensions is a good idea. The point of the floating layer seems to be to deal with windows that for one reason or another don't behave well when scaled to different dimensions. Why not just translate floating windows by the upper-left corner of their current screen when they're hidden? Then we'd preserve their aspect-ratio and position as absolute coordinates, which is what I would want myself (if I had more than one screen). You might not be able to see them on a smaller screen, but you could always move them back to the original screen (or put them into tiled mode temporarily?). Or we could have a special-case check that we don't show floating windows without putting them so they're somehow visible. -- David Roundy http://www.darcs.net