Can you please provide a screenshot?

Created attachment 354032 [details]
Screenshot showing white on light top-bar

Hmm, yes. In this case it looks like the text shadow and the background colour are at odds with one another.

(In reply to Russel Winder from comment #0)
> The writing needs to switch to a fairly dark grey so as to have reasonable 
> contrast with the background

No, if there's a contrast issue with text and background, then there's no single text color we can pick to fix it. If the text shadow isn't enough, then there's no way around analyzing the background area underneath the top bar and picking a text color that contrasts sufficiently (within reason of course - if the background is a checkerboard, then we've lost ...)

I know Alessandro had some thoughts on this, so adding him to the CC-list

(In reply to Florian Müllner from comment #4)
...
> No, if there's a contrast issue with text and background, then there's no
> single text color we can pick to fix it. If the text shadow isn't enough,
> then there's no way around analyzing the background area underneath the top
> bar and picking a text color that contrasts sufficiently
...

Well, we use text shadows on the lock screen, for the same purpose. The issue is the text shadow in combination with the background colour of the panel itself. I'd be up for either increasing the opacity further, or perhaps even removing it altogether.

Elementary OS solves the readability issue by changing the top-bar style depending on the background used. I'll attached three screenshots that show how the top-bar looks depending on the luminance of the background behind the top-bar. We could adjust the shadows depending on the background, or entirely follow the Elementary OS' style approach.

Created attachment 354119 [details]
elementary-os-dark-text

Created attachment 354120 [details]
elementary-os-light-text

Created attachment 354121 [details]
elementary-os-translucent-bar

(In reply to Alessandro Bono from comment #6)
> Elementary OS solves the readability issue by changing the top-bar style
> depending on the background used. I'll attached three screenshots that show
> how the top-bar looks depending on the luminance of the background behind
> the top-bar. We could adjust the shadows depending on the background, or
> entirely follow the Elementary OS' style approach.

Thanks Alessandro, that's useful.

The goal of the dynamic top bar background is to:

 1. Create a sense of space when there aren't any maximized windows
 2. Focus windows when they are maximized, by making the top bar blend into the bezel

For 1, more transparency is better, so I'm keen to increase it as much as possible, potentially to the point where it's fully transparent.

I'd thought that using text shadow below the items in the top bar would be enough to distinguish them when the background is transparent. However, that doesn't seem to be the case when the background is light. That would indicate two possible approaches:

 1. Make the items dark, like Elementary does
 2. Increase the opacity of the background colour

I think I'm slightly more in favour of option 2.

Something else that my testing revealed is that we might need to look at hover and active states for the top bar "buttons". A fully transparent background with an active popover attached to it looks a little odd to my eyes.

Another solution is to use a gradient. Some WIP patches are coming.

Created attachment 359215 [details] [review]
common: Use a gradient when free floating

Also, tweak the shadows as per latest design.

Created attachment 359216 [details] [review]
panel: Use a gradient when free floating

Also, update the theme as per latest design.

Review of attachment 359216 [details] [review]:

::: data/theme/gnome-shell.css
@@ -119,3 @@
 StScrollView.vfade {
   -st-vfade-offset: 68px; }
-

Mmh, different sassc versions? Would be good to keep the noise down here ...

::: js/ui/panel.js
@@ +1041,2 @@
     _updateSolidStyle: function() {
+        let metaBackgroundActor = Main.layoutManager._bgManagers[Main.layoutManager.primaryIndex].backgroundActor;

No poking into private layoutManager properties, sorry.

Maybe a cleaner solution would be to handle the background properties in layoutManager instead? Something along the lines of:

Main.panel.actor.connect('notify::style-class', Lang.bind(this, this._updatePrimaryBackground));

_updatePrimaryBackground: function() {
    let backgroundActor = this._bgManager[this.primaryIndex].backgroundActor;
    if (Main.panel.actor.has_style_class_name('solid')) {
        ...
    } else {
        ...
    }
}

@@ +1044,3 @@
             this._removeStyleClassName('solid');
+            Tweener.addTween(metaBackgroundActor,
+                         { gradient: false,

Booleans aren't animatable - either this turns false the moment the animation starts (which means the animation is pointless), or the opposite tween keeps the property at false until the end of the animation (which means *that* animation is pointless).

What you really want is setting the property to true for either animation, then unset it in an onComplete handler when animating out.

Created attachment 359365 [details] [review]
panel: Use a gradient when free floating

Also, update the theme as per latest design.

Review of attachment 359365 [details] [review]:

::: js/ui/layout.js
@@ +294,3 @@
         Main.sessionMode.connect('updated', Lang.bind(this, this._sessionUpdated));
+        Main.panel.actor.connect('notify::style-class',
+                                 Lang.bind(this, this._updatePrimaryBackground));

We'll also need to initialize the effect correctly (that is: call the handler here), and make sure to update it whenever the primary background actor is recreated.

@@ +320,3 @@
+    _updatePrimaryBackground: function() {
+        let metaBackgroundActor = this._bgManagers[this.primaryIndex].backgroundActor;
+        if(Main.panel.actor.has_style_class_name('solid') || Main.panel.actor.has_style_pseudo_class('overview')) {

Style nit: Missing space after if.

Also not sure about the 'overview' class - the overview uses its own background actor, so what we do to the "normal" background underneat doesn't really matter.

(It does mean that we don't get a correct transition between overview background and normal background unfortunately ...)

@@ +321,3 @@
+        let metaBackgroundActor = this._bgManagers[this.primaryIndex].backgroundActor;
+        if(Main.panel.actor.has_style_class_name('solid') || Main.panel.actor.has_style_pseudo_class('overview')) {
+            metaBackgroundActor.gradient = true;

This is common to both branches, so could just keep this outside the if statement

@@ +328,3 @@
+                               transition: 'easeOutQuad',
+                               onComplete: function() {
+                                   metaBackgroundActor.gradient = false;

We need to make sure that this is never called after the solid style has been removed again, so you should do something like

Tweener.removeTweens(metaBackgroundActor)

before the animations

(In reply to Florian Müllner from comment #16)
> [...] and make sure to update it whenever the primary background
> actor is recreated.m
Can you point me to the right way to do this?

> Also not sure about the 'overview' class - the overview uses its own
> background actor, so what we do to the "normal" background underneat doesn't
> really matter.
> 
> (It does mean that we don't get a correct transition between overview
> background and normal background unfortunately ...)
The code for the overview was not working because I didn't connect to the 'notify::pseudo-class' signal. Even if the background actor is not the same, hiding the gradient when we enter in overview mode and show it when we leave the overview mode let us see some parts of the animation. Is it possible to fade the switch between the two background actors? It might improve the situation.

Created attachment 359423 [details] [review]
panel: Use a gradient when free floating

Also, update the theme as per latest design.

*** Bug 787940 has been marked as a duplicate of this bug. ***

For what it's worth, the analyzing top bar of elementary OS looks absolutely gorgeous to me. I hope it is being considered.

I am currently getting a mid-grey top bar and I think it works very well: I definitely prefer it over the solid black now I have tried it for a while.

We also have a problem with the button clicked state, which is a blue underline that pretty much vanishes on the default background, any idea about that?

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.