Several bugs on 0.38.0

[aacebedo]

Tested the last commit on 0.38.0 (thanks for the hard work BTW) I saw some bugs breaking my workflow:

• resizewindow dispatcher not working anymore
• toggleoverview (which is a great idea) segfault
• multi-monitor setup seems broken (move focus and move window all over the place and behaviour unpredictable)

[dawsers]

I am running v0.38.0 and I can reproduce resizewindow not working horizontally after one of the latest changes, but focusing, window movement, overview and multi-monitor work well here. Please, attach a (small) config file where I can reproduce the problems. It could be a combination of the geometry of your setup that is different than mine.

[aacebedo]

I noticed that resizing horizontally works only if you resize the window vertically first. I retried toggleoverview and didn't segfault this time. Multimonitor is actually working but I see a Z-depth bug, with the windows from the workspace of monitor 1 displayed a few seconds above the window of the other monitor when moving the focus. It is like part of the workspace of monitors overlaps

[aacebedo]

Additional things I noted:

• windows do not fit columns height automatically leading to holes. It would be interesting to have an automatic fill mode
• first window does not fill the entire screen
• windows does not automatically realign to left of screen when left-most window is closed (leading to a gap)

[dawsers]

I am working to fix horizontal resizing.

I have seen the z-depth problem when testing v0.38, but it doesn't happen in v0.35. So it's either a bug in Hyprland (?), or something has changed that I am not aware of. There are new things happening there everyday, and little documentation. I will have a look.

Windows have to apply the gaps configuration. If you have set gaps_out and gaps_in, the holes are caused by that. A "top" window will always have a gaps_out between the top and the bottom of the bar, and the same goes for a bottom window. Windows in-between have a gaps_in gap between them. If you would like windows to fill all the space, set gaps to zero.

The first window you create is like any other window, it uses the OneHalf width and is positioned at the center of the screen. I find this better than using all the available space, as most windows don't need it.

What you see about left alignment is the same as the top alignment, and again caused by the gaps configuration. Set gaps to zero and columns will align exactly to the left edge.

[aacebedo]

Noted for z depth I saw you fixed resize, l will try it. I am mot sure about the gaps because it is set to 5 and I have huge gaps (the size of the closed window) I understand the one half width but would it be possible to add a config option of the layout to change this behaviour?

[dawsers]

If what you see (as "gap") is the size of a window, it is because column reordering is lazy. This means a column will not move if it is already inside the viewport. For example, if you have two visible windows and close one, the other will stay where it is. If you move a window, it will stay where it is and the others will move. That was intentional to be able to keep the eyes focused on the window that was being manipulated. I tested several other strategies where I would try to fit more windows inside the viewport, and /or center the active one after an event. Those had some trouble, like for example moving windows I wanted to see just because the active one was located in an "optimal" way by the strategy. Maybe I could re-add some of that code and create an option for people to choose whatever they prefer. But the current behavior is predictable and explained in the README.

I can add an option to choose the size of a new window between: OneThird, OneHalf, TwoThirds, Maximized or LastFloating (default size of a window returned by the app), but that would affect all new windows, not just the first one you open. Is that what you want, or you just want the option to change behavior of the first one you open? I'd be happier to be consistent here.

[dawsers]

I have been thinking about the configuration option for initial column width. To me, it doesn't make sense to make a difference between the first column and the rest. For example, when you suggest the first window (column) should fill the entire screen (as it does in other layouts), what do you expect to happen when you open a new one? Will it also fill the entire screen, leaving the previous one outside? Will if adopt a different size, thus having the first one being maximum size and the following ones a different size? Or do you expect the first one to magically adopt another size after new columns are added? That is what I meant about consistency. I can add an option to modify every new column's width. People will be able to choose, and the default will be the current one (OneHalf). But making a difference between the first one and the rest is inherent in other layouts that make all windows fit the viewport at all times, but here it doesn't make sense to enforce different behavior and auto-resize columns because of the order in which they were created. If somebody wants a column to fit the screen, but only when it is the only one in the row, it is just a keypress away, calling fullscreen 1. If they want several columns to fit the viewport, it is another key press away, by calling fitwidth. After all, this is a scrolling layout, for auto-tiling there is master and dwindle.

[dawsers]

I added a configuration option to modify the default column size when creating a new window column_default_width.

I also changed the re-ordering or columns to be more intuitive instead of lazy. It will always fit the active window on the viewport, and the previously focused one if it fits, and if it doesn't, the one on the other side of the active one. If none of them fit, it will try to show as much of them as possible by moving the active to either monitor edge. Note that there are cases where if one of them fits, it won't try to fit the other one, so the active one is not moved. This is so "aligned" columns don't de-align unless focus moves to another column.

[aacebedo]

Thanks ! I starde using it and it seems very nice. I also started to use the toggleoverview which is very useful.

I noticed the fitwidth visible behave lie the fitwidth all even if I use the alignwindow l to just display a subset of the window.

Also noticed that resizing windows in overview does not impact window size when leaving overview mode. Could be interesting to impact the size ratio change made in this mode.

[dawsers]

There was definitely a bug in the selection boundary of visible windows for fitwidth, and it only showed when you align windows to the edge of the monitor. It should be fixed now.

Hoever, fitwidth visible chooses all the windows that are visible or partially visible and re-scales them. But I checked the ones that are completely outside of the viewport are ignored, for those you have all, tobeg, toend.

I consider overview a special mode. The less you do there, the better. When you enter overview mode, window sizes are saved so you can return to the same configuration when you exit that mode. If I allowed to resize windows there, what would the configuration at return time be? So I think overview is suited for navigation, maybe window reordering and little else. The problem is Hyprland doesn't provide a way to limit the functionality of what you can do there, because it is just the same layout, but scaled.

I believe fitwidth or resize is how resizing should happen.

I am not happy with overview. It is useful but prone to bugs and misunderstandings. If due to windows sizes and number, one is too small, overview will crash the plugin...and the compositor. But I don't want to remove it because it can be very useful. I am investigating how to make it less functional, maybe something like hyprexpo.

[aacebedo]

Ok noted for the overview mode. I'll try hyprexpo when 0.39 will be released as it is not compatible with 0.38.0

By the way cyclesize seems broken too.

[dawsers]

When is cyclesize broken?

[aacebedo]

When is cyclesize broken?

forget what I said, misconfiguration on my side

[dawsers]

I think these bugs were fixed. I have committed the new column rework, so there are quite a few changes. Time for new bugs.

[Acumane]

Reproing z-depth issue, 0.39.1

[dawsers]

Yes, I am aware there were changes in Hyprland after 0.35 that make "damaging" of monitors more precise. It has nothing to do with the plugin itself. For example, if you use 0.35, that doesn't happen, and the code is basically the same. The reason why this is happening is Hyprland doesn't support the concept of layouts that span more than the viewport, so when the compositor has to "damage" a region, it never considers there may be windows outside of the coordinates of the monitor. That causes the windows that were outside to stay there for a fraction of a second until recalcuateMonitor gets called again by the compositor.

I opened an issue in Hyprland to track this behavior, not just for the Z issue, but also for more general things like focusing, overview mode rendering etc. 5489. I offered myself to maybe work on it, but after looking at the code, I realized I would basically need to rearchitect the compositor. A simple fix there to the Z issue would make the rest of the layouts less optimized, and nobody wants that, as hyprscroller is a very niche layout plugin.