sort icons according to window position

[ehula]

Can the icons be sorted from left to right according to the position of the windows on the workspace?

For instance, if I have a master and two slave windows, the master window icon would appear first, then the two slave icons. If any of the windows move, the order of the icons are changed as well.

[cyrinux]

I will study this 👍

[psimovec]

I think we will need secondary sorting if the distance from left side is the same.. For master layout it would be sufficient to have secondary top to down sorting, but for dwindle it might not be optimal. Just throwing ideas/thoughts, not sure what will work best..

How do we want to sort this? F is for Firefox
Left to right, top to down it would be F,A,C,B, but for dwindle layout it might be nice to possibly keep A,B together (FABC)? It might be nice to somehow follow the dwindle tree layout..

Maybe we can find some general solution taking into account all 4 borders? (lowest x, highest x, lowest y, highest y).. Or at least some quite good solution, and then making the sort order possibly hackable in config if we don't agree on which sorting order is the best 🤔

So maybe we don't need to/should not implement the ordering in this app, and just to use ordering of Hyprland (by using MOD+TAB (dispatching cyclenext)) Hyprland goes in order FABCF...

It should probably be checked if there is some decent ordering is implemented in Hyprland, and possibly implementing it in Hyprland itself if there is not..

I think the order of icons should definitely visually match how cyclenext behaves

[ehula]

I think sort order should be as follows:

Master Layout:

1. Non-Fullscreen Mode:

• Master window
• Slave windows in cyclenext order
• Floating window(s) in cyclenext order

2. Fullscreen Mode:

• Active window
• Other windows in cyclenext order

In regards to Dwindle Layout, since I don't use it, I don't know exactly how it works. Maybe one of you could come up with a similar design for it.

[maximbaz]

Thanks for raising the issue, I also agree the order should be more predictable, and I like the idea to follow cyclenext. @ehula could you clarify why you think we should group windows by their floating status, instead of just follow the order exactly as Hyprland's cyclenext decides it to be?

In fact, it looks like the following command can return us the order of cyclenext (in the example, for workspace 10). I wonder if this would be of help to implement this:

hyprctl clients -j | jq '.[] | select(.workspace.id == 10) | .title'

[ehula]

@maximbaz Because it seems that when you toggle the floating status of a window back to non-floating, it get added to the end of the cyclenext order, but what I don't know is what order the window is in when it is in floating mode. If, when it is toggled into floating mode, it gets moved to the end of the cyclenext order, then we could simply follow hyprland's cyclenext order, but I don't think that is the case. Can we check this?

Side note: I really wish there was a way to cycle through all the windows, including floating windows, using cyclenext. Do you know if there is a way to do this?

[ehula]

hyprctl clients -j | jq '.[] | select(.workspace.id == 10) | .title'

This doesn't seem to list the windows in cyclenext order. If I move windows around on a workspace, it continues to list them in the same order. I don't know what order that is, but it looks like creation time.