Transparent top panel when in opaque state creates some mind boggling use case

[didrocks]

I find that there can be some cognitive issues as the top panel isn't fully opaque when an application touches it.

Here are 3 use cases where I understand why this happens, but I'm afraid some users won't. Note that I'm with the default bionic wallpapers, and an application is maximized, so the panel is at max opacity in the theme.

Here is the case with a window in the background, under the panel. Especially when you focus other apps, you have that weird top bar mix.

With a window in foreground, another effect is puzzling: you see the window control, and some parts are thus a little bit more opaque (as you have the panel on front), instead of obfuscating it. I'm afraid that lead to people hovering and clicking it, while triggering another action (like the panel date, or the system wifi-sound-session menu)

It's even more visible when there is a suggested action in the headerbar.

It's not a strong case that the panel should be fully opaque, but I would like that we think of those issues. Is it only me who finds it mind boggling?

Note that I have 2 monitors (one on top of the other), and this is why I can easily (without Super + press) end up in that situation, the panel being on top of the bottom monitor.

[clobrano]

Note that I have 2 monitors (one on top of the other), and this is why I can easily (without Super + press) end up in that situation, the panel being on top of the bottom monitor.

Oh, that is why I've never tested this situation 😞

I'm afraid that lead to people hovering and clicking it, while triggering another action (like the panel date, or the system wifi-sound-session menu)

indeed it is possible, moreover a ticket has been already opened from a guy who thought it was a bug. So maybe, transparent panel when everything goes solid is not so intuitive.

I think transparent top panel on maximized window is kind of a living thing 😄, it looks good or bad depending on the wallpaper and the display quality, so if we keep it, we should accept we won't have total control of it.

To me it is fine to give a test to fully opaque again, also because we changed titlebar/menubar relationship last week and so the effect could be nice.

[Paz-it]

@didrocks - What I can't understand. how come some windows goes under the top-panel?
I tried to reproduce it but couldn't?

[clobrano]

@Paz-it you need a dual monitor setup with one monitor above the other and the top panel in the display at the bottom, then when you move a windows to the display at the top, the window goes under the top panel

[didrocks]

(that, or on a single monitor setup: having a window popping up, like dialogs, with fixed height higher than monitor size, or forcing it with Super + mouse click if you really want hurt yourself ;))

[Feichtmeier]

@didrocks just a question which came up in a different issue: did this also happen (hard to reproduce now) if you disabled the desktop in tweaks?

[didrocks]

Yes, this has nothing to do with desktop icons.

[rptfrg]

Transparent top panel looked so nice 😢

[Luxamman]

Is there a way (like in CSS) to "fake" a transparent background? Like put the desktop-background-image as a background behind the transparent bar when maximized? Needs to be positioned and cropped as a second layer behind the bar... but maybe possible? And everything behind the bar will be hidden and still look like transparent.

[Feichtmeier]

I am really torn if this is such a common use case that we need to change the transparency. While I understand that it might be "irritating" for users in my opinion it is not less irritating if the window is opaque because you can't even see whats under the top bar. It seems like we would try to mitigate a gnome design "mistake" once again (since the best would be if the window manager would understand what's happening and would adjust the window to it) and I am not sure if we are really mitigating this or even making it worse. So if we are still open for a discussion here:
I think the most common use case for a gnome user should be this (at least the GNOME designers think this is it xD):

• press super + P and select:
  
• now you want to drag a window to another workspace so...
• ... you press super
• you drag the window from the left screen (which is 1 extra additional workspace now) to the other workspaces in your main screen:
  

{drawn with a mousepad in mypaint... sorry... traveling atm and no second screen, I will replace this piece of art with a proper screenshot when I am back home}

[didrocks]

@Feichtmeier: please reread the thread on the forum, this isn't limited to multi-monitors only, there are cases with some screen resolutions this happens on a single monitor case with transient dialogs.

[didrocks]

@Luxamman: this is an interesting idea, maybe possible with some pseudo-elements. The benefit is that in that case, we'll have a consistent background color, while still have some transparency.

[clobrano]

Yesterday I tried with a background-image to mimic blur effect on panel, but no result yet. It might be due to my lack of svg skills however 😄 , I'll try again later

[clobrano]

OK, tried again and get support from IRC #gnome-shell: I'm able to make a nice and useless transparent background image, but blurred background is not supported.

Now, what about that pseudo-elements? 😄

[didrocks]

I'm not even sure this is supported by the Shell, but thinking from my small css knownledge, some people uses :before and :after pseudo elements, and then reposition it to fit the main element position and size, behind the main element.

There, we can maybe add a background color…

[clobrano]

What puzzles me is how to add the actual background wallpaper, but I'll look into it.

One thing we could do is use the same color we would have had with transparency + default ubuntu wallpaper. Just thinking out loud though, I know it wouldn't be the same 😞

[didrocks]

It doesn't seem that bad to me if we can pick the average color of the wallpaper with transparency and use that. At least, whatever is the wallpaper, you are sure the text is readabale.

[Luxamman]

Is a gradient possible?
Maybe we can try - instead of hoping for blur (I really wished we had blur... I was experimenting with kind of frosted glass pattern to fake it, maybe you have more luck) - what about a gradient in the Canonical color range? So we repeat a little the login screen and can use the gradient for simple separation of the bar and the dock. Also, the gradient gives a little bit the illusion of a blurred background but can be fully opaque.

This - unfortunately - isn't solving the main problem here, but maybe an idea for max window mode. And I also don't see the problem resolved in vanilla...?

Quick mockup - brightness adjustment will be a b*** here:

[Feichtmeier]

I asked the author of the awesome blyr extension for an idea on how to bypass our issue with a blur and here is his answer:
yozoon/gnome-shell-extension-blyr#8 (comment)

[clobrano]

what about a gradient in the Canonical color range?

I made some tests, but gradient seems not supported (same gradient works in gtk-communitheme, but not in panel). Solid color, like a mix between Canonical's colors, is possible though

[Paz-it]

How about using an .svg for the panel and condition it to change color acording the wallpaper but only when windows are maximize? It was possible in Unity.

[Luxamman]

pity that we are technically limited - dark aubergine for the top and just slightly brighter for the dock could look good - did you already try that @clobrano?

[Feichtmeier]

That's my last try on weither this is really such a problematic situation (I am searching parallel for solutions btw, so please don't get the impression I try to block some greater decision ;O) or not:

I want to point out once again, that we are using gnome shell here. Maybe gnome shell has some performance issues but there is really one thing that does the shell right and that is the dash/activities/workspace overview.
I bet you all know what you can do with gnome shell, but I think some of our designers don't use it on a daily basis so that's a video I recorded to show what would be the most "gnomish" (-.-) way to move a window from one screen (= workspace) to another:
https://photos.app.goo.gl/EwggmQ9W4pRQyX6b2

And this is if you want to use two applications beneath each other:
https://photos.app.goo.gl/hyX6VBJpqMjm3Eo52

Vanilla gnome shell (gnome-session) uses the transparent top panel with unmaximized windows, too. So those situations would also occur in gnome-session.

[Luxamman]

@Feichtmeier I'm with you, like said. Rather solving the "grey wall" problem, than a gnome vanilla problem...

[clobrano]

How about using an .svg for the panel and condition it to change color acording the wallpaper but only when windows are maximize? It was possible in Unity.

Not with Gnome shell, but I don't understand how this would solve the problem.

I bet you all know what you can do with gnome shell, but I think some of our designers don't use it on a daily basis so that's a video I recorded to show what would be the most "gnomish" (-.-) way to move a window from one screen (= workspace) to another

😄 however you might still do the other way. It would be awesome if mutter was able to avoid headerbars to stay under the panel (maybe moving them by some pixels) :(

@didrocks you think the above ^ is possible? Or Mutter is the wrong actor here?

[Feichtmeier]

@didrocks @Luxamman @clobrano @madsrh
Do you all like the jet shell? If yes I guess we have the solution we can all live with and we could close this issue 💪

[clobrano]

It's certainly better than it was last week 😄

[Luxamman]

Well, back to all black^^
Still a compromise, but at least solves the problem.
Maybe experimenting a little with the separator between bar and dock in max window for visibility.
And like to have a longer transition between the window and max window state :)

[Feichtmeier]

@Luxamman
It also solves another issue which I was about to write a wall of text into the mockup thread:
the contrast again (yes I know yawn)
Now we have a better contrast on
a) the text of popups and popups [better readable at night or at bright sunny days]
b) better contrast between the headerbar and the popup so I could remove the over aggressive border

[didrocks]

smile however you might still do the other way. It would be awesome if mutter was able to avoid headerbars to stay under the panel (maybe moving them by some pixels) :(
@didrocks you think the above ^ is possible? Or Mutter is the wrong actor here?

oupsss, sorry @clobrano, didn't see your ping. No, this isn't something that Mutter is able to handle AFAIK (and yes, it's the correct actor). I doubt as well upstream would change this behavior as it's not a problem for them (black panel)

@Feichtmeier: sorry, what do you mean by jet shell?

Vanilla gnome shell (gnome-session) uses the transparent top panel with unmaximized windows, too. So those situations would also occur in gnome-session.

Note that it's not "unmaximized windows" which goes for transparent Shell, the algorightm is "when no windows is in next to the panel (some pixels or touching it). We extended that in the ubuntu session by "when no windows is next to the panel or dock".

[Feichtmeier]

@didrocks the color of the opaque panel and dock which is in master now to solve both that problems mentioned in this issue and the grey wall of doom

[didrocks]

After a alt+F2, rt to ensure I'm running it, I really like it as well :)

[clobrano]

I doubt as well upstream would change this behavior as it's not a problem for them (black panel)

I agree, but perhaps I can push the fact that controls under a panel are not usable anymore 😃

I'll have a look at mutter, but I might need some help (on IRC) to set it correctly. Tried some times before and got some problems...

[Feichtmeier]

All these situations can also occur when not maxed and not only in communitheme session but also ubuntu (dock and panel) and gnome session (panel). So how much is this an issue too ?

[didrocks]

I don't think when the button aren't usable due to controls being under an opaque panel is an issue personnally: you don't see it, you can't click on it. That makes sense to me :)

[clobrano]

Closing this since the panel is not transparent anymore in this state