0

I have this convoluted setup with three monitors, on a single X screen, driven by awesome wm 4.2.

Some applications (Pale Moon, XTerm, QJackCtl to name a few) draw their tooltips and context menus disregarding the actual monitor setup I have, probably assuming there is only one large rectangular monitor. So some tooltips are spanning screens, and to my frustration, some are even partly drawn outside the actual monitors. See the award-winning sketch illustrating the issue below:

Multi-monitor setup

Is there a way to make awesome force an application to believe the whole desktop spans only the monitor it is displayed in, or any other way to avoid that nasty off-screen behavior?

If it makes any difference, I don't use any tiling features, I run all my windows as floating ones.

Patrice Levesque
  • 2,079
  • 17
  • 16
  • Sorry, but as far as I know, there is no way to do this. I think either GTK or Qt (not sure) has some code where it queries the size of the monitors and uses the for tooltip placement. Since you say QJackCtl is affected, I guess that GTK does this. But the WM cannot do anything about this since it is not involved in tooltips at all. Also: XTerm can do tooltips?? – Uli Schlachter Feb 04 '18 at 09:36
  • @UliSchlachter Both tooltips and context menus have that nasty behavior; XTerm has context menus (activated by Ctrl-click) that are drawn offscreen. – Patrice Levesque Feb 04 '18 at 14:12
  • 1
    Oh wow, I really did not know that Xterm has this. Anyway, Xterm is not aware of RandR and your individual monitors. It (actually, the widget library it uses) just takes their bounding box and ensures that its menu is somewhere in there. The relevant code is here: https://sources.debian.org/src/libxaw3dxft/1.6.2e-1/src/SimpleMenu.c/?hl=1155#L1248-L1262 The WidthOfScreen / and HeightOfScreen here is what /usr/bin/xrandr shows you in its first output line under "current": It is the bounding boxof your monitors (basically). – Uli Schlachter Feb 05 '18 at 15:10

0 Answers0