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:
In this scenario notifications should stay light imho, because they overlap the dark headerbar. Adwaita doesnt have this problem because they have everything light in the gtk theme
And dialogues are currently both light in the gtk and shell I think this is fine and our “friendly dialogues” idea still works.
But we could also try a completely dark approach. I don’t know if we did take into account that dark notifications can have a different dark than headerbars. Back then we had several problems which we have fixed now: headerbar/shell color, osd border, drop shadows
Edit: no, not the same color as the dark gtk3 menus. The shell popup color (jet, with transluscent borders) for everything in the gtk theme (menus, context menus, popovers). We wouldnt change anything in the shell
I could make 1 branch for each colour version we like to try. Maybe you are right and we would need to go full dark again by this logic. Maybe not
Let’s wait for the others to find this thread
It’s probably because it’s semi-transparent, but the menu is actually darker in the dark variant. #222222 in light variant and #1d1d1d in the dark one. This way the distance from the headerbar color is probably too evident in the dark variant
this has a nice sideeffect for chromium & electron (since electron is chromium based). It fixes the issue with electron always using the light menus, by … having dark menu for all variants ^^
Looks great @frederik-f, but I’ve noticed an issue with the screenshots you’ve posted… I believe the date for world domination is the 18th October 2018
to solve this problem:
:
he is right about this.
