This time I anticipate that I am not convinced with this solution for the following reasons:
with dock on the right side (or with window controls on the left side) it is still possible to have some important window button under the dock and so visible to the user, but not clickable. Basically we’re going to have the same problem we had with the top panel
it looks out of place and a bit messy (but I agree this is not objective). Probably because it’s a simple flat panel, or because of the position (at the bottom of the screen, or with some blurriness, would be totally different).
The popover alpha value is quiet low at the moment at 0.015. Increasing it by only 0.01 to 0.025 is a noticeable yet still usable change. Everything above makes it too transparent - the following is 0.025 (maybe even this is too much):
And to answer why this should not be used for notifications is that somehow this value is again far too low for a white background as you won’t notice any transparency at all on the notifications then (no idea why the alpha value has different results on dark and light backgrounds):
Current notification alpha 0.1 first without and then with mousover:
Sorry, here we go: I fear this is the outcome of our “downstream” dock, which is has not been planed by the gnome designers. How does the ambiance shell does this?
I think it does not look messy with 0.1 because we now have the thin line at the edge of the maximized windows. Yet I understand that some might find the three colored areas (top panel, dock and window) to look odd.
Yes, you’re right. Upstream dock is shorter and appears only in overview, so it’s a totally different use case.
Sorry to stress this again, but we still end with the same problem of top panel transparency, and even more since it’s easier to have windows below the dock
Hm, but this problem is present in unmaximized situations, too. with the panel and the dock. So by the arguments of the initial issue we could go full opaque in maximize and unmaxmized states, too. To prevent the windows to be visible under the dock and panel in every multimonitor situation I don’t want that!
Ahhhhhhhh, no!
Maybe we have miscommunicated. I said the old Ubuntu notify became more transparent on hover, which was fine since you couldn’t click them. But these can have buttons, so no.
Ah not the same thing. With unmaximized window you can still see most of it, so it’s clear that it’s just a window behind the dock/panel. With maximized window you’ll see only a piece of it
This is more an issue in a multi-monitor setup, right? Because I can’t reproduce.
Maybe full opaque is really the way to go since there isn’t any other way to fix this through the theme. Though that again brings up the dark stripe issue. I’m going to propose something a bit outrageous, but, the idea behind Adwaita’s black top-panel and curved edges is to have the top-bar blend into the monitor. Maybe we can follow that idea and have everything become plain black or near plain black when a window is maximized?
There are ways to reproduce it on single monitor as well, it’s described in the ticket, but yep it’s not a common issue.
This is the same reason why I proposed darker panels.
@luxamman proposed a gradient with Canonical’s color (mix to decide), which is a nice idea, but it looks that panel and dock does not support it. Using only solid and bright color, instead, it’s a possible way, but either it’s very hard to find the right mix or in general a bright but monotone “top line” is not nice to see (unless it blends into the monitor)
So, the question is: whether we flip a nice/working design because of a problem we can not control, for some, special usage scenarios?
As I understand it, it would be a step back to all solid - because to “solve” that problem it would be necessary to make non-transparent bar/dock all the time - or?
And IMO it is not better to have solid bars when windows are underneath - but I also don’t understand why having the dock always visible on the bottom when working with a wider display ratio - waste of space^^
I think we could try to have a slight difference in transparency between bar/dock, but still work with transparencies. A much higher amount of people will have a problem with the “grey/dark wall” in max windows mode, than having problems with hiding windows in multimonitor mode behind the dock on the bottom and so on…
I’ve repeated it multiple times (on the bug report and forum) that the issue isn’t multimonitor specific, so please, don’t be fooled by this and qualify as a corner case. It can easily triggered on small monitors, like typically a 14’ laptop monitor.
(Also, this isn’t related to the Dock being at the bottom? Unsure where you read that, it’s even not the case in any of the reported screenshot…)
Edit: that’s not denying that the wall of grey isn’t an issue. We all agree on this.
Quoting @madsrh from GitHub since we should indeed discuss this here :
"A quick note: I don’t think of this as 3d (origami style sounds good) and I don’t think it will break the user experience. We have lots of 3d stuff in the GTK theme - does the user know the difference between shell and GTK?’
No the average user does not know the difference nor does he want to know
But the shell has other functions than the GTK applications. I would agree to say, that an application is an application and that the user would like them to look all the same no matter if they are built with Qt or Gtk or Java. But since the shell fulfills other, more dramatic tasks than the applications, I think it’s good to underline this difference in function → visually. The shell is the visual manifestation of the operating system the applications run on.
@mpt wondered why all menus have different colors in the different places and in light and dark versions of the gtk theme.
I thought about this for a while and maybe he is right about this.
Our principles or planing towards the shell and gtk differentiation changed several times since Novemeber. When you dive into the css and try diferent things you know what the shell can render and where it’s limits are.
One way to bring all menus to at least the same colors, would be to adapt both light&dark gtk themes to the popup color of the shell. We thought about the different way around some months ago, with changing the popover color to white (Mockups/new design discussions - #274 by frederik-f ) but this the problem with that way is, that the shell theme can not change without manually changing it in gnome-tweaks, unlike dark and light css which can change from app to app or by using the new gnome night light feature (gnome-calendar 3.30 and gnome-builder as examples).
So since I am really bad with Gimp I simply clicked the headerbar at a position where the shell menu opens but it looks like I clicked the gtk hamburger menu:
The context menus would look “like this” but again, I clicked the next free pixel on my desktop to give an impression how this would look with gtk context menus:
ha that’s funny! 
I don’t want that! 
to solve this problem:
:
