YaLTeR
Overview
Something that zooms out and lets you see multiple workspaces and windows on each monitor. The design concepts here are very close to what I have in mind: https://github.com/YaLTeR/niri/discussions/352#discussioncomment-10094739
Actual interactions in the overview (click on window to focus it scrolling it into view? moving windows around workspaces like in GNOME Shell?) will need some trying and evaluating hands-on.
There are some questions on what to do with layer-shell surfaces. It probably makes sense to draw a separate background layer on each workspace in the overview, and the top layers should stay on top. Once again will have to try and see what works.
Perhaps just hiding the layer-shell is ok as I doubt there's much need for an 'overview' of that layer. I could be wrong but as of now I don't even use it beyond the waybar currently.
What are other uses for layer-shell?
@mastoca Launchers e.g. wofi, fuzzel, bemenu, etc. also use layer-shell surfaces. Still I also prefer that at least such launchers and bars should be hidden in the overview, will make implementation simpler too?. The bar is going to look tiny and unusable at that size anyway.
Uhh, notifications? Yeah, it's a mess. Best show only the normal app windows as that design concept shows I think.
@salman-farooq-sh I agree focusing on just the normal app windows would satisfy 95-99% of use cases.
If we must get fancy, I would suggest a filter to omit certain windows from participating like the screen recording does (perhaps would be a nice phase II).
My idea is to show Background layer on every workspace, but show all other layers just on top, so you'll still see your bar as normal.
@YaLTeR Yeah that is a good way to do it, it feels consistent with the normal (current non-overview) mode specifically that launchers, notifications, and bars remain at their own place when navigating columns/workspaces.
Regarding background, how about keeping it fixed too? The vertical column in the concept design designating the viewport also looks great by simply making it a bit darker.
Wondering how would floating windows show up in the overview? Stickied in the middle viewport?
Regarding background, how about keeping it fixed too? The vertical column in the concept design designating the viewport also looks great by simply making it a bit darker.
I think it will make more sense to duplicate the background, and generally tie it to the workspace. Think what GNOME Shell does past GNOME 40. It will also naturally allow for per-workspace backgrounds in the future.
Wondering how would floating windows show up in the overview? Stickied in the middle viewport?
Not sure yet. Maybe just on top of the "visible" rectangle in the middle.
It will also naturally allow for per-workspace backgrounds in the future.
Oh, if those are in the plans then yes, background per workspace is good. But what will the rest of the area on the left and right of the "viewport" / "visible rectangle" show in overview? The background or some solid color?
just on top of the "visible" rectangle in the middle.
Agreed. Per workspace.
But what will the rest of the area on the left and right of the "viewport" / "visible rectangle" show in overview?
Some solid color I guess, though not sure if it'll look good yet.
Thinking on how it looks in PaperWM, the ideal for me would be wallpaper in the visible rectangle, and very blurred wallpaper (a la BlurMyShell) in the areas outside of it. Not sure how that plays with per-workspace backgrounds, though. Maybe blurred wallpaper of focused workspace. Apologies for the bikeshedding; I just came from the 10/GUI demo video and it got me thinking about the overview.
I have 1.5 things I would like to ask of this. Closing applications using a touchscreen and separately using only a keyboard only. I am honestly not sure how this would look from an implementation standpoint that would be acceptable. I have multiple ideas in mind, but this would be really nice to have.
Closing applications using a touchscreen and separately using only a keyboard only
How about just having [Shift|Ctrl|Configurable mod?] + click close the window in overview mode? This covers both touchscreen and pointer use. For keyboard only you would just keep your existing close-window key binding.
Also I've only just discovered this issue and it's made my day.
For touchscreens my wish is to close the window with touch itself, without needing any modifiers, such as swipping to the side of the screen, or having a close button in the top right corner of the app.
I currently use niri as my main DE on my tablet which has no keyboard attached so a modifier won't really work well for that.
I'd love to know how you use it without a keyboard! Do you use any other assistive tech / input device? I've got a little waveshare 10in touchscreen lying around, I'm gonna give it a go.
FWIW I would prefer the option of dragging and dropping the window to a dropzone in the corner of the screen to kill them. The thought of trying to scroll down and accidentally flicking a window into oblivion with a no-confirm quit is already making me feel anxious 😆
@boomskats to avoid hijacking the thread with offtopic https://github.com/YaLTeR/niri/discussions/325#discussioncomment-11298999 more discussion on keyboardless use in general can be found here. once xkbcommon tags a release and smithay/niri updates to it, I plan on making a video showcase on my tablet as well as update the dotfiles.
I'm not sure how is @YaLTeR timeline to implement this feature (I'd offer to contribute, but I'm a backend dev, not sure where to begin to ever implement this ;) ), but this is something I'd appreciate a lot in niri.
One dirty hack that occurred to me is that, if niri msg windows provided the column and row of each window (and maybe width), I could try adapting sov (nirov?) to fetch window info from the json output to assemble the grid -- and ~figuring out the fields for column, row and width seems way more simple.~ this seems to be already in the works
My ideal overview system would combine something like the zoomed-out view with a fuzzy search -- my vision for the tool I started making for myself would have the zoomed-out view on one side, with a window search box on the other side. My intent is to make it highlight the fuzzy-finder matched windows while typing, and jump to the first/selected one upon pressing enter.
window searching setups already exist and are used, and I think combining them by integrating a zoomed out overview into the search would make for a very nice computing experience.
Would it be an idea to rename this function to expose instead of overview, since the latter is more generic and is also used in various places in the documentation as a general term? Perhaps it could help to avoid any ambiguity.
I am very used to "Overview" (everyone in GNOME calls it that) and very not used to "Expose" (I think I only heard that on macOS), so I much prefer "Overview".