Cursor warp and focus options not respected

[Acumane]

I'm trying to use windowrule = move onscreen cursor -50% -50%, <window>, but the window always spawns centered above the tiled window beneath because my mouse warps there. This is especially strange since my follow_mouse is set to 0.

This also means that cursor:persistent_warps is broken (focusing a window always warps the cursor to the center).

Can confirm this works as expected if I set general:layout = master

[dawsers]

I read the Wiki to try to understand what that does, and it says it applies to floating windows. Does it mean it is a rule applied when you turn a window floating? You will need to explain to me what it does and give me an example. I am not able to create one, I don't know what to expect.

As for pesistent_wraps, yes, it is probably broken. It is a "new" option, so I probably haven't implemented it.

[dawsers]

I have added support for cursor:persistent_warps. Let me know if you see any weirdness.

[Acumane]

Everything works perfectly now. This also nearly solves another issue where bindm = SUPER, mouse:272, movewindow retiles on release. Now, SUPER + left mouse floats a window permanently, but drag focus is lost (used to not be)

[dawsers]

Sorry, I don't use the mouse for window management, and use floating windows very rarely. So it would be very helpful if you told me exactly what doesn't work and how to reproduce it...as if I had no idea about using Hyprland...which I basically don't, because I always have the plugin on :-)

Please, tell me what you want me to test, what happens when hyprscroller is the working layout, and what you'd expect to happen (or what the standard layouts do in that case).

Thanks.

[dawsers]

OK, the window dragging issue seems to be related to the changes I made in #113

I will try to find a way to fix both things at the same time. There are lots of edge cases.

[dawsers]

Window dragging should be fixed in e590a24

Please, let me know about the other issues.

[Acumane]

Yeah, after e590a24, this behaves more like master (below):

In both tiling layouts, when a window is released above another, they switch places and assume the other's size. This wouldn't be ideal for hyprscroller.

For starters, they should at least preserve their size after dragging:

[dawsers]

That is not possible without "memory". When you drag a window, it is removed from the layout, and when dropped back, it is re-inserted again. If there is no memory of removed windows, the window has to be treated as new, so the size will be a default size. That is also what happens with Master or Dwindle, you drop the window on a certain "slot", and its size simply has to take the size assigned to the "slot".

A layout shouldn't keep a "memory" of old windows. It can be done, but it is dangerous.

[Acumane]

Unfortunate, I know floating windows recall their size.

Here's what I'm thinking... on release of a dragged window d:
⠀ (1) if cursor is above a row or col that d does not belong to, insert
⠀ (2) else d swaps places with t, the target window below the cursor

Ideally, the method for determining where a window gets inserted would split the target window into zones, e.g. if your cursor is in the bottom half of window t in a col on release, then d gets inserted below t. Use left/right zones when t belongs to a row.

Up to you whether this placement method is also used in case (2) for consistency.

[dawsers]

Hyprland stores the size of floating windows in the Window structure, because they belong to Hyprland instead of the layout. But it doesn't store any information that belongs to the layout alone.

What you propose doesn't solve thee issue of size. The new window will always have the default size of inserted windows. When you drag:

1. The window gets removed from the layout It no longer belongs to hyprscroller
2. Focus follows the mouse, so the active window in hyprscroller changes
3. You drop the window, it will be inserted as new where the active window is, and in the mode you currently are,
4. If you are in row mode, it will take the default size of row mode columns. If you are in column mode, it will take the width of the column you insert it into, and the default height of column mode windows.

If you want to move windows, there are plenty of options what keep size without using the mouse. you can:

• Use the move dispatcher
• Use the scroller:selectionmove dispatcher
• Use trails and trailtoselection

There are plenty of ways to move things around without having to keep memory of "old" windows. Those diapatchers work because the windows they move never leave hyprscroller.

I mean I can hack something for this particular case to work (most of the time), but then someone would complain they also want to override the mode (insert the dragged window in a column even if they are in row mode), then they would want this hack to work for floating windows that "come back" etc. Once I open the door to "memory" it won't end.

The way it works right now, is exactly like Master or Dwindle do.

[Acumane]

What you propose doesn't solve thee issue of size

I understand, I can live with that

Once I open the door to "memory" it won't end.

Relatable

The way it works right now, is exactly like Master or Dwindle do.

Not exactly, windows don't swap consistently:

[dawsers]

That is how it should work.

1. You drag the lower window. It is removed from the layout
2. The top window is the new active window
3. You drop the window, it gets inserted below the active window by default. You can change this with setmodemodifier

[Acumane]

I saw what you did with setmodemodifier. Cool stuff, but this is not "exactly like Master or Dwindle." I will see what I can do with scripts

[dawsers]

It is the same. The difference is what they consider the point of insertion of the new window. There has to be one, and it is arbitrarily decided by the layout. Dwindle uses nodes in a tree, so the focus changes to a point in the subtree. When you drop the window, it inserts it as if you created a new one with that subtree node focused. hyprscroller does the same; it is just our insertion position is after instead of varying depending on where the window is. What you want is to modify that, and have an insertion position that is variable: before in the example above. But how would you then be able to insert the window after if that is what you wanted? You want an insertion point that depends on things other than the active window, the number of windows etc. You want something that depends on mouse position, doesn't depend on the current mode etc. It is not as simple. There would need to be a specification that covers all edge cases. Right now, it is completely predictable, and follows the rules of inserting windows. I think it would even support setmodemodifier and window rules. If you changed that, you would also need to override those.

[Acumane]

LOL I was messing with list.h and yeah I can't be bothered. Should've read what you said... thanks for explaining.

[dawsers]

No problem.

Is there anything else to fix for this issue to be closed?

[Acumane]

Given the constraints, lgtm