multi-monitor support seems to not work about hudkit HOT 5 CLOSED

yep, works for me! thanks :)

from hudkit.

Hi and thanks for reporting! ✨

I use i3wm with 2 monitors too, but without this issue, so I don't have an immediate solution, but I do have some ideas. Brain dump follows.

There are 2 separate surprises in this screenshot:

1. Based on where the window edges' drop shadows appear, the overlay window itself is positioned wrong. (Not the in-web-page content, but the actual window.)

   💭: That might suggest some other program is moving the overlay window. It looks to me as though in the first screenshot, the window is positioned centered relative to the right monitor, and in the second screenshot, centered relative to the left monitor. Perhaps there is a program on your system that automatically positions new windows centered within the currently active monitor?

2. The overlay window's entire area should have a partially opaque blue background, but it looks to be completely transparent.

   💭: This likely means the JavaScript on the example page.html errored out before drawing the blue monitor rectangles on screen. Perhaps I've goofed and used some cutting-edge JS feature in the example that Ubuntu's libwebkit doesn't support yet?

If you're feeling up for a debugging journey, any of the following diagnostics would help a lot:

The second issue (probably JS erroring out?) is likely easier:

1. Edit the example's run.sh to pass the --inspect flag to hudkit;

-../hudkit "file://$PWD/page.html"
+../hudkit --inspect "file://$PWD/page.html"

2. What console entries (if any) does the Web Inspector window's Console tab contain? Clicking one and Ctrla selects all if you want to copy-paste.

The first issue (wrong window position) is trickier to narrow down, because the space of things that could cause it is pretty big. But these would help:

• Try editing main.c to directly give integers of your choice to gtk_window_move and gtk_window_resize (instead of using the x, y, width and height variables) and seeing what happens. If setting the window to a different position in the code makes no difference, that would definitely imply some other program is moving the overlay window after it's created.

• Try disconnecting or connecting a monitor using xrandr, while the hudkit example is running. That should trigger hudkit to resize the overlay window to the new desktop area. If it positions correctly then, that would rule out bugs in hudkit's own window positioning.

• If it seems based on the above that something is resizing the window after creation, you could back up your i3 config, copy the default from /etc/i3/config, and if it works then, gradually bring in parts of your actual config until it breaks. Even if it's just something weird in your setup, it would make a good FAQ entry for the next person.

from hudkit.

passing --inspect shows nothing at all in the console, bizarrely:

and the monitor-frame-container is totally empty.

the window seems to be consistently opening in the correct position now, though – i just upgraded my gpu drivers, but don't think i changed anything else. it works fine if i pass --inspect, but apparently just doesn't show up at all now if i don't. who knows...

adding some logging to the embedded js, it seems like Hudkit.getMonitorLayout is hanging? adding some more logging, it seems like the generated js (specifically, the name of my external monitor) is kinda Weird:

got monitor model: 'eDP-1-1' (length 7)
got monitor model: 'HDMI-1-2' (length 8)
final buffer: [{name:'eDP-1-1',x:0,y:0,width:1920,height:1080},{name:'HDMI-1-2d~',x:1920,y:0,width:1920,height:1080},]

there are consistently a few junk characters after HDMI-1-2; they change each run.

if i memset escaped_monitor_model_string full of zeroes in on_js_call_get_monitor_layout just after it's declared, the problem goes away. aiui, only statics and globals are initialised to zero automatically, so i guess it needs zeroing out explicitly?

from hudkit.

if i memset escaped_monitor_model_string full of zeroes in on_js_call_get_monitor_layout just after it's declared, the problem goes away. aiui, only statics and globals are initialised to zero automatically, so i guess it needs zeroing out explicitly?

Oops! 😦 You're right. I thought I checked this; I even wrote a comment, which on further reading is altogether wrong. Why was I even trying to optimise out a 1-char memset?

Memsetting a '\0' at the end should be enough; the rest of the buffer being uninitialised junk doesn't matter.

from hudkit.

Fix is on master. Check it works for you?

It's a great mystery why this has never happened on my machine. Nasal demons are scary.

from hudkit.