Closed tkna91 closed 7 months ago
Is ReaImGui up-to-date? Version 0.8.7.6 should have fixed this HiDPI bug on Linux. Extensions > ReaPack > Synchronize packages.
Sorry, I didn't notice. After the update, it was resolved. Thanks for the useful tool!
Screencast:
https://github.com/cfillion/reaimgui/assets/102382754/64d1ffb3-fca6-49f8-a819-20da53474ffe
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:
https://github.com/cfillion/reaimgui/assets/102382754/20f64ea5-46f7-4303-b6b6-3e4cd3f07717
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.
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.
Screenshot:
Screencast:
https://github.com/cfillion/reaimgui/assets/102382754/e9cdaebb-7d4b-4a4c-9c9c-fbb91e6fee2e
Is it possible to not save the window position (so that the mouse pointer position is not shifted) by referring to the above option?
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.)
I checked with the following options for Modal window positioning:
.
It looks fine.
Screencast:
https://github.com/cfillion/reaimgui/assets/102382754/89b25592-014a-4988-b97d-bb2021999791
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:
https://github.com/cfillion/reaimgui/assets/102382754/fe73f13a-cb68-424e-ae0d-10e7735b9509
Is it more of a problem with the sanitization of nvk_SEARCH ?
The following did not fix the problem.
~/.config/REAPER/Scripts/nvk-ReaScripts/SEARCH/Data/scripts/search/data/results.dat
The results.dat:348
is bytecode so I don't know what is there.
@NickvonKaenel What do you think?
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
$
@cfillion Even if it is not a newer version, simply disabling the following options you noted may solve the problem.
Screencast:
https://github.com/cfillion/reaimgui/assets/102382754/2dea35d9-35bf-4013-a3da-9fe1d1f34c6d
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.
Some scripts seem to require a new version to make the first click. Screencast:
https://github.com/cfillion/reaimgui/assets/102382754/e4214640-8ab5-4b0b-b4ef-6b322be58ab3
@NickvonKaenel ListClipper_IncludeRangeByIndices
is being renamed to _IncludeItemsByIndex
in v0.9 (34d9a7dcb4224a9c272299af3e1b4cc8035c15b3). 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()
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
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 (256b2cbc38330cc7f400d14dd60738678b456892). (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.
Thanks, I'll get that fixed!
In the new version, this problem seems to be less likely to occur. https://github.com/swaywm/sway/issues/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:
https://github.com/cfillion/reaimgui/assets/102382754/548734f4-1b5b-4f9e-bb32-0b566913f3f7
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:
https://github.com/cfillion/reaimgui/assets/102382754/8210c0aa-2979-4efe-8228-c4b645da83bf
In my environment, the mouse pointer target is off as shown here and does not work properly.
Screencast:
https://github.com/cfillion/reaimgui/assets/102382754/7340079a-2630-4dec-87a8-de6421dbb5b9
This seems to occur in a multi-display environment. It did not occur in a single display laptop environment. What should I do?
Environment: