Suggestions for Improving "Running Applications" pie menu

[ykhurshid]

It would be nice to have an option to preview windows when hovering your cursor over their respective slices.

It would also be great to automatically group Windows of the same application (or possibly custom class) as their own submenus. I often have quite a few different windows for my browser for example so it can get a little crowded.

[Schneegans]

These are good suggestions which should be possible to implement. The first would require an OnHover D-Bus signal which I wanted to add anyways. What do you mean with "preview windows"? I think easiest would be to make all other windows transparent but for the hovered one. Like the Dash-To-Panel extension does it. The last should be easy to implement as well, I guess. But we should add a switch to make this optional.

[ykhurshid]

What you're proposing is what I had in mind as well when talking about previewing windows.

[Schneegans]

I am currently working on this. The OnHover and OnUnhover signals are already merged to the develop branch. Additionally there was quite a lot of refactoring necessary to allow for arbitrary configuration widgets for the items in the menu editor. Until now, it was only possible to set one additional custom data property per item - but for this feature here, we require more settings, like "Group Windows by Application", "Show Current Workspace Only" or "Highlight Window". But that is now possible as well!

So I thought - maybe we can use the opportunity to think about the window list menu a bit more... it is one of the menus I do not like very much, because the positions of the entries always change. This makes this menu very inefficient - you always have to search for the correct window!

But maybe we can do better than simply copying Ctrl-Tab! Here are some thoughts:

• Should we sort the entries alphabetically to make the ordering more deterministic?
• Should we add an option to allow for some kind of name-based filtering? This way a user may create menus for specific windows only! You could create your own menu structure and at some point are all Firefox-windows, at another are all terminal windows of the current workspace, etc.

Do you have more ideas? The goal should be to design it in such a way, that window items are at predictable positions...

[ykhurshid]

A lot of good suggestions! Customizability is the way to go for sure and in particular the ability to create menus specific to certain applications.

A possible good default scheme for a running applications pie menu with relatively predictable behavior:

1. The running application pie menu gets populated with the first four items following the order right, left, up, and down. any further items get added in a clockwise manner bifurcating from the diagonals further and further (though this is only practical up to 12 items IMO).
2. The only time a menu item shifts its position is if it is on a diagonal and an item adjacent to it has been removed. So if you have 4 windows and one gets closed, there is no shifting of positions. If there are 5 windows and one gets closed, there would only be a shifting of positions if the window that was closed was the 5th window at the diagonal. If the closed window was at one of the other 3 cardinal directions, that position would remain blank until a new window was spawned to take its place.
3. All windows of the same application are grouped together once there are more than 8 windows in the menu.
4. There should be an interactive way to create your own window groups on the fly which will appear in your running application pie menu as its own submenu at a fixed position that you can set.
5. Hovering over an item will preview its contents.

I have no strong preferences as to how you initially sort these items (alphabetically is not a bad default scheme) but predictability and usability should take strong precedence over consistancy.

[Schneegans]

This sounds reasonable, but the main issue is that Fly-Pie does not really know when a window was opened. While we could somehow try to track this, there are definitely many cases where this would break (for example, the extension is reloaded whenever you logout / login. So after a re-login the window-order would be changed). So I think we have to come up with an idea which is solely based on the current state of the windows / workspaces without information about prior states.

[ykhurshid]

Sorry, read your comment only yesterday. Took me some time to process. I have some ideas on how to deal with this. I will leave the question of making window switching truly deterministic for another day. There are a lot of low-hanging fruit we can pursue that can greatly improve the usability of the menu without having to achieve that lofty goal. Here is my new proposition:

1. By default, windows that occupy their own unobstructed space in the display (that is without any window above or below it) should not be listed in the pie menu unless if they are considered pop-ups of the currently focused window. The menu should also be local to the currently focused monitor.

2. Windows that are occluding or are occluded by the currently focused window will be on the top (occluding) and bottom (occluded) positions in the pie menu. This follows an intuitive stack-based scheme.

I don't know if this is outside the paradigm of marking menus but I envision concentric rings of applications depending on their position in the stack instead of having to keep every application on the same circular "row". In practice, this will often take more of the form of a tower of icons that contracts and expands in width along its length than a pie but I think it will be very useful compared to the current solution

3. The windows that 2 applies to should in turn be sorted based on their own spatial location relative to each other. So if there are two side-by-side windows that are currently being occluded by the currently focused one, the one to the left should occupy the bottom left slice in the pie menu.

4. Windows of the same application class (or customized group) as the currently focused group should be on the right and left of the pie menu. Optionally, you can also click (or hover) on the central node of the pie menu to pop up a secondary pie menu that only cycles between windows of the same group or class.

5. To make this all usable in hover mode, there should be a configurable timeout period (500 ms would be a decent default imo) where an application is then selected (this will be necessary because of the idea of having multiple rows of icons).

[Schneegans]

I think for now, most of your suggestions require too much fundamental changes to Fly-Pie. I like however the idea of sorting windows based on their spatial arrangement very much!

I have implemented already filtering of windows by their title and sorting / grouping by application. This feels pretty solid and makes the menu much more deterministic already. You can test the current state in the branch feature/advanced-window-management. But expect bugs 😄

I am currently struggling with implementing the window peeking functionality we discussed earlier. Most of it already works quite nicely, but there are still some really hard-to-solve issues when peeking windows which are on another workspace. This mostly because there seems to be no reliable signal which is emitted when the workspace switch is completed...

[Schneegans]

Regarding the window peeking - I now simply focus the hovered window if window peeking is enabled. This feels surprisingly good and is really easy to implement. Messing with the window transparency leads to all kind of strange behavior especially when switching workspaces in the meantime.

I just merged the branch to develop. Let me know what you think!

[ykhurshid]

Sorry, saw this quite late. I don't quite like how easy it is to mess up your window configuration this way. It would be perfect if there was a way to undo a focus. Maybe, undo the focusing of the window by clicking on the centre or hover over it for a period of time for hover mode This should not exit you out of the submenu itself.

All this would require is for flypie to track which application was in focus when the submenu is invoked and only till the submenu closes (by either selecting a window and exiting or cancelling. Maybe, we should also be able to close applications by right clicking on their icons in the menu.

I really like the improvements you made regarding grouping application windows and name filtering. I think aside from the issue outlined above, it's already superior to the built in alt-tab.

[Schneegans]

What exactly do you mean by "mess up your window configuration"? Of course, you will mix up your window stacking order with the way it's implemented right now. But is it sufficient to restore the previously focused window when canceling the selection? The stacking order of the other windows will be different...

Once I have some time to work on this, I will try to implement the real window peeking. But it's really cumbersome if you try to peek a window on another workspace. Dash-to-Dock solves this by temporarily disabling the workspace switch animation. So it looks as if the peeked window is actually on the current workspace. I do not like this approach very much as one looses a lot of spatial context...

[ykhurshid]

What exactly do you mean by "mess up your window configuration"? Of course, you will mix up your window stacking order with the way it's implemented right now. But is it sufficient to restore the previously focused window when canceling the selection? The stacking order of the other windows will be different...

I think that would be a good enough solution for me currently, yes. I'm aware that tracking and restoring stack order will be something quite tricky and currently focusing on that will slow down initial development so it should be more of a long term goal imo.

Once I have some time to work on this, I will try to implement the real window peeking. But it's really cumbersome if you try to peek a window on another workspace. Dash-to-Dock solves this by temporarily disabling the workspace switch animation. So it looks as if the peeked window is actually on the current workspace. I do not like this approach very much as one looses a lot of spatial context...

In fairness, you could just have two different menus, one dedicated to switching between apps in the current workspace and another that switches between different workspaces. You could then chain the two together by having each workspace it's own submenu, being the children of the root node of the pie menu. Once you enter each submenu, it switches to that workspace and then allows you to switch between applications. That way you never lose your spatial context.

[Schneegans]

I cleared the milestone as Fly-Pie 7 will be focused on GNOME 40 support only.

[juarezr]

Regarding the window peeking - I now simply focus the hovered window if window peeking is enabled. This feels surprisingly good and is really easy to implement. Messing with the window transparency leads to all kind of strange behavior especially when switching workspaces in the meantime.

It would be possible to have an alternative approach to Window Peak other than focusing?

Changing the focus interferes with other extensions like:

• Mouse Follows Focus
• Alt-Tab Move Mouse

Maybe one could:

1. Draw a line/trace pointing to the selected window without changing the focus.
2. Change the Experimental Hover Mode setting from on/off to Never/Always/Except at End and require a (Click) for switching the focus when hovering a leaf/terminal node.