dons:

jcreigh:

...

Wed May 30 22:47:33 MDT 2007 Jason Creighton * first shot at a floating layer

This is a first attempting at a floating layer:

mod-button1: move window mod-button2: swapMaster mod-button3: resize window

mod-t: make floating window tiled again

Moving or resizing a window automatically makes it floating.

Known issues:

Hard to manage stacking order. You can promote a window to move it to the top, (which you can do with mod-button2) but it should be easier than that.

Moving a window by dragging it to a different Xinerama screen does not move it to that workspace.

Code is ugly.

We'll be playing with this, and thinking about it for a few days.

In fact, this is really nice! Great work Jason. This is very exciting: it makes some apps (gimp!) a lot more usable. The patch is in now the repo, for brave souls. Here's a screenshot of a couple of floating windows over a wide pane: http://www.cse.unsw.edu.au/~dons/tmp/float.png -- Don

On Thu, May 31, 2007 at 09:37:34PM +0100, Bruce Stephens wrote:

It makes using things like gkrellm possible: I can start it, and then conveniently float it somewhere out of the way. On the other hand, for things like gkrellm, I really *want* that to remain visible when I switch workspaces.

Maybe there's a place for a per-screen decoration layer, always visible, in which I can stick clocks, status bars, GNOME panels, etc.? Hmm, maybe just things that just display information (rather than interact)? (And then maybe I could use xcompmgr or something to make them translucent?)

Let's keep the number of layers down, and just allow windows to be present in multiple workspaces.

Another (much more trivial) decoration I'd like is the number of the workspace. I guess that could use the per-workspace floating layer. (I imagine that as a translucent number in a corner, but I guess it could equally be opaque. For preference it wouldn't take focus---actually, it would be nice to be able to have some clients not participate in focus---I don't want to type things into gkrellm, for example.)

Preventing some windows from getting the focus is definitely a feature I'd like. -- David Roundy Department of Physics Oregon State University

On Thu, May 31, 2007 at 10:22:22PM +0100, Bruce Stephens wrote:

David Roundy writes:

...

On Thu, May 31, 2007 at 09:37:34PM +0100, Bruce Stephens wrote:

...

Maybe there's a place for a per-screen decoration layer, always visible, in which I can stick clocks, status bars, GNOME panels, etc.? Hmm, maybe just things that just display information (rather than interact)? (And then maybe I could use xcompmgr or something to make them translucent?)

Let's keep the number of layers down, and just allow windows to be present in multiple workspaces.

Ah, but that's tricky for xinerama, as I understand it. Anyway, I was just suggesting one new layer per screen, so that doesn't feel huge. Admittedly, presumably it's conceptually a new kind of layer, which is bad. And maybe it's not worth it.

I've never used Xinerama, so I usually restrict myself to asking how it would best work for the (normal) case of just one screen, and let the people with multiple screens deal with the fallout. Ultimately, it's good for them, too. A clean flexible design is good for everyone.

My hunch is the right way to do this is to have some windows always present on a screen. I'm thinking of that in terms of something like the new floating layers, but maybe there's a cleaner way to do it.

(I should confess to being attracted by the tagging approach of wmii, dwm. That would presumably be a good way to allow windows to be in multiple workspaces. However, I'm not sure whether that's the best way. It feels like it would be a radical change for xmonad.)

Actually, that's basically what I (thought I) was suggesting. It's actually not much of a change for xmonad. Just a few places need to be modified. If I have time and energy for more xmonad hacking, I'm interested in implementing an explicit "tagging" of windows, which would associate zero or more String tags with each window. The simplest use would be to allow the user to execute a given command on more than one window at a time (e.g. to move all tagged windows to a given workspace, or delete them all). I find it tedious having my workspace redraw N times as I move N windows to another workspace. Doubly tedious if those windows are interleaved with the rest, so I have to do some swapping around (mod-tab or mouse) between the mod-shift-n. -- David Roundy Department of Physics Oregon State University

xmonad:

David Roundy writes:

...

On Thu, May 31, 2007 at 09:37:34PM +0100, Bruce Stephens wrote:

[...]

...

...

Maybe there's a place for a per-screen decoration layer, always visible, in which I can stick clocks, status bars, GNOME panels, etc.? Hmm, maybe just things that just display information (rather than interact)? (And then maybe I could use xcompmgr or something to make them translucent?)

Let's keep the number of layers down, and just allow windows to be present in multiple workspaces.

Ah, but that's tricky for xinerama, as I understand it. Anyway, I was just suggesting one new layer per screen, so that doesn't feel huge. Admittedly, presumably it's conceptually a new kind of layer, which is bad. And maybe it's not worth it.

My hunch is the right way to do this is to have some windows always present on a screen. I'm thinking of that in terms of something like the new floating layers, but maybe there's a cleaner way to do it.

I note that by explicitly unmanaging a window, and using float mode to move it into the gap, you can set any client whatsoerver as sticky/ statusbar: , ((modMask .|. shiftMask, xK_u ), withFocused unmanage) -- Don

On Fri, Jun 01, 2007 at 01:13:31PM +1000, Donald Bruce Stewart wrote:

...

Ah, but that's tricky for xinerama, as I understand it. Anyway, I was just suggesting one new layer per screen, so that doesn't feel huge. Admittedly, presumably it's conceptually a new kind of layer, which is bad. And maybe it's not worth it.

My hunch is the right way to do this is to have some windows always present on a screen. I'm thinking of that in terms of something like the new floating layers, but maybe there's a cleaner way to do it.

I note that by explicitly unmanaging a window, and using float mode to move it into the gap, you can set any client whatsoerver as sticky/ statusbar:

, ((modMask .|. shiftMask, xK_u ), withFocused unmanage)

I guess, it seems to me that the gap itself is a horribly ugly hack to work around the inflexibilty and lack of power in the layout algorithms of xmonad. The right way to create the gap (apart from Xinerama) would be to express it as a layout in some sort of a nested workspace, so that you could go into true full-screen mode, or have some layouts that don't include the status bar. I've never wanted a status bar, because I've never felt that my screen was too large in any direction. So I prefer to put information in a corner (e.g. xclock, which is also nicer to read--my eyes don't need to focus on it to tell the time), so that I can use all the width and height of my screen. But, of course, this kind of configuration requires actual window management, and the gap is just precisely a case of giving up on managing windows. Better to have a window manager that is sufficiently powerful to manage all the windows right. -- David Roundy http://www.darcs.net

xmonad:

dons@cse.unsw.edu.au (Donald Bruce Stewart) writes:

[...]

...

In fact, this is really nice! Great work Jason. This is very exciting: it makes some apps (gimp!) a lot more usable.

I agree. Transient frames work nicely. More nicely than with ion3, actually (in ion3 I think there's only one floating layer, so transients were visible in all workspaces which is often irritating).

I agree.

It makes using things like gkrellm possible: I can start it, and then conveniently float it somewhere out of the way. On the other hand, for things like gkrellm, I really *want* that to remain visible when I switch workspaces.

Almost certainly this sets the override-redirect property, and you can thus put it in the status bar gap xmonad allows for.

Maybe there's a place for a per-screen decoration layer, always visible, in which I can stick clocks, status bars, GNOME panels, etc.? Hmm, maybe just things that just display information (rather than interact)? (And then maybe I could use xcompmgr or something to make them translucent?)

clocks, status bars and so on, go in the per-screen `gap', an unmanged region of the screen, on any (or all) borders. xmonad will ignore clients in that area, that have override-redirect set on them. See the status faq, http://xmonad.org/faq.html#status and a recent blog by gimboland, on the topic, http://gimbo.org.uk/blog/2007/05/30/xmonad-does-status-bars-right/

Another (much more trivial) decoration I'd like is the number of the workspace. I guess that could use the per-workspace floating layer. (I imagine that as a translucent number in a corner, but I guess it could equally be opaque. For preference it wouldn't take focus---actually, it would be nice to be able to have some clients not participate in focus---I don't want to type things into gkrellm, for example.)

We plan to dump the internal state of xmonad to stdout, so that you can then post process it with a status bar client. dzen, for example, would happily display the index of the current workspace this way. Expect a patch for this soonish. -- Don

David Glasser wrote:

Excellent. The only downside to doing it this way is that to have different bars on different windows, you'd have to make the output

You shouldn't need to do any fancy multiplexing, or have different status bars on different workspaces. Just send a new line (that has the updated workspace number) to dzen's stdin. ~d

dons@cse.unsw.edu.au (Donald Bruce Stewart) writes: [...]

clocks, status bars and so on, go in the per-screen `gap', an unmanged region of the screen, on any (or all) borders. xmonad will ignore clients in that area, that have override-redirect set on them.

Right, but that feels like losing a chunk of a screen for something that's only occasionally of value. I was thinking of having gkrellm (or something similar) always visible, but perhaps (adjustably) translucent, in which case it could just overlay normal windows. Hence the idea of something like a floating layer. Now I think of it, I think I was talking past David Roundy. I think he's talking about windows he wants to be in multiple workspaces in the sense that they participate in the workspace layouts. In this case, at least, I *don't* want the windows to affect layout (which is why I was thinking in terms of the floating stuff). However, quite possibly it's not worth the complexity. I'm sure a one line status bar with dzen will be sufficient. Or even a GNOME (or KDE) panel, I guess, since those can also hide themselves (so wouldn't need much permanent space---just few pixels). [...]

Another couple of ideas for the float layer: mod1-button2 should raise a window that's not at the top, but lower to the very bottom one that's already on top. Otherwise it can be hard to find obscured windows. But once this behavior is configurable, of course, this change will be less critical. When dragging a window, I'd rather it was displayed is it'll be when I release it. Currently the window is raised to the top while being dragged, but then released at the current stacking level, with the result that you can easily "lose" the window you're dragging, if you drop it under a larger window. This change wouldn't prevent that loss, but would make it obvious, since the window would be hidden when you drag it under the larger one. Another solution would be to always raise windows when moving them. -- David Roundy Department of Physics Oregon State University

jcreigh:

On Thu, May 31, 2007 at 12:35:04PM -0700, David Roundy wrote:

...

Another couple of ideas for the float layer:

mod1-button2 should raise a window that's not at the top, but lower to the very bottom one that's already on top. Otherwise it can be hard to find obscured windows. But once this behavior is configurable, of course, this change will be less critical.

I don't know about this. But yes, I agree that mouse bindings should be configurable.

Agreed.

...

When dragging a window, I'd rather it was displayed is it'll be when I release it. Currently the window is raised to the top while being dragged, but then released at the current stacking level, with the result that you can easily "lose" the window you're dragging, if you drop it under a larger window. This change wouldn't prevent that loss, but would make it obvious, since the window would be hidden when you drag it under the larger one. Another solution would be to always raise windows when moving them.

I'm thinking that we should just always raise windows to the top of the floating layer when moving or resizing them. Anyone have any other thoughts on this issue?

I think it should be raised, yes. BTW, Using the 'master' to indicate this is a bit icky , imo, but that's another issue to do with implicit floating layers, or explicit/detached layers. -- Don

droundy:

On Wed, May 30, 2007 at 10:53:54PM -0600, Jason Creighton wrote:

...

Wed May 30 22:47:33 MDT 2007 Jason Creighton * first shot at a floating layer

This is a first attempting at a floating layer:

mod-button1: move window mod-button2: swapMaster mod-button3: resize window

mod-t: make floating window tiled again

Moving or resizing a window automatically makes it floating.

Known issues:

Hard to manage stacking order. You can promote a window to move it to the top, (which you can do with mod-button2) but it should be easier than that.

Indeed, this is ugly, but I think the fix is easy, we just need to use the old version of swapMaster (I don't recall its name) that moves the given window to the top of the stack. Then the floating layer will behave like a normal window manager in this regard: raising a window leaves the other windows in the same stacking order.

yes, i think we actually have to handle the floating layer in its own stack, so that it can be ordered and shuffled like a normal overlapping wm.

I hope you're thinking that once this is cleaner we can move the button configuration out of Main and into Config? That'll make it both easier to configure and easier to find. And the refactor which'll be needed should also help with other features like adding tabs, either to float windows or to a tiled workspace with tabbed layout.

will happen soon, jason's working on it.

I'm with dons on the question of reorganization, a bit flag to indicate the float layer is just ugly. And I still hope someday to be able to refactor the float layer out of xmonad entirely and into XMonadContrib. We may not want this refactor to actually happen, but I think the code should be structured such that it can be done--it'll make for cleaner code and a more powerful interface.

agreed. the floating-ness at least has to move away from being interleaved with tiled windows -- that just doesn't let fullscreen tiling work very well with floating windows, since focus gets permuted strangely. -- Don