The pure black background we use is designed to make the top bar blend into the screen bezel and give focus to application windows (particularly when maximized). It's a key part of the shell's visual design, so I doubt we want permanent transparency here.

It could be interesting to make the top bar transparent when there are no maximised windows (in the current workspace), though.

Yeah, Endless does something similar where we set the top bar to be partially translucent, which becomes full black upon maximization.

Allan Day,
This assumes the screen bezel is black, doesn't it?

Even Android has a transparent topbar.
https://upload.wikimedia.org/wikipedia/commons/a/a7/Android_L_Develpment_Preview.png

As does iOS:
https://upload.wikimedia.org/wikipedia/en/3/3e/IOS_8_Homescreen.png

As does OS X, KDE, Unity and Windows.

So the pure black top bar seems to be a rather odd descision.


Jasper,
What is "Endless"?

Endless is an operating system that's based on GNOME, built by my employer.

(In reply to Moo from comment #3)
> Allan Day,
> This assumes the screen bezel is black, doesn't it?

Yes - which is true the vast majority of the time.

> Even Android has a transparent topbar.
> https://upload.wikimedia.org/wikipedia/commons/a/a7/
> Android_L_Develpment_Preview.png
> 
> As does iOS:
> https://upload.wikimedia.org/wikipedia/en/3/3e/IOS_8_Homescreen.png

Both iOS and Android dynamically change the appearance of the top bar - the transparency isn't permanent.

> As does OS X, KDE, Unity and Windows.

OS X doesn't use straight transparency (it's more the trademark frosted glass). Also, maximised windows aren't such a thing on OS X. The latest Unity release doesn't use transparency by default.

Either way, what other operating systems do isn't the primary factor here. I've already said that transparency without maximised windows makes sense (it makes the screen feel bigger and more expansive). However, it looks a mess when you have a maximised window, and doesn't help you to focus on window content.

You are right. It does look a mess when (In reply to Allan Day from comment #5)
> Either way, what other operating systems do isn't the primary factor here.
> I've already said that transparency without maximised windows makes sense
> (it makes the screen feel bigger and more expansive). However, it looks a
> mess when you have a maximised window, and doesn't help you to focus on
> window content.

I agree.

I propose that the top bar get translucency when non-maximized.

Adding the gnome-love keyword; I think this is a good 'first bug' candidate for newcomers.

There's also an extension that can be used as a starting point — without the complexity of configurability: https://extensions.gnome.org/extension/885/dynamic-top-bar/

(In reply to Emmanuele Bassi (:ebassi) from comment #7)
...
> There's also an extension that can be used as a starting point — without the
> complexity of configurability:
> https://extensions.gnome.org/extension/885/dynamic-top-bar/

Testing the extension, 0.1 transparency and button shadow off looks good to me.

Note that the overview should use the transparent version of the top bar.

(In reply to Allan Day from comment #8)
...
> Testing the extension, 0.1 transparency and button shadow off looks good to
> me.

That should be 0.2, not 0.1.

would love to see this myself, and also if i can ever understand jhbuild and gnome git i would be happy to start contributing...this would be a perfect starting place for someone like me

Hello,

DynamicTopBar extension developper here. Perhaps the easiest way to integrate this into the shell is to include the extension by default ?

(In reply to AMDG2 from comment #11)
> Perhaps the easiest way to integrate this into the shell is to include 
> the extension by default ?

No, unless we want to restrict it to classic mode, a feature/behavior shouldn't be an extension.

Let's try to be more explicit and give some actionable suggestion — this is likely my fault, I was being overly cryptic in comment 8.

Since we'd like this feature, one way to make it happen would be to take the DynamicTopBar extension, which already exists, and turn it into a patch for GNOME Shell, against the current master branch.

The behaviour should be automatic, and not configurable; the opacity of the top bar should be 0.2 during normal operations, and turned to 1.0 as soon as window on the current workspace is maximized.

If the user changes workspace to one that does not have a maximized window, the top bar should go back to 0.2 opacity; switching to a workspace that has a maximized window should also bring the opacity of the top bar to 1.0.

For the love of everything, make it fully customizable by themes if you do this. Something like a different selector of pseudo-class.

How should the top bar look like while we have only one half-tiled window?

(In reply to Alessandro Bono from comment #15)
> How should the top bar look like while we have only one half-tiled window?

Opaque and black, I'd say - a half-tiled window would be equivalent to a fully maximized one.

(In reply to Allan Day from comment #16)
> (In reply to Alessandro Bono from comment #15)
> > How should the top bar look like while we have only one half-tiled window?
> 
> Opaque and black, I'd say - a half-tiled window would be equivalent to a
> fully maximized one.

Not sure. If we disable translucency when only half the background is visible, what about a normal window that touches the top bar? It sounds confusing to me that a window that can take up 50% (tiled), 80% (unconstrained) or 100% (maximized) of the available area results in an opaque top bar for its smallest and biggest size, but a translucent one in between ...

What if the bar became fully opaque only if a window edge is adjacent to it, within a fuzzy area of (5 * scaling_factor) pixels?

(In reply to Emmanuele Bassi (:ebassi) from comment #18)
> What if the bar became fully opaque only if a window edge is adjacent to it,
> within a fuzzy area of (5 * scaling_factor) pixels?

Makes sense to me.

I can also imagine the top bar turning opaque as you push against the top edge of the display while dragging a window (and maybe the sides for half-tiling).

Created attachment 337326 [details] [review]
panel: Add solid class depending on context

Add solid style class when there is at least one
window near enough to the panel

based on https://github.com/endlessm/eos-desktop commits:
9dbce87613a2787db5570faf7973cfbbe6997876
be79058bd773bbec849789a769ac6bf20ce47ea4

Created attachment 337327 [details] [review]
gnome-shell: Apply new theme style

Set transparency by default and use full black as
a special case

Do you plan to animate transitions? This would probably want some pondering over too, as e.g. when maximizing windows (that doesn't have an animation yet afaik) or when going from the overview to an maximized window it would be weird, but it would be also very pleasant when unmaximizing.

Also on a light background I'm having quite some problem with readability and considerable eye strain under 0.4. A solution for this would be to include some logic like pantheon and using black text when needed, but this would require much more work.

This is looking good, Alessandro! Having tried the patches I have a few suggestions, based on discussion with other designers (and in line with Juraj's comments above):

 * There's a legibility issue when the panel is semi-transparent. It also looks a bit like it is disabled. Our suggestion to fix this is to make the text and icons lighter (possibly white).
 * The transition when the panel background colour changes is a bit abrupt. It would help to animate it.

Created attachment 339187 [details]
Screenshot : shadows applied to panel's cotent example

The Dynamic Panel Transparency extension [1] solves the panel's readability issue by making its content lighter (as Allan proposed) but also by adding shadows to it (see attached example). Think that's what elementary OS does either.

[1] https://extensions.gnome.org/extension/1011/dynamic-panel-transparency/

Do not think its overstatement to state that it would be good if someone reviewed the patch.

Created attachment 344205 [details] [review]
gnome-shell: Improve transparent style

I took a stab at improving the transparent style. This patch makes the text and icons white and also gives them a 50% black shadow. On hover etc. the shadow is increased to 100% black.

I also tried using transitions but for some reason they do not work for me (on GNOME 3.22). Actually, it seems that even the existing transitions do not work. Any advice regarding this?

I also noticed one minor glitch: when changing workspaces, the panel flickers between solid and transparent while the windows are sliding up/down (most likely because their top gets too close to the panel). Is there a way to "block" _updateSolidStyle during workspace switching?

Created attachment 344217 [details] [review]
panel: Do not change solid class during workspace switching

I managed to fix the flickering. Probably not the cleanest approach because it accesses the internal _switchData variable but it works for now.

(In reply to Michael Kuhn from comment #27)
> I also tried using transitions but for some reason they do not work for me

Indeed, transitions broke at some point. I filed a fix in bug 778145.

Created attachment 344969 [details] [review]
gnome-shell: Improve transparent style

After applying the patch from bug 778145, transitions now (almost) work. There is one remaining problem: The panel corner does not support transitions and the animation therefore looks a bit glitchy if you look closer.

Created attachment 350412 [details] [review]
_common: Apply new theme style

Set transparency by default and use full black as
a special case

Created attachment 350413 [details] [review]
panel: Add solid class depending on context

Add solid style class when there is at least one
window near enough to the panel. Update the css
style accordingly

based on https://github.com/endlessm/eos-desktop commits:
9dbce87613a2787db5570faf7973cfbbe6997876
be79058bd773bbec849789a769ac6bf20ce47ea4

(In reply to Michael Kuhn from comment #28)
> I also noticed one minor glitch: when changing workspaces, the panel
> flickers between solid and transparent while the windows are sliding up/down
> (most likely because their top gets too close to the panel). Is there a way
> to "block" _updateSolidStyle during workspace switching?

The flickering should be fixed. It is avoided by using the the actual (meta)windows coordinates instead of the ones of the actors. The coordinates of the actual windows don't change size/position during animations.

Let me know if you still see it.

Review of attachment 350412 [details] [review]:

The commit message isn't great, but meh - for what it's worth, I usually don't bother with coming up with a separate one for the gnome-shell-sass module, and just reuse the message from the corresponding gnome-shell commit ...

::: _common.scss
@@ +758,3 @@
+  background-color: rgba(0, 0, 0, 0.2);
+  /* transition from solid to transparent */
+  transition-duration: 500ms;

Any reason it's different than the reverse transition?
(Not saying it's wrong, just curious)

@@ +812,3 @@
     &:hover {
       color: lighten($fg_color, 10%);
+      text-shadow: 0px 0px 8px rgba(0, 0, 0, 1);

I expect the designers to tweak the styling, so I'll just state that this effect looks overly strong to me (using a light background; the default lock screen one is a good test case)

Review of attachment 350413 [details] [review]:

As mentioned on IRC: We probably want to give the window-list extension the same treatment, so it would be good to generalize the proximity tracking and move it to a separate class to avoid duplicating the code in the extension (and forgetting to update it). However (as also mentioned on IRC) I'm fine with landing the patch first and refactor it later for the extension, if you prefer.

In addition to the comments below, the commit message could also be better - it mentions obvious things like "update the CSS style", but omits any explanation of the change reasons.

(I usually borrow from designer comments in cases like this one, for example something like:

panel: Add transparency when free-floating

The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.

::: js/ui/panel.js
@@ +815,3 @@
         Main.sessionMode.connect('updated', Lang.bind(this, this._updatePanel));
+
+        this._trackedWindows = {};

Nowadays we have support for Map(), so we don't need to (ab)use objects as hash replacement.

@@ +824,3 @@
 
+    _onWindowActorAdded: function(container, metaWindowActor) {
+        let signalId = metaWindowActor.connect('allocation-changed', Lang.bind(this, this._updateSolidStyle));

It's a bit ugly to track window actors and then base the actual checks on windows, but I can see how tracking windows and using ::position-changed is a bit painful, so OK.

@@ +1032,3 @@
 
+    _updateSolidStyle: function() {
+        if (this.actor.has_style_pseudo_class('overview') || !Main.sessionMode.hasWindows) {

The canonical way to test whether we're in the overview is Main.overview.visible, which should be slightly safer - should we decide at one point that we don't need different overview styling and remove the style class, then this check is easy to overlook (although the effect should be visible enough to catch the bug quickly, so it doesn't match too much I guess)

@@ +1038,3 @@
+
+        /* Get all the visible windows that are in the primary monitor */
+        let windows = global.get_window_actors().filter(function(metaWindowActor) {

Maybe throw in a map(a => a.meta_window)? Otherwise windowActors would be a more appropriate name ...

@@ +1040,3 @@
+        let windows = global.get_window_actors().filter(function(metaWindowActor) {
+            let metaWindow = metaWindowActor.meta_window;
+            return metaWindowActor.visible &&

Maybe
  metaWindow.showing_on_its_workspace() &&
  metaWindow.located_on_workspace(activeWorkspace) &&
  ...?

Using the actor visibility means that the panel style transition starts at the end of the workspace switch animation, with the above both animations happen in parallel.

@@ +1045,3 @@
+        });
+
+        /* Check if at least a window is near enough to the panel */

IMHO "let isNearEnough = windows.some(...)" is a good example for how clean code and good variable naming make comments unnecessary. If you want to keep it anyway: "at least one window"

@@ +1046,3 @@
+
+        /* Check if at least a window is near enough to the panel */
+        let panelTop = this.actor.get_transformed_position()[1];

I prefer

    let [, panelTop] = this.actor.get_transformed_position();

over array indexes

@@ +1051,3 @@
+        let isNearEnough = windows.some(Lang.bind(this, function(metaWindowActor) {
+            let verticalPosition = metaWindowActor.meta_window.get_frame_rect().y;
+            return panelTop < verticalPosition &&

I'm not sure I agree with this bit - a particular ugly case:
 1) have a non-maximized window (so the panel is translucent)
 2) press <super>, click anywhere in the window and move the
    pointer to the top edge
 => the panel briefly becomes solid when the window top touches it,
    then gets translucent again as the window moves underneath it;
    when the pointer reaches the monitor edge, we get a tile preview
    with a translucent panel

@@ +1052,3 @@
+            let verticalPosition = metaWindowActor.meta_window.get_frame_rect().y;
+            return panelTop < verticalPosition &&
+                   verticalPosition < panelBottom + 5*scale;

Style nit: spaces around operators

@@ +1055,3 @@
+        }));
+
+        if (isNearEnough) {

Style nit: Omit braces where all blocks are single lines

(In reply to Florian Müllner from comment #35)
> Review of attachment 350412 [details] [review] [review]:
> ::: _common.scss
> @@ +758,3 @@
> +  background-color: rgba(0, 0, 0, 0.2);
> +  /* transition from solid to transparent */
> +  transition-duration: 500ms;
> 
> Any reason it's different than the reverse transition?
> (Not saying it's wrong, just curious)

Because when we have just maximized a window it looks ugly to see the maximized window with the topbar still transparent, thus we want to make the topbar solid quickly. On the other hand, there is no hurry when a window is unmaximized, therefore we can take more time for the transition (since it is nice).

This is the reasoning behind it, feel free to drop it if the designers don't approve it.

(In reply to Florian Müllner from comment #36)
> Review of attachment 350413 [details] [review] [review]:
> @@ +1032,3 @@
>  
> +    _updateSolidStyle: function() {
> +        if (this.actor.has_style_pseudo_class('overview') ||
> !Main.sessionMode.hasWindows) {
> 
> The canonical way to test whether we're in the overview is
> Main.overview.visible, which should be slightly safer - should we decide at
> one point that we don't need different overview styling and remove the style
> class, then this check is easy to overlook (although the effect should be
> visible enough to catch the bug quickly, so it doesn't match too much I
> guess)

I opted to use this.actor.has_style_pseudo_class('overview') because when Main.overview::hiding is emitted Main.overview.visible is still true. This causes the function _updateSolidStyle() to return at the first check. Thus, the 'solid' class is never added. On the other hand, in js/ui/panel.js when Main.overview::hiding is emitted, we remove the 'overview' class just before calling _updateSolidStyle().

Created attachment 351618 [details] [review]
_common: Add transparency when free-floating

The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.

Created attachment 351620 [details] [review]
panel: Add transparency when free-floating

The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.

based on https://github.com/endlessm/eos-desktop commits:
9dbce87613a2787db5570faf7973cfbbe6997876
be79058bd773bbec849789a769ac6bf20ce47ea4

Review of attachment 351618 [details] [review]:

(In reply to Alessandro Bono from comment #37)
> This is the reasoning behind it, feel free to drop it if the designers don't
> approve it.

I expect the designers to tweak stuff before or after landing the patches, from my point of view it's fine

(In reply to Alessandro Bono from comment #38)
> I opted to use this.actor.has_style_pseudo_class('overview') because when
> Main.overview::hiding is emitted Main.overview.visible is still true. This
> causes the function _updateSolidStyle() to return at the first check. Thus,
> the 'solid' class is never added. On the other hand, in js/ui/panel.js when
> Main.overview::hiding is emitted, we remove the 'overview' class just before
> calling _updateSolidStyle().

OK, makes sense.

Review of attachment 351620 [details] [review]:

Nice work! We'll still have to figure out what to do about the window-list and panel corners, but neither is something we should block on IMHO.

So apart from the window type question below, this is ready to go IMHO (although the designers may also want to chime in on the style). One nit on the commit message: If you want to keep the attribution (let's face it, the last iteration has very little to do with the referenced commits), "based on" should be capitalized.

::: js/ui/panel.js
@@ +1040,3 @@
+        /* Get all the windows in the active workspace that are in the primary monitor and visible */
+        let activeWorkspace = global.screen.get_active_workspace();
+        let windows = activeWorkspace.list_windows().filter(function(metaWindow) {

Oh, this is much nicer than map()+located_on_workspace()

@@ +1043,3 @@
+            return metaWindow.is_on_primary_monitor() &&
+                   metaWindow.showing_on_its_workspace() &&
+                   metaWindow.get_window_type() == Meta.WindowType.NORMAL;

Mmh, looks like we want to include at least DIALOG and MODAL_DIALOG here as well? Or maybe != Meta.WindowType.DESKTOP?

(list_windows() doesn't include override-redirect windows, so all menu types are already handled correctly)

(In reply to Alessandro Bono from comment #37)
> Because when we have just maximized a window it looks ugly to see the
> maximized window with the topbar still transparent, thus we want to make the
> topbar solid quickly. On the other hand, there is no hurry when a window is
> unmaximized, therefore we can take more time for the transition (since it is
> nice).

Should there be an animation at all if there’s is no animation for maximising the window? It’s going to look weird.

(In reply to Juraj Fiala from comment #44)
> (In reply to Alessandro Bono from comment #37)
> > Because when we have just maximized a window it looks ugly to see the
> > maximized window with the topbar still transparent, thus we want to make the
> > topbar solid quickly. On the other hand, there is no hurry when a window is
> > unmaximized, therefore we can take more time for the transition (since it is
> > nice).
> 
> Should there be an animation at all if there’s is no animation for
> maximising the window? It’s going to look weird.

I don't think that it looks that weird, and in the long run maybe we will have an animation for the (un)maximize action. Furthermore, currently (in the patch) there is no way to distinguish how the window approaches the topbar (by a drag operation or by a maximize action) and I doubt that it worth to try to separate the cases.

(In reply to Alessandro Bono from comment #45)
> I don't think that it looks that weird, and in the long run maybe we will
> have an animation for the (un)maximize action. Furthermore, [...] I doubt that > it is worth to try to separate the cases.

I agree.

Created attachment 351711 [details] [review]
_common: Add transparency when free-floating

The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.

Fix missing hovering effect when the topbar is black

Created attachment 351712 [details] [review]
panel: Add transparency when free-floating

The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.

Comment on attachment 351711 [details] [review]
_common: Add transparency when free-floating

Attachment 351711 [details] pushed as 4c36117 - _common: Add transparency when free-floating

Attachment 351712 [details] pushed as 447bf55 - panel: Add transparency when free-floating

(In reply to Alessandro Bono from comment #45)
> I don't think that it looks that weird, and in the long run maybe we will
> have an animation for the (un)maximize action.
It would be great to have maximize and unmaximize animations like full screening :) There is a bug 766685 about that idea.

What happens with a busy background? I have seen what (I believe is) a screenshot of the current state of this, and it seems to be simple opacity. With a busy background (e.g. as many photos are), plain opacity will make top bar text difficult to read in many cases.

Apple and Microsoft have both addressed this at various points in their respective OSes with blur because they recognised this issue.

(In reply to Stephen from comment #52)
> What happens with a busy background? I have seen what (I believe is) a
> screenshot of the current state of this, and it seems to be simple opacity.
> With a busy background (e.g. as many photos are), plain opacity will make
> top bar text difficult to read in many cases.
> 
> Apple and Microsoft have both addressed this at various points in their
> respective OSes with blur because they recognised this issue.

Can you please file a new bug against gnome-shell if it is actually a problem after testing?

At the level of transparency it has in the screencasts I have seen, it will be a problem - when Compiz was a new thing back in the day, there were one or more plugins that allowed setting transparency without blur, and they were not useable with anything but abstract/blurry backgrounds for the same reason.

If the issue has already been considered/tested and/or there's a reason this implementation is materially different, my apologies, but if not, it's a bit worrying that what is essentially bling is being introduced without testing a range of backgrounds first.

If there's a fairly easy-to-set-up way of testing the current implementation (e.g. live ISO snapshot) somewhere, I'm happy to do that to confirm the issue specifically with Shell's top bar.