Patch appears outside the screen

[Ars-subtilior]

I have created a patch, which I have opened several times. Today, when I tried to open it, it appears in the taskbar, but will not open and the preview in the taskbar is empty. I have tried shutting down Pd and restarting it, I have restarted my PC (running Windows 11) but the problem persists. I had noticed this with some older patches I was not worried about losing after getting a new PC - my old one ran Windows 10. Is this a known problem? Is this a Windows 11 problem? Is there a solution?

[ben-wes]

this sounds familiar and is most likely due to a canvas position outside your screen area (maybe the patch was saved on a multi-monitor setup before?).

maybe check if you can recover the window via right-click on the taskbar and maximizing it (i currently don't remember what other options there are and am not on windows)? i remember that this was an issue in the past and thought it was fixed. are you working with the current Pd version?

[Spacechild1]

This can happen when you save a patch that is on a second screen and then open it again with a single screen. The patch would still have the original coordinates and therefore will not be visible. That's obviously a bug. One workaround is to select the patch window in the taskbar and then bring it back to the main display with Windows+Left/Right/Up/Down.

[ben-wes]

related: #1805

[Ars-subtilior]

Maximising the window from the task bar and resaving it has fixed the problem. I have not been using two monitors, so I am not sure what the original cause was, but if it happens again, I have a solution now. Thanks for the help.

[Ars-subtilior]

Workaround available.

[ben-wes]

Workaround available.

good to see that it worked for you this way! i agree with @Spacechild1's opinion though: it's a bug and other users will experience this again. maybe not a critical issue - but would be good nonetheless to have a better solution for this (like limiting the offset in a way that at least parts of the window stay visible for interaction ... or even aligning windows at the top left corner if they are otherwise overflowing the screen area on any side. not sure what behaviours are common for other apps. but it's obviously a common problem).

@Spacechild1: would you suggest to keep this open or wait for similar reports?

[Spacechild1]

Let's keep it open for reference. It is important to point out that @Ars-subtilior did not use a second screen, so it is exactly not the same issue as in #1805 (which appears to have been fixed), but they are probably related.

[ben-wes]

just a random guess - but it could simply be this coordinate wrapping causing patches to open outside on the right if they were saved with a slightly negative position like -1 0 (which might be placed at 1923 0 afterwards considering my comment back then about the horizontal wrap at 1924px):

set x [expr ($x - $xmin) % $width + $xmin] 
set y [expr ($y - $ymin) % $height + $ymin] 

@Ars-subtilior do you by any chance remember where the window was maximized from (if you have these window transition animations activated anyway)?
and this could also be quickly tested by creating the scenario described above.

[Ars-subtilior]

I maximised the window from the task bar. Using any of the other options (move / size) did nothing.

[ben-wes]

i did a quick test on Win11 with Pd0.54-1 (with a 1920x1080 screen):

• confirming that i can create this scenario by saving with a position slightly left outside the screen
• for some reason, it even becomes invisible with an x-coordinate of -12 (although the blurry shadows are visible then and i can grab the border/edges and scale it into the screen)
• it's not possible for me to move a patch window slightly outside the top border since Win11 automatically repositions it back to 0 in that case
• to recover the window to the visible area, i can either maximize it via right-click on the taskbar or with the keyboard shortcuts mentioned by @Spacechild1 ([windows] + [up arrow], [windows] + [left arrow], ...)

now i'm not sure if this is the same as the case reported by @Ars-subtilior, but it's quite likely. simple solutions for this could be:

1. don't wrap if patch_x + patch_width < screen_width (same for y)
2. wrap with padding (although that would be quite arbitrary like 100 or so)
3. no more wrapping at all and instead just clip the x coordinate between minx and minx + width - patch_width (again same for y)

i think the scenario that was covered by the wrapping behaviour is a multi-monitor setup. in that case it works well for standard resolutions. but as soon as resolutions differ, it creates surprising results.

EDIT: corrected clip suggestion considering negative origin (i hope).

[ben-wes]

for the clipping-option, changing the pdtk_canvas_wrap_window function for Win32 starting from line

pure-data/tcl/pdtk_canvas.tcl

Line 52 in 0259d00

proc pdtk_canvas_wrap_window {x y w h} {

as follows might be an option (at least works when testing here on Win11... i didn't test multiscreen-setups or Win10 though):

proc pdtk_canvas_wrap_window {x y w h} {
    foreach {width height} [wm maxsize .] break

    # get virtual root coordinates for minimum position
    set xmin [winfo vrootx .]
    set ymin [winfo vrooty .]

    # clip window size to screen size
    set w [expr {min($w, $width)}]
    set h [expr {min($h, $height)}]

    # get max position
    set xmax [expr {$xmin + $width - $w}]
    set ymax [expr {$ymin + $height - $h}]

    # clip given position
    set x [expr {max(min($x, $xmax), $xmin)}]
    set y [expr {max(min($y, $ymax), $ymin)}]

    return [list $x $y $w $h]
}

adding to that: i removed $::menubarsize here since this function is only for windowingsystem "win32" and the value in that case is set to 0 in

pure-data/tcl/pd-gui.tcl

Line 391 in 0259d00

set ::menubarsize 0

- i hope, i'm interpreting this correctly?

[ben-wes]

@Lucarda are there any objections from your side concerning this clipping solution?

for people working on multi-screen setups, this shouldn't change anything - they can still distribute their windows as they wish and save/restore them that way. but it should protect users from disappearing windows (if i'm not wrong). i would go ahead and test this with more setups if it sounds right and possibly create a PR.

[Lucarda]

@ben-wes go ahead with the PR. I just tested it on Win11 with multiple displays and it all works fine for me.

:)

EDIT: i had pasted your code from above without any $::menubarsize in it. I agree that you are correct and there's no need for it.

[ben-wes]

alright - thanks a lot for testing! :)

[ben-wes]

PR is created after a bit more testing on my side as well. hope i did that right!