Yaru: GNOME Shell 3.31.90 top bar always translucent

[jbicha]

• yaru version 19.04

gnome-shell 3.31.90 is now in disco-proposed so I installed it.

GNOME Shell turned off the top-bar translucency feature and made it always opaque. This works in the GNOME session but in the Ubuntu session, the top bar is now always translucent even if an app is maximized.

I suspect the Yaru GNOME Shell theme will need to be updated to fix this issue.

[Feichtmeier]

@clobrano I would like to diverge branches now. I am using 18.04 and I see no reason to apply a perma opaque panel to the 18.04 snap :man_shrugging:
Do you agree?

[clobrano]

I ~don't~ do :D, but we must pay attention to the build scripts

[Feichtmeier]

I have no idea how they work but there are three options:

A) use master for edge and sometimes promote it to stable and use a different branch for disco
B) use master for disco and use a different branch for edge snap and sometimes promote it to stable
C) don't diverge branches but fix the panel for now, wait for the disco .Deb release and change it back right after

I would prefer A) because it looks like the panel is already being made transparent again right in the next cycle so we could make a .Deb release out of a certain branch only for disco and keep fully business
Or C) but tell people using the snap that it is only a temp change

But maybe that's bullshit but I can't tell you because I have no idea how that works
Maybe @didrocks could a share an idea? :)

[clobrano]

As far as I remember, .snap package is made out of the master branch, so option A should be actually safer. I believe that .deb can be easily made by any branch, but I can double check on IRC today.

Of course, diverging now means that every fix should be backported between the two branches, since they only diverge (for now) because of this little thing about panel :sob:

[Feichtmeier]

Backporting sucks, you are right.
That's why
C) could also be an option

Edit: Hm A) is basically C) because those non lts theme packages are never updated again after release :)

[clobrano]

Backporting sucks, you are right.
That's why
C) could also be an option

Right. So, I'll look into the issue and see what we can do.

[clobrano]

How unlucky! Transparency was implemented (on CSS) with a .solid class, which they removed. If it had been implemented with a .transparent class instead, we could have kept the same implementation and the shell would have just ignored the .transparent settings.

[clobrano]

This is not due to the panel code, but it's close and I don't want to open a ticket on dashtodock yet.
The dock does not get the custom color in .opaque class, while the color in .transparent class is correct (note that the two colors will be the same)

[clobrano]

@jbicha, have you noticed if, in disco, the dock is full black when a window is maximized?

[jbicha]

I am running gnome-shell 3.31.90 and I'm still using the Yaru version published as a disco .deb. Yes, the dock is black right now.

[clobrano]

Thanks a lot for double checking.
So, it is actually a possible bug in current dash to dock more than the
effect of the fix to this bug.
Not sure how to tackle this, is it too early to open a bug on dashtodock
repo?

On Thu, 28 Feb 2019 at 12:02, Jeremy Bicha [e-mail] wrote:

I am running gnome-shell 3.31.90 and I'm still using the Yaru version
published as a disco .deb. Yes, the dock is black right now.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/ubuntu/yaru/issues/1201#issuecomment-468231335, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACwAHo7MH6PHF4BaRnLo1uWYVpOuPCsKks5vR7c4gaJpZM4bIMrp
.

[jbicha]

is it too early

No.

Maybe you could specify the color you want in the Yaru theme instead of in Dash-to-Dock.

[clobrano]

Maybe you could specify the color you want in the Yaru theme instead of in Dash-to-Dock.

We do it already. This looks a regression, since in 18.10 it works fine