wibox.widget.systray doesn't support pseudo-transparency

[flyboy14]

Hello!
I found out that there is built-in pseudo-transparency for wiboxes in awesome 3.1 and newer.
It can be enabled by appending 2 hexadecimal digits to the colors in theme file:

theme.bg_normal = #000000AA --"AA" is the transparency value. 

It works good for wiboxes and all widgets, but but unortunately it does'nt work for wibox.widget.systray().
For example, this: (in theme.lua)

theme.bg_systray = "#121212AA"

works exactly like this:

theme.bg_systray = "#121212"

I wonder if there's a way to make systray transparent due to match my system theme.
Screenshots included.


Thanks!

[blueyed]

Might be related to #359.

[flyboy14]

No. It's not about redrawing. When I restart awesome with value #ffffff systray becomes white and with value #121212 it becomes dark grey. But pseudo-transparency that works with awful.menu and awful.wibox doesn't seem to work with systray widget

[psychon]

Same issue in old tracker: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=513

[timroes]

Reading through the ticket history also in the old issue tracker, I am not sure if my systray issue is related to that. Even without any transparency background colors and drawing is pretty broken (but still looks like it could be related):

I actually set the background color of the systray to #FF00FF. Only the volume icon seem to work well. The synology cloud station icon will always draw on black background. The dropbox icon (as can be seen in the picture) draws over a copy of one of the other icons.

Since this behavior seem to stick to the icons whenever they appear it might also be an issue in dropbox/synologies software. Has anyone similar issues with their systray.

Also, is the issue with the pseudo transparency something, that is planned to be fixed?

[psychon]

@timroes That might very well be a Qt bug and the "draws over a copy of one of the other icons" might be one of my attempts at fixing this bug in Qt.

And for fixing pseudo transparency with the systray: If you tell me how, I could look into that. So far I haven't seen/had any sane ideas.

[Determinant]

I'm also experiencing the same problem. Any update on this bug?

[psychon]

@Determinant No

[ervasive]

And for fixing pseudo transparency with the systray: If you tell me how, I could look into that. So far I haven't seen/had any sane ideas.

I have zero clues of how systray is implemented or what can be done regarding this issue but tint2 handles tray icons pretty well in my experience, maybe some ideas could be gathered from there. Just my 5 cents.

Also, currently there is not much info about this limitation in the docs besides the following:

The color (string like “#ff0000” only) 

Maybe it could be stated more explicitly there as well.

[Elv13]

but tint2 handles tray icons pretty well in my experience,

The issue has never been that it's impossible to implement. The issue is that the protocol wasn't designed for that in mind and the complexity associated with making it work is not worth it from a maintainer point of view. KDE (both v4 and v5) at first refused to implement it but eventually gave up that stance due to user pressure (and regret it). Gnome (3) also refused to do the necessary hacks (at least by default).

[ervasive]

Oh, I wasn't aware of that.
If I understand correctly the issue is related to XEMBED based system tray specification and occurs all over the place:
Airblader/i3#90
polybar/polybar#854
taffybar/taffybar#177

Here is some explanation:
Airblader/i3#90 (comment)
Airblader/i3#90 (comment)

[actionless]

my workaround is to have tray which is hiding on click/hotkey

for sure won't work for anyone who really need to observe some status info from tray all the time