Repository navigation
wxGUI/nviz: fix 'window must be shown' error message during docking undocked 3D view window - #7819
Conversation
|
Did you run this change (recently) once built? I made an AI agent try out this PR, and it hit a circular import that isn’t on main with this. Even when working around that problem, it doesn’t seem enough. It also thinks that this fix only masks the problem, being a timing problem. It suggests another fix. You can read below if you’d like, I also included the files. Used Opus 5.5 Medium. Details (process)
I've read the PR and the issue; now installing build dependencies so I can build GRASS and run the GUI under a virtual display. Configuring the build; fixing missing dependencies one at a time. Build succeeded. First check: the PR adds Run inside a real GRASS session instead. Circular import in every order. Confirm at the real surface: launch the GUI on the PR head vs. GUI exits silently. Run The PR head can't even start the GUI. Checking the build output matches the PR source, then reproducing the original bug on Writing a driver that runs the real GUI and triggers the same handlers the toolbar buttons call (3D combo → Stdout is captured by the GUI's own console. Let me look at the screenshots, then send logs to a file. Confirmed the bug on main: docking triggers the Baseline logged. Now the PR's approach, with only the import changed (duck-typed Startup was slower after the rebuild (no GMFrame at 8 s yet). Re-running. GUI didn't come up. Checking the log and for leftover processes. Build-tree mismatch from switching to the older PR base. Simpler and more representative: apply the PR diff onto current PR-as-is on top of current Workaround variant: no assertion. Probe: resize the undocked window before re-docking — with Both variants leave the stored size stale (698×374) while the canvas is 940×800. Let me look at what that means visually. The stale viewport issue after resize+redock exists on main as well, so the PR just masks it rather than fixing it. Next I'll check whether EVT_SIZE is actually re-bound after the 1-second delay. Re-binding works: a later resize updates the viewport again. Cleaning up the working tree and sending the evidence. Details (Final summary)Verification: wxGUI/nviz, the "window must be shown" error when re-docking the 3D view (PR #7819)Verdict: FAIL. As submitted, the PR stops the GUI from starting at all. What the bug is and what the PR doesWhen you dock a 3D view back into the notebook, The PR's fix is a timing workaround, not a real fix:
So the resize that crashes is simply ignored, and resizes are handled again after 1 s. Why it isn't correct as writtenThe new line MethodI built current Steps
Findings
I sent four files: the reproduced error on |
Yes you are right, with last code from the main Git branch, this PR make Python |
7e4b9ea to
37abc47
Compare
…ndocked 3D view window
…ocking undocked 3D view window" There is a simpler solution. This reverts commit d0a9d578b318598b40827b07db346c3882dcd69d.
…on the screen Fix 'window must be shown' error message during docking undocked 3D view window.
|
Successfully refactored and retested to much simpler and better solution 37abc47. |
echoix
left a comment
There was a problem hiding this comment.
Made it retry it and it worked. There's still the existing issue when resizing that it only gets done on a subsequent resize, but that's the same on main too.
…ndocked 3D view window (#7819) * wxGUI/nviz: fix handling window resize event only if window is shown on the screen Fix 'window must be shown' error message during docking undocked 3D view window.



Fixes #7668.