Corrupted tray icons after restarting of Awesome #1720
Comments
|
I know that this isn't helping anyone, but I'll still mention it: Awesome only places the tray icons, it does not draw them.
As far as I know, Dropbox uses Qt. Does Telegram do, too? What is creating the third icon, which apparently does not have this problem? |
|
Yes, Telegram uses Qt too. The third app is Slack, I don't know what toolkit it uses. Okey, I get it, but what I don't understand is how other window managers and desktop environments properly shows its tray icons? |
|
It somehow depends on a tray width. Awesome shows tray icons normally if I set tray.forced_width. |
|
I believe the reason for the corrupted tray icons is that awesome wm doesn't support or advertise support for alpha channels for tray icons. Qt checks for this, and when it isn't supported, it tries to grab the background behind the icons and do the compositing itself. And I guess when restarting awesome, it grabs the background too early or something to that effect. |
|
@sw9 Yup, that's correct. However, the systray spec (I guess) means to have systray icons in a flickering manner: You first clear the background (this can be done without actually knowing what the background is) and then draw your icon ontop. This kind of drawing is sadly incompatible with anything modern. I guess Gtk works around its drawing model here while Qt tries to force things in the other direction... And no, I don't want to turn awesome into a compositing manager. Not even for the systray. |
|
Well then, wouldn't the smart way to fix this be to somehow delay QT grabbing stuff? |
|
@spheenik Yes, now I understand why I had to add a sleep 3s before every (QT) application (such as |
|
I had the same problem, installed https://github.com/TomaszGasior/gtk3-mushrooms and now it works great :) |
This helped in my case as well. |
|
For tracking purposes:
|
Did not help in my case, i use |
|
According to https://gitlab.gnome.org/GNOME/gtk/commit/e3a1593a0984cc0156ec1892a46af8f256a64878 this bug should be fixed with GTK 3.24.3 . |
|
Can someone explain why if this is related to GTK rather than Awesome, it does not happen with XFCE, Gnome, KDE, etc? |
|
TBH i have seen this bug in i3 also, i guess it depends on the tray, for me
nm-applet tray icon misbehaves in both i3 and awesome.
…On Fri, Mar 15, 2019, 03:36 Benjamín Ariel Nava Martínez < ***@***.***> wrote:
Can someone explain why if this is related to GTK rather than Awesome, it
does not happen with XFCE, Gnome, KDE, etc?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1720 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIeV7uEvj1vQucWm_y0Yg_vjPE0JjLAHks5vWsfogaJpZM4M7m0S>
.
|
|
Hmmm... seems that setting a forced width helps a bit
And this happens if you hide → unhide the wibar
The background seems to leak through. setting the background to a solid color (e.g "#ff0000"), "alpha" or anything, actually, doesn't help at all... |
If you want me to guess: AwesomeWM is not a a WM+compositing manager, but only a WM. Thus, we do how tray icons where always done. With the invention of compositing and the compositing X11 extension, the systray specification was changed so that one can also use compositing for systray icons. With that, systray icons can just do "this is a transparent background" instead of having the traditional thing of getting the real background and drawing ontop of that. Now, changes in toolkits could break the "traditional systray icon stuff" and DE users would not notice. The big guess here is now that Gnome, KDE (these two I'm pretty sure about), and XFCE (dunno about this one) use this "compositing stuff" while AwesomeWM does not. Does this answer your question? Systray icon spec: https://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
|
|
So in principle if we use a composite manage like compton with awesome,
that should fix the problem?
…On Fri, Mar 15, 2019, 12:51 Uli Schlachter ***@***.***> wrote:
Can someone explain why if this is related to GTK rather than Awesome, it
does not happen with XFCE, Gnome, KDE, etc?
If you want me to guess:
AwesomeWM is not a a WM+compositing manager, but only a WM. Thus, we do
how tray icons where always done. With the invention of compositing and the
compositing X11 extension, the systray specification was changed so that
one can also use compositing for systray icons. With that, systray icons
can just do "this is a transparent background" instead of having the
traditional thing of getting the real background and drawing ontop of that.
Now, changes in toolkits could break the "traditional systray icon stuff"
and DE users would not notice.
The big guess here is now that Gnome, KDE (these two I'm pretty sure
about), and XFCE (dunno about this one) use this "compositing stuff" while
AwesomeWM does not.
Does this answer your question?
Systray icon spec:
https://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
_NET_SYSTEM_TRAY_VISUAL is the relevant property for compositioning:
If this property is set to a visual with an alpha channel, the tray
manager must use the Composite extension to composite the icon against the
background using PictOpOver.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1720 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIeV7jaco7oxWYD44279aPJzdvNugaigks5vW0oJgaJpZM4M7m0S>
.
|
|
Nope, I'm using compton, actually
01:25, 15 de marzo de 2019, Anjan Nath <notifications@github.com>:So in principle if we use a composite manage like compton with awesome,
that should fix the problem?
On Fri, Mar 15, 2019, 12:51 Uli Schlachter ***@***.***> wrote:
Can someone explain why if this is related to GTK rather than Awesome, it
does not happen with XFCE, Gnome, KDE, etc?
If you want me to guess:
AwesomeWM is not a a WM+compositing manager, but only a WM. Thus, we do
how tray icons where always done. With the invention of compositing and the
compositing X11 extension, the systray specification was changed so that
one can also use compositing for systray icons. With that, systray icons
can just do "this is a transparent background" instead of having the
traditional thing of getting the real background and drawing ontop of that.
Now, changes in toolkits could break the "traditional systray icon stuff"
and DE users would not notice.
The big guess here is now that Gnome, KDE (these two I'm pretty sure
about), and XFCE (dunno about this one) use this "compositing stuff" while
AwesomeWM does not.
Does this answer your question?
Systray icon spec:
https://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
_NET_SYSTEM_TRAY_VISUAL is the relevant property for compositioning:
If this property is set to a visual with an alpha channel, the tray
manager must use the Composite extension to composite the icon against the
background using PictOpOver.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1720 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIeV7jaco7oxWYD44279aPJzdvNugaigks5vW0oJgaJpZM4M7m0S>
.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
…-- Sent from Yandex.Mail for mobile
|
In theory, that would be possible. In practice, it is not, because the spec does not allow things like "I previously did not support transparency, but now I suddenly do" (= compositing manager was just started). Thus, AwesomeWM always has to announce "I do not support tray icon transparency". And if the spec would allow that, no one would implement it correctly anyway, because no one would test this code... |
|
What would it take to change the spec to fix this? What are XFCE, MATE, Gnome, etc., doing right, then? I might take a look into this but could someone put me up to speed in this matter? |
|
+1
…On Sat, Mar 16, 2019, 00:03 Benjamín Ariel Nava Martínez < ***@***.***> wrote:
What would it take to change the spec to fix this? What are XFCE, MATE,
Gnome, etc., doing right, then? I might take a look into this but could
someone put me up to speed in this matter?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1720 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIeV7uuu9qEQZ_F_ET8qyNWpa70mE2vzks5vW-dcgaJpZM4M7m0S>
.
|
A time machine to change the spec before it is finalised (and some good arguments to convince people that the added complexity is worth it). I doubt a lot that the powers that be are interested in changes to the spec. And I doubt more that toolkits authors would update their code due to changes to the spec. Everyone rather focuses on wayland. (GTK 4 even dropped support for tray icons, didn't they?)
They have built-in compositing managers and so there is no problem in saying "transparency support is available", because that support cannot suddenly go away due to Anyway, to come back to something a bit more productive than time machines: Which version of stuff still has problems? I thought the regressions in GTK where fixed quickly and Qt does some drawing through the RENDER extension these days to make transparency work properly (git says: since version |
I doubt this issue would mean an entire rewrite of the spec, but I'd have to take a look though... I'm no expert but I also don't think that forking the project and adding a quick fix just for the people that are interested in it would have to have the attention of the "powers that be". I want to be clear: I'm not asking for anyone to do it, I just want to know if hacking it a bit would at least be possible.
True but what'd be problem of making a little switch that lets people compile or start awesome with the "I have transparency support" flag always on, expecting users have a compositing manager e.g. compton? Why do icons still work when switching off window compositing (at least with XFCE)? |
Oh, wow. I'm stupid. One cannot change the "supports transparency"-flag of an already-running systray. However, one can just get rid of the systray and set up a new one: |
|
Here's some real transparency in a systray icon (running with compton). Note that we just get whatever-is-behind-the-wibar as background here and not the wibar's content. diff --git a/awesomerc.lua b/awesomerc.lua
index fa584b8a8..9f9e31b73 100644
--- a/awesomerc.lua
+++ b/awesomerc.lua
@@ -216,15 +216,16 @@ awful.screen.connect_for_each_screen(function(s)
-- @DOC_SETUP_WIDGETS@
-- Add widgets to the wibox
+ s.mywibox.height = 30
s.mywibox:setup {
layout = wibox.layout.align.horizontal,
{ -- Left widgets
layout = wibox.layout.fixed.horizontal,
mylauncher,
- s.mytaglist,
+ --s.mytaglist,
s.mypromptbox,
},
- s.mytasklist, -- Middle widget
+ nil, --s.mytasklist, -- Middle widget
{ -- Right widgets
layout = wibox.layout.fixed.horizontal,
mykeyboardlayout,
@@ -233,6 +234,12 @@ awful.screen.connect_for_each_screen(function(s)
s.mylayoutbox,
},
}
+ s.mywibox:set_bg(beautiful.bg_normal .. '80')
+ s.mywibox.ontop = true
+ gears.timer.start_new(1, function()
+ awesome.systray(s.mywibox.drawin, 0, 0, 20, false, '#ff0000', false, 0)
+ return true
+ end)
end)
-- }}}
diff --git a/common/atoms.list b/common/atoms.list
index 9cf41336e..2061fb743 100644
--- a/common/atoms.list
+++ b/common/atoms.list
@@ -57,6 +57,7 @@ ESETROOT_PMAP_ID
WM_STATE
_NET_WM_WINDOW_OPACITY
_NET_SYSTEM_TRAY_ORIENTATION
+_NET_SYSTEM_TRAY_VISUAL
WM_CHANGE_STATE
WM_WINDOW_ROLE
WM_CLIENT_LEADER
diff --git a/systray.c b/systray.c
index c3919ee3b..beca7b23f 100644
--- a/systray.c
+++ b/systray.c
@@ -44,15 +44,16 @@ systray_init(void)
globalconf.systray.window = xcb_generate_id(globalconf.connection);
globalconf.systray.background_pixel = xscreen->black_pixel;
- xcb_create_window(globalconf.connection, xscreen->root_depth,
+ xcb_create_window(globalconf.connection, globalconf.default_depth,
globalconf.systray.window,
xscreen->root,
-1, -1, 1, 1, 0,
- XCB_COPY_FROM_PARENT, xscreen->root_visual,
- XCB_CW_BACK_PIXEL | XCB_CW_EVENT_MASK, (const uint32_t [])
- { xscreen->black_pixel, XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT });
+ XCB_COPY_FROM_PARENT, globalconf.visual->visual_id,
+ XCB_CW_BACK_PIXEL | XCB_CW_BORDER_PIXEL | XCB_CW_EVENT_MASK | XCB_CW_COLORMAP, (const uint32_t [])
+ { xscreen->black_pixel, xscreen->black_pixel, XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT, globalconf.default_cmap });
xwindow_set_class_instance(globalconf.systray.window);
xwindow_set_name_static(globalconf.systray.window, "Awesome systray window");
+ xcb_change_property(globalconf.connection, XCB_PROP_MODE_REPLACE, globalconf.systray.window, _NET_SYSTEM_TRAY_VISUAL, XCB_ATOM_VISUALID, 32, 1, (uint32_t[]) { globalconf.visual->visual_id });
atom_name = xcb_atom_name_by_screen("_NET_SYSTEM_TRAY", globalconf.default_screen);
if(!atom_name)
|
|
Another "Argh": xfce-panel does indeed composite the tray icons itself without any interaction with the compositing manager: https://git.xfce.org/xfce/xfce4-panel/tree/plugins/systray/systray.c?id=5ceb4057a2e4c6136b7884ad649dd95f1c71aabf#n715 |
|
Just want to report my case: I use Manjaro, AwesomeWM within XFCE. The tray is in xfce-panel (I disabled it from AwesomeWM), but still have the problems with rendering (take a look into nm-applet icon, dropbox etc). It doesn't appear in xfwm though. I wonder how AwesomeWM still affects on it, if assumably xfce-panel does composition for themself. Does it report that tray composition is enable or it's still the awesome's job? |
|
Hey, I'd like to report my case as well. I've had this issue back when I used Arch Linux but I've moved to NixOS and I don't experience this issue anymore. I'm using a normal AwesomeWM installation without XFCE or Gnome. I've also experienced back then #2606 and I don't experience it anymore. Long live reproducible builds! |
|
So are there any tl;dr work arounds or patches to apply in order to remedy this issue? I've been sick of having to see corrupted tray icons for years now. |
|
Yes: i3 |
|
As already noted by others in this issue i3 has the same problem too: i3/i3#3335 (comment) |
|
I'm not sure what was changed, but for me on Archlinux, xfce4 with AwesomeWM, tray icons stopped corrupting (tray is in xfce4-panel for me). I haven't touched my config for a while. It looks like something was fixed whether on GTK side or Xfce or AwesomeWM.
|
|
Can you post the versions you use?
Thanks!
Am 10. November 2019 10:13:32 MEZ schrieb Sergey Kukunin <notifications@github.com>:
…I'm not sure what was changed, but for me on Archlinux, xfce4 with
AwesomeWM, tray icons stopped corrupting (tray is in xfce4-panel for
me). I haven't touched my config for a while.
It looks like something was fixed whether on GTK side or Xfce or
AwesomeWM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1720 (comment)
|
|
I have Manjaro (based on Archlinux):
I'm sorry, I'm not an expert so I might have not provided all related versions. I'll happily provide extra info, just tell me what. P.S. Noticed that gtk3 is patched: https://github.com/krumelmonster/gtk3-mushrooms |
|
Just to add myself to the list -> seems fixed in current Arch (I could normally easily reproduce by just restarting Awesome once - doing so now the icons are still intact...) |
|
i still can reproduce on the latest arch install just make tray hide/unhide several times and background will scramble underneath Qt icons (ie literally the problem with Dropbox background from the first post is still reproducible for me) |
|
Might there be some way to automate resizing the tray when an icon is added or removed? |
|
Using NixOS 22.11 here with xfce4 and I also have the same issue than everyone else in this thread. This is quite annoying. At least I'm glad that I found the right thread about this bug. EDIT: I found a way to solve this issue. Instead of running the default command which is |
Output of
awesome --version:awesome v4.1 (Technologic)
• Compiled against Lua 5.1.5 (running with Lua 5.1)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.4
• LGI version: 0.9.0
How to reproduce the issue:
Actual result:
Expected result:
The text was updated successfully, but these errors were encountered: