Waybar: Tooltips / Menus not correctly positioned

[Alexays]

Need to implement XDG Popup

[cjbassi]

The tooltips show up in the middle of the screen for me, but they should appear where my mouse is. Is that what this issue is describing?

[rbnis]

One interesting find I just made is, that everytime aa tooltip is displayed, waybar gets a new window/container id from sway.
I'm not sure if that helps finding the problem.

[matt-snider]

@Alexays I'm also wondering if this refers to the same issue commented above by @cjbassi. Could you please confirm whether this is the case?

[Alexays]

@matt-snider Yeah that's the part of the issue!

[Alexays]

I have debugged to know where it comes from, and it's not a waybar or sway/wlroots fault, but from an update of gtk3

[matt-snider]

@Alexays Thanks for the info. Is there any upstream gtk3 issue we can watch?

[Alexays]

Surely https://github.com/GNOME/gtk/commit/a73f961e657014dba173ee121f62b53e4a02391c
So we need to implement xdg popup

[JadeMaveric]

One interesting find I just made is, that everytime aa tooltip is displayed, waybar gets a new window/container id from sway.
I'm not sure if that helps finding the problem.

One possible workaround I can think of is to use the for_window [class=window-class] move <left|right|down|up> [<px> px] to position the windows correctly.

Another variant of the command allows the window to be positioned at the cursor. Here's the i3 manual entry https://i3wm.org/docs/userguide.html#_moving_containers

[JadeMaveric]

I tried for_window [app_id="waybar"] move position mouse
No, it did not work. :disappointed: Not the way I imagined anyway

[alebastr]

@JadeMaveric, I had this in my sway config. Works slightly better.

for_window [app_id="waybar" floating] {
    move position cursor
    move down 120px # adjust if some menus still don't fit
}

It's also possible to do correct positioning via ipc:

#!/usr/bin/env node
const BAR_HEIGHT = 28;
require("i3wm")
  .Client.connect({ bin: "sway" })
  .then(client => {
    client.subscribe("window");
    client.on("window", ({ change, container }) => {
      if (container.app_id === "waybar" && change === "new") {
        client.command(`move position cursor`);
        client.command(`move down ${container.geometry.height / 2 + BAR_HEIGHT} px`);
      }
    });
  });

[alebastr]

Some related links:
https://github.com/swaywm/sway/issues/3871 - sway currently does not support xdg popups on layer shell windows.
https://github.com/wmww/gtk-layer-shell - library that hacks gtk3 to correctly initialize popups on layer shell window (does not work in sway, see ↑).
https://gitlab.gnome.org/GNOME/gtk/merge_requests/713 - support for custom surfaces was removed from gtk4.

[JadeMaveric]

@alebastr Thanks!!! I tried the sway config method and it worked.
I've never used IPC before, guess this is a good excuse to get started with it.

[topisani]

I improved a bit on @alebastr's script and rewrote it in bash. It should now place the menu to the left and below of the cursor, which (at least in my case, with the tray in the top right) never places a menu partly off-screen, and always next to the cursor.

#!/bin/bash

handle() {
  local event=$(swaymsg -t SUBSCRIBE "['window']");
  if [[ $(jq .container.app_id <<< $event) == '"waybar"' && $(jq .change <<< $event) == '"new"' ]]; then
    local vert=$(( $(jq .container.geometry.height <<< $event) / 2 + BAR_HEIGHT))
    local horz=$(( $(jq .container.geometry.width <<< $event) / 2))
    swaymsg move position cursor
    swaymsg move down $vert px
    swaymsg move left $horz px
  fi
}

while handle; do
  sleep 0.1
done

Adding this to your sway config, the menu doesn't flash up in the center first:

for_window [app_id="waybar" floating] {
  move position 5000 5000
}

[luispabon]

Unfortunately @topisani 's workaround above doesn't work on some multi monitor setups. Works great on the primary display though.

[luispabon]

How about using wlr-layer-shell if available ? Mako uses it to correctly position itself

[ddevault]

There is a patch for sway which implements layer shell popups:

https://github.com/swaywm/sway/pull/4307

[luispabon]

SWEET

[kisik21]

If I apply this patch right now, will it all work properly or some Waybar patching will be required too?

[dinnymate]

@kisik21 That patch had been merged, but sadly it didnt solve the issue. I suppose XDG Popup still has to be implemented for waybar.

[kisik21]

@dinnymate yeah, I applied this patch myself (it's easy to patch stuff on NixOS - the Linux distribution I use) and saw no difference :3

[ddevault]

it's easy to patch stuff on NixOS - the Linux distribution I use

I use arch btw

[kisik21]

@ddevault I used arch btw, NixOS is better

[ddevault]

I don't actually use arch, I'm just making fun of you :P

[luispabon]

We found the arch user.

Oh wait!

[kisik21]

@ddevault I understood it the second I saw your comment :3
Ok, let's not make this an off-topic chat!

[dinnymate]

Any update on this?

[tmccombs]

If I understand correctly, this is just about menus fro tray icons and tooltips (which is still very annoying). Is there any way to position a floating window created by a command run with a custom "on-click" handler?

Also, is there anything I could do to help resolve this issue?

[eternal-sorrow]

Also, is there anything I could do to help resolve this issue?

help with this PR maybe? https://github.com/Alexays/Waybar/pull/441

[Alexays]

Fixed thanks to @alebastr with #441 <3

[HelloEdit]

Hi, just installed waybar on Arch with Sway. When I run the minimal configuration and put my cursor on the date, I have that:

(waybar:2113): Gdk-WARNING **: 16:18:35.671: Couldn't map window 0x555c00eaed50 as subsurface because its parent is not mapped.

I think it has something to do with this issue. If it doesn't, please let me know.

[tmccombs]

I also get that error, and tooltips do not appear for me at all.