This is just a guess, but perhaps it due to GTK3/CSD stuff and it's not taking the whole window bounds, including the titlebar and window borders, into account? That would throw it off by like 20-30px every time.

@eht16 if you can try and debug it, I suppose you'll see that the value you get with `gtk_paned_get_position()` is smaller than the one set with `gtk_paned_set_position()` a couple ms before? If so, a sad hack could be something like: ```C gtk_paned_set_position(paned, pos); for (int i = 1; i < SOMELIMIT && gtk_paned_get_position(paned) < pos; i++) { gtk_paned_set_position(paned, pos + i); } ``` or a smarter version that would guess the delta from the actual difference, if that can give useful info.

Thanks guys, for your suggestions.

Was could it have been?

- CSD - any kind of timing issue related to setting the pane position - nor a GTK bug - ...

And the winner is: some old _eht16-Windows-special-hack_

For reasons I don't remember anymore, I added in https://github.com/geany/geany/commit/9431eea2445ccf191777cf3667a9292cf4ddcb... (in 2009) a Windows only change to realize the main windows *before* setting the window geometry and position. Maybe it was related to off-screen window positions or so. Or some GTK2 behavior required it which is no longer the case.

After removing the `gtk_widget_realize` call, the message window height is stable, i.e. stays at where is has been left off. Also, I couldn't find any other negative impact of the removed call, even weird off-screen positions worked as expected (the window is moved to the visible screen area).

Too bad I don't know why the realize call was added initially :(. At least, it pretty good explains why it happened only on Windows. Apparently, something in GTK3 has changed in that regard.

#2892 is here to fix it.