Open evanmtp opened 7 years ago
Update: the issue seems to be that some of the code in j.get_onscreen_position.js recursively drills down to the top-level patcher and uses its coordinates to provide the window offset (containerposition) for positioning the pop-out browser window. This is fine for instances where j.namespacebrowser.view is instantiated directly in a patch or in the main GUI of a view, but it causes problems if j.namespacebrowser.view is in a panel - effectively, the JS skips over the panel window and just returns the main window’s coordinates. I modified the JS by removing the code related to containerposition. Inside j.namespacebrowser.view, I also changed the loadmess going into vexpr (which provides an horizontal and vertical offset to account for the patcher toolbars) from 52 34 to 18 0. This gives the correct alignment and seems to work whether j.namespacebrowser.view is loaded in a patcher, a view’s main GUI or a view’s panel.
Here's a zip containing a demo patch, a demo model and view with panel, and modified versions of j.namespacebrowser.view and j.get_onscreen_position.js :
Under some circumstaces, j.namespacebrowser.view will incorrectly position the pop-out browser patcher.
When j.namespacebrowser.view is instantiated inside of a panel within a view, the pop-out browser will appear at a location determined by the position of the view in the main patch. In the following screenshot, clicking on the j.namespacebrowser.view menu widget next to Input in the panel has caused the browser pop-out window to appear over the view in the main patch.
In the next screenshot, the main patcher window has been moved, and menu widget in the panel has been clicked again. Note that the pop-out panel has traveled with the view in the main patcher.
Please see the following patch for a demonstration.
The issue is based in j.get_onscreen_position.js, which is being used to get the position of the menu widget, but I'm afraid my JavaScript chops aren't up to offering a fix.