Re: [i3] Tray Icons Disappearing on i3bar

  • From: "BRAGA, Bruno" <bruno.braga@xxxxxxxxx>
  • To: "Discussions/Questions about the i3 window manager" <i3-discuss@xxxxxxxxxxxxx>
  • Date: Tue, 3 Jul 2012 20:20:44 +1000

FYI.

I have created the ticket for this issue:
http://bugs.i3wm.org/report/ticket/745

Regards,

--
*Braga, Bruno*
www.brunobraga.net
bruno.braga@xxxxxxxxx


On Fri, Jun 29, 2012 at 7:26 PM, Michael Stapelberg <michael@xxxxxxxx>wrote:

Hi Fernando,

Quoting Fernando Lemos (2012-06-29 03:37:13)
When i3 is restarted, so is i3bar. Looks like when i3bar quits, its
window is destroyed and the embedded windows receive a BadWindow error
[1]. Seems to be a design issue in XEmbed itself:
They shouldn’t, though. Have a look at the code. When i3bar receives an
EOF (or does it not receive an EOF in that case? maybe we should make it
restart-aware) it first properly kills all embedded tray icons.

What happens here, I guess, is that some clients may try to create the
tray icon again, while others may not. Or maybe they do, but i3bar
wasn't up by the time they retry (I'm guessing here, I really didn't
read XEmbed).
In case they don’t retry, they are violating the spec. Also, the
embedder can be down for an arbitrary amount of time. The tray
application is supposed to deal with that. And at least nm-applet does
(so do all GTK-based ones probably). Note however that when the embedder
does not properly kill the tray clients, they may not retry at all. So
this is probably what’s happening here (as you described above).

XEmbed also says that "the protocol ends" when the embedded window is
reparented to the root window [2]. So I don't know much about X, but
maybe reparenting the embedded windows to the root window before
terminating would be a solution? I'm not sure how the clients are
supposed to react, though.
As I said, we should be doing that :).

What puzzles me is that you guys say it also happens when returning
from suspend... I have no idea why that is, I always thought suspend
was (mostly) transparent to applications?
Yes, it definitely should be transparent to applications. My guess is
that for some reason, a monitor reconfiguration event is sent and i3
restarts i3bar because of that. However, that’s a different code path
than the i3 restart, so it’s quite a mystery to me currently.

Best regards,
Michael

Other related posts: