polybar: Polybar shows on wrong monitor after hide

The fix in i3 is merged now. Thanks everyone 😃

@Airblader Now that I read my comment again it does sound demeaning. I’m sorry about that, it certainly was not meant that way.

Polybar sets the x and y coordinates of the window to position it on the screen. It calculates those coordinates from the monitor specified in the config (or the primary monitor). So for example if I had two 1920p monitors side-by-side and polybar on the monitor on the right at the top, it would set its geometry as 1920x50+1920+0 (assuming it is 50px high). As far as I know we don’t use the monitor name for anything else when positioning the bars. Does i3 need polybar to explicitly set the monitor name somewhere?

I am currently on my way back from vacation, so I don’t have much time to track this down right now but I will try to dig into this and give a more in-depth answer tonight or tomorrow.

Sorry again, I didn’t mean to attack anyone. I’m very much a fan of your and the i3 team’s work. I hope we can fix this issue together.

I can’t say I appreciate @patrick96’s tone, but in trying to hunt this down I would appreciate if someone could tell us what it is polybar does that is supposed to let the window manager know onto which output to place the bar.

From the log file provided by @jluttine in https://github.com/i3/i3/issues/3819 it appears that polybar sets the geometry to x=0/y=0 for both windows, so I guess the geometry when mapping the window is not what polybar tries to use(?)

Your PR works for this issue. I have nonetheless added a fix within polybar since there are likely other WMs that do a similar thing.

Are these log file parts from the latter, not former, setup?

In the log files, there are four polybar windows being mapped in total, grouped into two events: one at 10:45:27 and one at 10:45:43. The logs above are from the latter one.

Out of all four requests, there is only one with an initial geometry of x != 0:

10/13/2019 10:25:27 AM - manage.c:manage_window:195 - startup workspace = (null)
10/13/2019 10:25:27 AM - This window is of type dock 
10/13/2019 10:25:27 AM - randr.c:get_output_containing:108 - comparing x=1280 y=0 with x=0 and y=0 width 1280 height 720
10/13/2019 10:25:27 AM - randr.c:get_output_containing:108 - comparing x=1280 y=0 with x=1280 and y=0 width 1280 height 720
10/13/2019 10:25:27 AM - manage.c:manage_window:220 - Starting search at output HDMI-1
10/13/2019 10:25:27 AM - manage.c:manage_window:226 - Top dock client
10/13/2019 10:25:27 AM - manage.c:manage_window:245 - Initial geometry: (1280, 0, 1280, 27)

But this is from the first of the two events(?) and also it can be seen that that one actually shows at HDMI-1 while all others go to eDP-1, so it sort of sounds like i3 is doing the correct thing.

No, polybar-msg cmd restart should not break anything

Alright, so it is in fact i3 messing everything up (as usual).

It seems your only option is to leave this option set to true and use a transparent dummy bar to make i3 reserve space for your bars as described here. Then, if you hide the bars, you will have to kill the dummy bars and restart them once you show the bars again. This way i3 can reclaim the space when you hide the bars.