-
-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overview #850
Comments
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? |
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.
Not sure yet. Maybe just on top of the "visible" rectangle in the middle. |
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?
Agreed. Per workspace. |
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. |
...with a super slick transition involving blur. *chefs kiss |
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. |
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: #352 (comment)
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.
The text was updated successfully, but these errors were encountered: