
Hi there! I would like to discuss some ideas which I have been tossing around regarding the floating layer. In Bluetile I discourage the use of the floating layer and hope that people use the stacking layout instead, because I feel that the floating layer is fairly confusing to novice users. It feels pretty alien and managing windows that are currently floating is somewhat cumbersome (like how to bring one floating window in front of another). But unfortunately I can't get by completely without it in Bluetile, because things like dialog windows need to float even in a tiled layout. So I'm thinking about how the floating layer can be improved. Looking at the implementation, I feel that the floating layer is a little bit 'bolted on'. So my proposal: how about changing the core so that it allows to specify a _layout_ for managing floating windows? At the same time, floating windows could be integrated properly into the StackSet data structure. Each workspace should have two stacks associated with them: one that contains the windows in the tiled layer and the other stack contains the windows in the floating layer. Obviously few of the current layouts make sense for managing a floating layer. X.L.PositionStoreFloat might be a possible choice, but one would probably write a standard one based on what Xmonad core is currently doing in regards to floating windows. Having floating windows managed by a layout would remove their 'special status' and would allow for more customization: For example the possibility of adding decorations to floating windows as well. Thoughts on this? Best regards, Jan

"Jan Vornberger"
So I'm thinking about how the floating layer can be improved. Looking at the implementation, I feel that the floating layer is a little bit 'bolted on'. So my proposal: how about changing the core so that it allows to specify a _layout_ for managing floating windows? At the same time, floating windows could be integrated properly into the StackSet data structure. Each workspace should have two stacks associated with them: one that contains the windows in the tiled layer and the other stack contains the windows in the floating layer.
I believe having two stacks has been the plan for a while; it's just that it hasn't yet annoyed anyone enough to make them bother to implement it ;-) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

ivan.miljenovic:
"Jan Vornberger"
writes: So I'm thinking about how the floating layer can be improved. Looking at the implementation, I feel that the floating layer is a little bit 'bolted on'. So my proposal: how about changing the core so that it allows to specify a _layout_ for managing floating windows? At the same time, floating windows could be integrated properly into the StackSet data structure. Each workspace should have two stacks associated with them: one that contains the windows in the tiled layer and the other stack contains the windows in the floating layer.
I believe having two stacks has been the plan for a while; it's just that it hasn't yet annoyed anyone enough to make them bother to implement it ;-)
Actually, I did implement it, in 2007, and the two-level data structure was rather horribly more complicated. -- Don

"Jan Vornberger" writes:
Having floating windows managed by a layout would remove their 'special status' and would allow for more customization: For example the possibility of adding decorations to floating windows as well.
Yes, this seems like the way to do it. I'd started trying to do something like this in my spare time, but tend not to have enough spare time to finish it!

Jan.Vornberger:
Hi there!
I would like to discuss some ideas which I have been tossing around regarding the floating layer.
In Bluetile I discourage the use of the floating layer and hope that people use the stacking layout instead, because I feel that the floating layer is fairly confusing to novice users. It feels pretty alien and managing windows that are currently floating is somewhat cumbersome (like how to bring one floating window in front of another).
But unfortunately I can't get by completely without it in Bluetile, because things like dialog windows need to float even in a tiled layout.
So I'm thinking about how the floating layer can be improved. Looking at the implementation, I feel that the floating layer is a little bit 'bolted on'. So my proposal: how about changing the core so that it allows to specify a _layout_ for managing floating windows? At the same time, floating windows could be integrated properly into the StackSet data structure. Each workspace should have two stacks associated with them: one that contains the windows in the tiled layer and the other stack contains the windows in the floating layer.
I think it should be possible to have an elegant 2-level StackSet , with sensible navigation between the two layers. However, the logic for managing the boundary cases where focus switches from the first to the second layer is significantly more complicated than the current very clean code. -- Don

On Fri, Aug 13, 2010 at 09:58:01AM -0700, Don Stewart wrote:
Jan.Vornberger:
Hi there!
I would like to discuss some ideas which I have been tossing around regarding the floating layer.
In Bluetile I discourage the use of the floating layer and hope that people use the stacking layout instead, because I feel that the floating layer is fairly confusing to novice users. It feels pretty alien and managing windows that are currently floating is somewhat cumbersome (like how to bring one floating window in front of another).
But unfortunately I can't get by completely without it in Bluetile, because things like dialog windows need to float even in a tiled layout.
So I'm thinking about how the floating layer can be improved. Looking at the implementation, I feel that the floating layer is a little bit 'bolted on'. So my proposal: how about changing the core so that it allows to specify a _layout_ for managing floating windows? At the same time, floating windows could be integrated properly into the StackSet data structure. Each workspace should have two stacks associated with them: one that contains the windows in the tiled layer and the other stack contains the windows in the floating layer.
I think it should be possible to have an elegant 2-level StackSet , with sensible navigation between the two layers. However, the logic for managing the boundary cases where focus switches from the first to the second layer is significantly more complicated than the current very clean code.
-- Don
I don't know if 2-level is really what we want. If anybody is willing to put effort into this, it might be wiser to make this more generic. If we take a look back at the famous "Issue 4", we have another reason to fix this floating thing. But Issue 4 is not only related to floating windows, I also have that problem with my gimp layout (2 nested IMs for toolbars with Tabbed for Images), where moving the mouse out of the image-window to the toolbar-window changes focus in the nested tabbed layout, which is awfully annoying and makes those toolbars nearly unusable. (It can be worked around by moving windows in the layer with swapUp/swapDown, though.)
participants (5)
-
Don Stewart
-
Ivan Lazar Miljenovic
-
Jan Vornberger
-
Justin Bogner
-
Tobias Hommel