koekeishiya / yabai

A tiling window manager for macOS based on binary space partitioning
MIT License
23.45k stars 644 forks source link

Feature Request: resize stacked windows with padding for title bar #2045

Open diocletiann opened 9 months ago

diocletiann commented 9 months ago

Something like this would be really useful to know when you're working with a stack:

image
koekeishiya commented 9 months ago

Sounds reasonable. Could add a config option "cascade_window_stack".

Should the focused window be moved to the front of the stack when this option is enabled? That way the titlebar of all other windows in the stack will always stay visible. If not, only windows "further up the stack" will be visible as the active window changes.

diocletiann commented 9 months ago

Yea that makes sense to me. Thanks!

ognistik commented 8 months ago

Stackline—which I used to identify Yabai stacks—seems to be no longer in development and it gives lots of errors on Hammerspoon, so I hope something like this is implemented within Yabai itself 🤞️

aspauldingcode commented 7 months ago

The way this appears to work on sway and i3 is the titlebar is drawn seperately. Since all applications on linux with i3 or sway are forced to use server-side-decorations for things like the titlebar, it is drawn with an efficient and simple bar, to identify if it is stacked or tiled. I really like the idea here, and I wonder if it's possible in macOS.

But, if you think about how yabai stacks windows, it literally stacks them. In sway/i3, windows will never really be stacked. Just the "titlebar" while the windows which are not shown, contents will not even be drawn.

In yabai, the best way to probably do so is figure out how to spawn a titlebar arbitrarily, and allow the titlebar to have a min hight contents of 0, so there will be no window with the bar - Then renaming this titlebar with the name of the application.

i3/sway do not show application icon. So this should be easier. with yabai, this means we could spawn alias titlebars maybe as a subprocess under the yabai application process, which would allow us to stack them like shown in stacked mode with i3/sway, or even tile them width wise for a potential new "tabbed" mode in yabai. This would be a lot easier if the titlebar was not the original application titlebar. Meaning, it would work for all applications, not just ones with a configurable titlebar such as alacritty.

tiled vs stacked vs tabbed i3/sway example

koekeishiya commented 7 months ago

On macOS the application itself is responsible for drawing window decorations, not the window server. This is a technical difference between Linux and macOS.

aspauldingcode commented 7 months ago

I know that there is large difference there in macOS. and I am aware of the many limitations in macOS. I don’t even know if spawning alias titlebara would work. But I think it would be easier visually if using a mouse. i really like the implementation idea @diocletiann came up with. i guess what my concern is, using the window titles of the application in apps other than alacritty, which do not use this classic titlebar height, or even no titlebar.

diocletiann commented 7 months ago

I thought about emulating the i3 tab bar in SketchyBar but lost steam. A cascaded view like this doesn't waste much space and would be big improvement imo. @koekeishiya I'm not sure you'd even need to swap the window locations, it actually may be more disorienting if the window you're about to focus suddenly shifts.

koekeishiya commented 6 months ago

The main motivation here is to have some sort of visual indicator of how many windows are in a given stack, and which entry is currently focused right?

ognistik commented 6 months ago

The main motivation here is to have some sort of visual indicator of how many windows are in a given stack, and which entry is currently focused right?

I do think this is the main point of this thread.

koekeishiya commented 6 months ago

Would something like this be too intrusive? (color and opacity can be customized at user level).

stack1 stack2 stack3 stack4
dominiklohmann commented 6 months ago

I think there are too many applications that utilize this space to render helpful information. What do you think about rendering the indicator in the gap above the window, if a gap is configured, or at least allowing a vertical offset to be configured to achieve this effect?

diocletiann commented 6 months ago

Adding a top gap on a stacked window and using that space for indicators sounds promising.

koekeishiya commented 6 months ago

I thought about having a top margin for this behavior. So the node has frame 10, 10, 500, 500. With a top margin of say 40, the actual frame applied to the window would be 10, 50, 500, 460. The indicator would then be rendered inside that margin.

At first it seems like it would cause a lot of dead space, but maybe that isn't all that important and it will be fine. I'm also not sure if it is better at the top, or at the side (left? right? towards the edge of the screen, but how does that work when it is enclosed by another window from all sides?) etc.

ognistik commented 6 months ago

Honestly, I think the way that Stackline was doing it was perfect. It even had this "minimal" mode that was not obtrusive at all.

90966912-1dd15080-e48d-11ea-9890-3e10ea7ce397
koekeishiya commented 6 months ago

So the "issue" I have when briefly looking at stackline screenshots is that it doesn't showcase a wide variety of situations. How does it look and operate under more complex layouts; what if the user does not have any padding or gaps enabled, and the layout is as follows:

Node A and E are single windows. Node B, C, and D have multiple windows (stacks).

+-----------------+
|     |  B  |     |
|     | (s) |     |
|     |-----|     |
|  A  |  C  |  E  |
|     | (s) |     |
|     |-----|     |
|     |  D  |     |
|     | (s) |     |
+-----------------+

It looks good in the provided screenshots, but I need to extrapolate that to always look good enough, and not just look good in specific scenarios.

diocletiann commented 6 months ago

I didn't like the stackline approach, it wastes more space than a top gap. I used to change the border color on a stacked window which worked well and didn't waste space. I think a thin top gap with some indicators would be good and match i3 and other TWMs.

koekeishiya commented 6 months ago

If people are interested in some brainstorming, please do some simple "programmer art" images/ascii art showing how you imagine it would work in a way that you are satisfied with / wastes the least amount of space. It is more helpful if you try to include a wide variety of scenario in your design, such as optionally configured padding or gap.

What I'm interested in at this point is a design that could work well. The implementation specifics for how to achieve that solution doesn't really matter yet.

aspauldingcode commented 6 months ago

Well, for example, I would love to have ability to customize with 1:1 look-alike with swaywm/i3wm defaults. Maybe it could be an option between: bars dots dots-inline dots-left native

in which the native option would render an alias title-bar which could just add a window titlebar above, renamed to the same important info in regular windows, and the bars option would clone the sway/i3 titlebars, and the dots inline would be in the titlebar, the dots left would be left, dots would be above etc

aspauldingcode commented 5 months ago

Something like this would be really useful to know when you're working with a stack:

image

I’m still feeling this approach.. feels closest to macOS. Might even be possible to implement ourselves, using the yabai layer feature to reorder a window’s layer. but, I think this is still the best way.

gldtn commented 2 weeks ago

Has something like this been implemented? Couldn't find it in the wiki.