Mouse pointer misalignment in a multi-display Linux (sway) environment about reaimgui HOT 19 CLOSED

Ah I see, the issue is that ListClipper_IncludeRangeByIndices did not exist in ReaImGui v0.8.5, it was added in v0.8.7.

Your script should either request API version 0.8.7 or use the old 0.5.10–0.8.6 name _ForceDisplayRangeByIndices.
...Or so I would normally say if that specific shim wasn't broken in the current release (256b2cb). (Nobody complained in over 6 months so I didn't bother doing a hotfix release.)

That one renamed function is the only breaking change between .5 and .7, so simply correcting the requested API version should work fine.

from reaimgui.

I pushed a fix for the position desync after opening a window. Here's a build: reaper_imgui-x86_64.so and imgui.lua.

Based on the following, it appears that the specification is not yet fixed, even for Wayland as a whole.

Yeah, it's crazy to me that Wayland is still missing the very basic feature of letting applications move their windows. Dear ImGui expects to be in full control of the position of its windows across all monitors relative to a global 0,0px point like it is on Windows and macOS.

At least it seems that both KWin and Mutter allow that to some extent, so it's not an issue in KDE and Gnome. (I haven't looked into whether they implement some unofficial Wayland protocol extension or it's just a special exception for X11 apps like REAPER...) Although these two WMs insist on clamping windows to be fully within monitor edges instead of letting Dear ImGui do that itself, so it's not perfect either...

Is it possible to not save the window position (so that the mouse pointer position is not shifted) by referring to the above option?

Dear ImGui has its own way of saving and restoring window positions. It can be disabled by unchecking Preferences > ReaImGui > Restore window position, size, dock state and table settings. Or programatically via {Config,Window,Table}Flags_NoSavedSettings.

(Disabling that option would not help with this issue though, as Sway would still not let Dear ImGui place windows at the default position that it wants. Also WMs without floating windows or floating disabled.)

from reaimgui.

Here's the relevant part of my code.

if not r.ImGui_ValidatePtr(clipper, 'ImGui_ListClipper*') then clipper = r.ImGui_CreateListClipper(ctx) end r.ImGui_ListClipper_Begin(clipper, #LIST, r.ImGui_GetTextLineHeightWithSpacing(ctx)) if Results.Focus then r.ImGui_ListClipper_IncludeRangeByIndices(clipper, Results.Index - 1, Results.Index + 1) end

I have not tested anything on Linux, so it's very possible there are errors.

from reaimgui.

Yeah before I use ImGui_CreateContext I'm calling
dofile(r.GetResourcePath() ..
'/Scripts/ReaTeam Extensions/API/imgui.lua')
('0.8.5')
so that's interesting that it's not working

from reaimgui.

Thanks, I'll get that fixed!

from reaimgui.

Is ReaImGui up-to-date? Version 0.8.7.6 should have fixed this HiDPI bug on Linux. Extensions > ReaPack > Synchronize packages.

from reaimgui.

Sorry, I didn't notice.
After the update, it was resolved.
Thanks for the useful tool!

Screencast:

from reaimgui.

I don't know when it started, but the mouse pointer still seems to shift when the window is initially opened.
It stops shifting when the window is moved.

Screencast:

from reaimgui.

How are you moving the window? When I tried under Sway a few weeks ago, it rejected any attempts by ReaImGui to move its own windows and always placed them at the center of the screen. Probably because of the ongoing Wayland situation where global window coordinates aren't officially a thing.

Is there a setting to have Sway let ReaImGui decide where its own floating window are placed? Or did you use Sway's shortcut for moving windows instead?

From the video, it looks like Sway ignored ReaImGui's initial window placement request, so the actual window position doesn't match what ReaImGui thinks it is.

from reaimgui.

How are you moving the window?

The window should be able to be moved by holding down the $mod key (meta by default) and dragging.

Probably because of the ongoing Wayland situation where global window coordinates aren't officially a thing.
Is there a setting to have Sway let ReaImGui decide where its own floating window are placed? Or did you use Sway's shortcut for moving windows instead?
From the video, it looks like Sway ignored ReaImGui's initial window placement request, so the actual window position doesn't match what ReaImGui thinks it is.

Yes, as far as I know, there is no standard way (yet) for the software used in sway to remember and restore window locations.
Based on the following, it appears that the specification is not yet fixed, even for Wayland as a whole.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

I thought that when the Modal window positioning: option of REAPER is one of the following, it would not remember the absolute position of the window and prevent the mouse pointer from shifting, but so far this does not seem to be the case.

• Center on current screen
• OS positioning

Screenshot:

Screencast:

Is it possible to not save the window position (so that the mouse pointer position is not shifted) by referring to the above option?

from reaimgui.

I checked with the following options for Modal window positioning:.

• Last window position (default)
• Center on current screen
• Center on mouse cursor
• OS positioning

It looks fine.

Screencast:

from reaimgui.

There may be a problem with that newer version.
Pressing down on the cursor key in the search results for nvk_SEARCH seems to cause an error.

ReaScript Error:

Data/scripts/search/data/results.dat:348: attempt to call a nil value (field 'ImGui_ListClipper_IncludeRangeByIndices')

ImGui Error:

(g.CurrentWindowStack.Size == 1) && "Mismatched Begin/BeginChild vs End/EndChild calls: did you forget to call End/EndChild?"

Screencast:

from reaimgui.

Is it more of a problem with the sanitization of nvk_SEARCH ?

from reaimgui.

The following did not fix the problem.

1. Rename ~/.config/REAPER/Scripts/nvk-ReaScripts/SEARCH/Data/scripts/search/data/results.dat
2. Reinstall nvk_SEARCH

The results.dat:348 is bytecode so I don't know what is there.
@nickvonkaenel What do you think?

from reaimgui.

I was able to decode the following.

$ luac -l -p results.dat | grep \\[348\\]
        203     [348]   GETTABUP        7 0 3   ; _ENV "r"
        204     [348]   GETFIELD        7 7 52  ; "ImGui_ListClipper_IncludeRangeByIndices"
        205     [348]   GETTABUP        8 0 48  ; _ENV "clipper"
        206     [348]   GETTABUP        9 0 16  ; _ENV "Results"
        207     [348]   GETFIELD        9 9 53  ; "Index"
        208     [348]   ADDI            9 9 -1
        209     [348]   MMBINI          9 1 7 0 ; __sub
        210     [348]   GETTABUP        10 0 16 ; _ENV "Results"
        211     [348]   GETFIELD        10 10 53        ; "Index"
        212     [348]   ADDI            10 10 1
        213     [348]   MMBINI          10 1 6 0        ; __add
        214     [348]   CALL            7 4 1   ; 3 in 0 out
$

from reaimgui.

@cfillion Even if it is not a newer version, simply disabling the following options you noted may solve the problem.

• RealmGui settings: Restore window position, size, dock state and table settings

Screencast:

from reaimgui.

Some scripts seem to require a new version to make the first click.
Screencast:

from reaimgui.

@nickvonkaenel ListClipper_IncludeRangeByIndices is being renamed to _IncludeItemsByIndex in v0.9 (34d9a7d). Is your script using imgui.lua to enable backward compatibility?

The current recommended snippet for public scripts:

local imgui_path = reaper.GetResourcePath() .. '/Scripts/ReaTeam Extensions/API/imgui.lua'
if not reaper.file_exists(imgui_path) then error('ReaImGui is not installed') end
dofile(imgui_path) '0.8.7' -- the version your script was written for

-- from this point, it's safe to use ReaImGui's API in reaper.* (of the version specified above only)

Improved snippet coming soon in v0.9 (the previous one remains supported obviously – this new one adds local per-file version for safe usage in libraries and faster call-less enums):

if not reaper.ImGui_GetBuiltinPath then error('ReaImGui is not installed or older than 0.9') end
package.path = reaper.ImGui_GetBuiltinPath() .. '/?.lua'
local ImGui = require 'imgui' '0.8.7'

-- from this point, it's safe to use anything in the ImGui.* table:
-- it contains the API of the specified version

-- call-less enums: ImGui.WindowFlags_None instead of ImGui.WindowFlags_None()

from reaimgui.

In the new version, this problem seems to be less likely to occur.
swaywm/sway#7974

After changing to the new version, the first launch puts the problem, but once closed and on subsequent launches, the ReaImGUI related z-ordering of windows no longer seems to be wrong.

Screencast:

Not that it doesn't happen, strictly speaking, probably due to causes other than the ReaImGUI, but the problem seems to have been greatly reduced insofar as I use it on a daily basis.

Screencast:

from reaimgui.