[Feature] Un-intuitive aspects on first use

[clotodex]

Just installed this amazing plugin and used for the first time - read the readme and watched videos - have not used paperwm before.
Quite overwhelmed, so I stuck to just to my config with this new layout, relying on mouse to get going with it.

What do you think about these things I noticed?

1. drag and drop a window in overview mode, does not "create" a column (probably blocked by Drag/drop onto col #12 )
2. Clicking on a window in overview mode, I would expect it to focus and then close overview mode
3. A column needs to contain the focused window to be able to be scrolled. I thought the gestures were broken until i figured this out (example: working in ide, multiple terminals in a column providing output - but not being focused)
4. [potential bug?] my mouse movement is a lot slower in overview mode (probably because of zoom-out) but that feels really weird
5. toggling column, row mode easily (discussed in Provide a "togglemode" dispatcher #114); I read through the issue and understand the reasoning - nevertheless this is very unintuitive and led me to search for this again
6. I would find it more intuitive to move a window "through" a column. Let me explain:

• when moving a window left or right, it "swaps" the place with the column net to it.
• what i would love to do is move the window, first INTO the column (if there is no column yet, create it), and when i keep moving it, move out of the column again

As next actions I can imagine:

• creating dedicated issues if the ideas or concerns are valid
• thinking about readme improvements (maybe a dedicated minimal setup)
• leave this issues as a pointer for new users or editing this issue into whatever feedback I get :D

What do you think?

[clotodex]

Acutally regarding 1. I DONT think this is blocked. If I switch to column mode, i can drag it onto that column.
So the issue I have with it:

• I would like it to act independent of current mode
• join in the column if i drop the window "above or below"
• join in the row if i drop the window "next to it"

[dawsers]

Thanks for taking the time to do this review. It is always useful to get feedback from first time users.

I will try to comment your concerns one by one...

1. As you point out in your second message, it does work as if you were not in overview mode. I cannot really make it work differently without a lot of work and intuition about what the user wants to do at any time. It follows the rules: there are two modes, and depending on the mode, it does things differently, but predictably. If I didn't respect those modes, then we would be talking about a different plugin. You are probably looking for a different layout; one that is less rigid in terms of window positioning. But you will find all of them have rules. For example, what you suggest may work with master or dwindle, but only because you are also following their rules, and accepting they work in a rectangular grid with limits the current viewport. For example, when using them you instead wouldn't be able to "add another column". What I mean is, sometimes intuition comes falsely from being used to certain behavior, but in reality those other layouts are not "flexible" either, they follow their own rules. For a better explanation of how hyprscroller works with dragging and dropping, see this discussion. It is a bit long, but it contains most of the information.
2. Overview mode is like normal mode, just zoomed out. You could even work in that mode. So if I do things differently, like closing it when you click, it wouldn't work the same way. Maybe you should use jump for quickly focusing other windows instead of overview. It is a lot faster when using the keyboard. In reality, hyprscroller is very focused on keyboard usage. I rarely use the mouse, that is the reason why. But you can add a submap that toggles overview and limits what you can do, for example closing it if you click.
3. hyprscroller is not a grid layout (also related to point 1). Windows belong to columns, and columns belong to rows. When you scroll, you scroll a row, moving from one column to the next. If you try to scroll up or down, it will check whether your current column has more than one window, and then it will scroll. That is the difference between a grid layout (which would support what you mention, and also point 1), and hyprscroller. You basically need a completely redesigned plugin to make those things work as you expect.
4. Yes, you are right. When zooming out, the mouse pointer and coordinates are also zoomed out. You are moving in a virtual monitor that is much bigger than the viewport. Hyprland doesn't support layouts that extend beyond the viewport, so I have to hacks into Hyprland functions to make this work. There are several dicussions that explain this, in case you are interested. I am trying to change this and make hyprscroller more robust in overview/jump mode, but it is not an easy task. In the meantime, windows and cursor are scaled (their coordinate spaces need to be mapped to the viewport to be able to see them).
5. Explicitly having the set the mode is done on purpose, The number of keystrokes is the same: one. And, unless you have a bar module that tells you which mode you are in, you may lose track of it. So it is always easier to simply press the mode key when you have forgotten, than opening a window and then moving it if you were in the wrong mode. However, you can add that toggle through a simple script, like it is mentioned in Provide a "togglemode" dispatcher #114 (it also includes the script you can use thanks to @chaorace)
6. Again, you are expecting a grid-type layout where there are no modes, which hyprscroller is not. I could write one, but it would be fundamentally different to what hyprscroller is now.

I think you have maybe misunderstood what this plugin does. It is not an extensible grid layout. That would be very interesting, but it also brings usability problems. Unfortunately, hyprscroller will have to continue being rigid, because I cannot change its working rules depending on the situation, being predictable is better in my opinion.

Maybe in the future, if someone writes a good spec for it, there could be an extensible grid layout like the one you seem to prefer, but hyprscroller's architecture doesn't allow it as it is now.

[clotodex]

Thanks a LOT for your feedback - the plugin is amazing and I am already daily driving it.

To your points:

1. ✔ very well said, I agree and am not lacking this feature anymore since i got more used of how to "move around" and "organize" without using the mouse - I still think there could be a more intuitive "main-stream" way, but agree that this might lead to a completely different experience altogether (which would rather be a fork of this)
2. ✔ agreed - could be a tutorial point if more people would want this - not using it anymore myself though (fully switched to keybind-jump). If I focus on mouse though to open it instead of a keymap - since it is gesture based I cannot launch a submap (i think)
3. i understand your point, what i actually meant is something also configurable in hyperland - being able to scroll in a window without focusing it - i would love to "scroll" a column without "focusing" it (based on cursor position)
4. ✔ got it
5. ✔ i think pointing to the issues or scripts or similar is enough - but should happen in the readme or tutorial (see below)
6. I am not expecting a grid layout, however I find moving a window through the current state of the scroller more intuitive than expelling, moving columns and readmitting (plus the ergonomics of this is hard) - but more below (8)

Learning how to use it, i am updating my experience:

7. moving windows - size changes

• admit/expel changing window size is weird - i expect the window to "move" not to relayout
• same goes for moving a window any other way which makes me believe this is a limitation or by design (could be a great config flag though)

8. moving windows - ergonimics

• now that i understand that everything is actually an operation on rows and columns, it feels really weird to NOT be able to move a window individually and directionally OUT of a column (need to use expel OR mouse grab OR i am missing something)
• i understand both ways of moving (columns and windows) is something i want - but windowlevel is way more important to me than column level (this could be a config option OR another dispatcher)

9. mouse gesture configurable to use jump not overview

• i agree jumpmode is what i want - not overview - but for mouse gestures this is not configurable afaik (going into jump instead of overview)

10. window center align does not always behave as expected

• centering does not work for me if there is a window open to the right of the column i want to center (alignwindow) - this might be a bug or i have not yet figured out the reason why

11. popups

• i do NOT understand yet how popups are managed - especially with a google meet "popout" i have extreme troubles getting it under control (in normal hyprland it is a popup, in hyprscroller it is not, i want it to be one, but dont actually know what a popup MEANS in the context of the virtual monitor - if it should be pinned to the viewport etc)

12. more tutorials or readme

• the shortcut-heavyness was not something i expected going into this project - but it does very much shine with fitsize, cyclesize etc (thinking if there could be a tutorial for guiding how to start using it - e.g. "try out", "beginner", "everyday" and "advanced" - could be simply different example configs)
• I used all scripts from How to know whether I am in row/column mode #57 (waybar AND toggle) for my setup - I find the toggleable experience way more intuitive - additionally I actually included the cyclesize and fit options into my main resize submap - mod+r -> arrows resize manually, space cycles widths, shift+space heights, t(his), a(ll),b(eginning),e(nd) and so on - this makes it overall 80% powerful out of the box i think

13. fitsize and distribute space

• fitsize is amazing and immediately one of my favorite shortcuts that feels like a superpower
• however i would love to sometimes make all visible windows in the split same width (height) - when my windows are differently sized and i fitsize the windows scale based on their previous size (this makes sense and should be default). I would love an option like "distribute widths" or "equalize widths" that can be run right after a fitsize. Does this already exist somehow? Searching in the issues did not yield any results

[dawsers]

Thank you again for all your comments. I will try to address the new points
you mention:

3. I understand you are talking about Hyprland's input:follow_mouse = 2 or 3, where mouse focus is detached from keyboard focus. You would want to be able to scroll non active columns while keeping focus. That would only work when input:follow_mouse is 2 or 3 (otherwise focus would follow the mouse), and the active window in the active column would never leave the viewport. Hyprland's input:follow_mouse is 1 by default, so this would not work in that case. Let me know if that is what you want and I will try to think of a way to make it happen.

...

6. When you move a window/column, it keeps its properties. Instead, if you admit it into another column, it loses some of them, and takes on the new parent's ones (like width). This is needed because you cannot have a column layout where each window has different widths, it would make the layout a mess with holes all over the place. When that window is expelled, it will keep the latest width (that of its latest parent). So what you mention about moving "through" a column has the problem that your window would lose its width, and when moving out again, it would be different. I wouldn't know if you are simply "moving across", or you admitted that window willingly; it has to work the same way. That is why move and admit are different, because they have different intentions.

7. Explained in 6. Also, moving windows doesn't change any of their properties unless they are "admitted" into a new parent, as explained above. Again, this goes back to the grid vs. row/column/window layout discussion. A window has a parent, column, which has a parent, row. And they inherit certain properties from the parent, mainly geometry, so the layout is manageable.

8. Moving a window out of a column makes it leave its parent, so it needs expel. Using the mouse is simply expelling it too. How would you propose to do this within the window/column/row layout hyprscroller is? If you want windows to be independent entities, that is not this layout, but there is a reason. It would be very hard to create a compact layout where you can place windows wherever you want and they can all have any size you want but are still tiled. It would be full of holes (wasted space). The best way to do this is a traditional, non-tiled layout where windows can overlap. This way you can have any size at any position without holes.

9. After reading your comment, I have just realized jump allows for refocusing without using the keyboard, by simply clicking. I thought I had disabled mouse gestures in jump mode. However, currently you cannot use the mouse to exit jump mode. I can add a click mode to focus and exit. Then you could use a regular binding to call jump with a mouse button (I use this for overview):

bind = ,mouse:275, scroller:jump

Don't do this now, because if you start calling jump mode recursively, the plugin will crash. It is not a toggle like overview. I found this out the hard way while writing this long comment...I lost all of it :-)

There are several changes coming to jump mode anyway (workspaces etc.), so this would have been added there anyway.

10. Alignment also works on rows/columns. If the current mode is row, it will center the active column. If the current mode is column, it will center the active window within the column. That is why it is not centered in the x axis of the viewport it you have another column on its right. For that, there is m/middle. I think that is what you want. That will center the window in the viewport. See the example key bindings in the README. middle is assigned to m in the submap.

11. I don't understand this. I don't use google meet, so I cannot visualize what you mean (maybe like a notification?). In general, "popups" can be real popups or windows. If they are popups, they belong to a window, and they work normally (these are menus, tooltips etc.). If you mean a window popup, they are simply windows. When they get added to the layout, they are treated as windows you want to tile, unless your add a special rule to make them floating. You could do that, make any window that doesn't look good when being tiled, floating. But this point works exactly the same in the standard Hyprland layouts: they tile anything that is not floating. And the same rules work for both regular layouts and hyprscroller.

12. The tutorial should definitely be updated. I will spend some time in it once I commit a new set of big changes. Making videos etc. is not my forte. The README, though, is quite thorough, and most people don't read it as it is, so making it even longer will not help much. That is why I wrote the tutorial, because most people would stop reading the README after a couple of minutes. But to anybody serious about using this plugin, I wholeheartedly recommend to read it completely, because it can prove very useful.

13. You would want a fitsize mode that doesn't keep relative aspects, but divide the space equally between the selected columns, am I right? I think that could be added. It is much simpler than what it does now :-)

[clotodex]

Don't do this now, because if you start calling jump mode recursively, the plugin will crash. It is not a toggle like overview. I found this out the hard way while writing this long comment...I lost all of it :-)

Oh nooo :D

Thank you again for taking the time to dive this deep with me. I am trying to finalize a lot of the points.

Here are my comments:

3. ✔ Yes exactly. So we are talking about the same thing. I have follow_mouse = 2 and the typical example for me is having the editor open and keyboard-focused while scrolling through windows of terminal outputs in the mouse-focused column to continue editing without actually "moving" the focus. (The hyprland usecase that is similar is coding or note taking next to another browser window where i wanna scroll through some reference without losing editor focus)

6,7,8 are all talking about the same thing but from different angles, as you rightly assumed.
I found a great clarification based on an existing feature: I expect the default behavior to be like window copy paste (found that feature and abused it for this). So I understand and WANT the window to take on the width of the column, but i dont expect the window to resize its height - exactly what window copy paste does. So I understand and WANT the hyprscroller layouting, not a grid, nor a whiteboard style (which defeats the whole purpose of tiling :D).
This makes my points very simple now:

6. new feature: moving a window with copy-paste style behaviour around a FIXED hyprscroller layout (not expelling) - I tend to reorganized my windows a lot

7. unintuitive default: :default behavior of admit or expel is unintuitive for me - only "need-to-have" rules, like column width are expected. I can understand the expel behavior - since it is creating a new column. But I would like my windows to be changed as little as necessary.

8. a mix of 6 and 7. For ergonomics I am missing an (additional) way that makes it easy to move windows around - i think copy-pasting comes closest but seems very un-ergonomic to me. I tend to just "move" windows in a direction, hence my request for 6. Enabling 6 and 7 would resolve 8. But my reasoning is the other way around - there is no ergonomic window moving feature (my opinion) while the default sizing behavior for moving windows is very unintuitive, which made me initially wish for the new feature 6. Hope this makes sense

9. Cool, cant wait for them :) what i meant was the gesture though, like swiping up with 4 fingers - this is not configurable to trigger jump (or at least i dont know how, your hyperland config example triggers on a click if i am not mistaken)

10. ✔ I think there was a bug with center (since it actually works now after an update). However you are right and middle is what i want - completely missed it in the readme (even though i read it multiple times)

11. Reproducable example for me: https://googlechrome.github.io/samples/picture-in-picture/ Toggling picture in picture in normal hyprland makes it floating, and in hyprscroller it gets tiled. I also dont understand why. This could also be caused by a change somewhere else and i need to debug this further - let me know if you can reproduce it. The expected behavior would be picture-in-picture becoming floating ABOVE the browser window without affecting hyprscroller at all. Btw a normal floating window works - it is just picture in picture.

12. let me know when the big commit happens and i am happy to help out, especially with the "how to get started" type guide

13. exactly! (in addition to the normal fitsize). And "selected" columns/rows are more or less always the visible - but reusing the code probably makes it more powerful :D I was also thinking about if the actual thing I want is a "cycle layout" rather than a fitsize type feature - since this would allow: equally, 2/3, rest equal, etc -> have not thought enough about this to feel like i have a good opinion, but wanted to share nevertheless

If you agree with what I am saying, we can split this discussing into separate issues. Or split out some and keep discussing the rest. But would be a shame for a super long comment to be lost again :D

• 3 = follow mouse 2 type column scrolling with gestures
• 6,7,8 or 6 and 7,8 for window behavior
• 9 = jumpmode + mouse (both gesture configurable and what you described)
• 11 = picture-in-picture broken (cause can be with the browser, hyprlands window rules, or scroller - tbd and waiting on your reproduction)
• 12 = overhaul tutorial and potentially make it more noob-friendly
• 13 = distribute space feature (likely like fitsize)

[dawsers]

OK, my comments:

3. I think we could do something like that. It would probably need to be optional. It will only work with follow_mouse 2 or 3. It will only work for columns that are in the viewport (otherwise you would lose focus of the active column). It would make the active window on a non-focused column the one pointed at by the mouse. So OK to mouse pointer changing the active window in a non-active column. I don't know if I want to add all that mess to gestures. There are already too many gestures to make it even more complicated.

...

7. If windows change height when being expelled, it is a bug. I verified it is the case, and have a fix for it.

8. So if I understand what you want correctly, you want a new dispatcher or a special mode for movewindow. That would take the active window, and expel it in the direction you want to move it, creating a new column. If the window is alone in a column, it will be admitted into the column in the direction of movement. So it would alternate between expelling and admitting, being a single window in its column, and belonging to the column in the direction of movement.

Maybe the animations are not as cool, but I think it is easier to select a window, go where you want and "copy" it there; you can even use mouse buttons for both selection and copying.

I need to think about how useful this one is.

9. There will probably be something like that.
   ...

10. I cannot reproduce any differences. PiP works the same if I am using hyprscroller or master/dwindle; they create a new tiled window. There is nothing special in that window; the layout manager adds it like a new tiled window. If you want it floating, you need to create a window rule. Maybe you have some rule somewhere in your config that doesn't apply when you run hyprscroller?

11. Yes, thank you. You can start taking notes with your experiences if you want to contribute to that. I am working on something for Hyprland, and after that, there will probably be a new version of both Hyprland and hyprscroller.

12. OK, I will think about how to modify the user experience for fitsize so it can create equal width columns/windows, maybe an extra (optional) argument or something like that.

[dawsers]

Expel now keeps window height after da68e3f