0

I have a weird effect in ZOOM which only appears for TCL/TK windows.

Ubuntu 18.04, GNOME window manager. ZOOM version 5.10.3 (2778) (relatively new, I was forced to do an update, the problem is also new). TCL/TK 8.6.

  1. I start a ZOOM session and share a "portion of screen" (Share - Advanced).
  2. I run wish from the command line. I move the wish window into the shared screen portion.
  3. For the client users of the ZOOM session, the wish window is visible if it has the focus.
  4. When I move the focus to another window, e.g. a terminal, outside the shared screen portion, the clients only see a black region somewhat larger than the wish window (instead of the wish window).
  5. When I move the focus to a window, e.g. a terminal, which is at least partly inside the shared screen portion, the wish window stays visible.
  6. If I share the entire screen in ZOOM (which is not what I want for my purposes, though), the wish window stays visible.

This is so weird, I don't even have the slightest idea what is going on. What is special about TCL/TK windows that they go black in ZOOM, but only under these circumstances?

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
Ralf
  • 1,203
  • 1
  • 11
  • 20
  • Are you running X or Wayland? – slebetman Apr 25 '22 at 10:58
  • @slebetman: `echo $XDG_SESSION_TYPE` says `x11`. – Ralf Apr 25 '22 at 11:03
  • I just noticed that the problem disappears if also the ZOOM client is updated (now I'm at ZOOM 5.10.4 for both the zoom session and the zoom client, running on different machines). But still: what's so special about TK windows? – Ralf Apr 25 '22 at 11:26
  • 1
    Tk was implemented at a very low level not on top of more popular toolkits like GTK or Qt. I was wondering if there were any incompatibilities with newer display managers like Wayland. But if you are using X11 then it's a bit weird since Tk has been stable since the 1980s – slebetman Apr 25 '22 at 11:55
  • 1
    Sounds like it's some sort of unexpected event pattern that Tk is ignoring (and the ignoring of that is something which Zoom interprets as "go black"). Very odd, and possibly a Zoom bug (given that updating the Zoom client fixed it, and they encourage keeping up to date). Alas, given that a newer version of Zoom fixes it, there's not much anyone's going to be able to do to hunt this down. Even if it was more easily reproducible, it'd *still* be very difficult to trace. (Event handling bugs always are horrible; there's just so many events behind the scenes!) – Donal Fellows Apr 25 '22 at 13:06
  • Also, the above is a Wild Assed Guess. I could definitely be wrong. – Donal Fellows Apr 25 '22 at 13:07
  • Unfortunately, the problem is still there. I'm not sure why it had seemed to disappear after an update of the ZOOM client, but another test showed that it persists. – Ralf Apr 25 '22 at 14:29

0 Answers0