[Bug] Multiscreen change puts client off screen
upon changing docks, rest client tries to stick to 1st screen or previously placed screen.
馃憢 Thanks for opening your first issue! If you're reporting a 馃悶 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 馃巵, please provide real
use cases that would benefit. 馃應
To help make this a smooth process, please be sure you have first read the
contributing guidelines.
This has been a known problem for a little while but I do not have the correct setup to be able to reproduce it.
If someone wants to take a crack at fixing it, there is already logic to _try_ and prevent the app from launching off screen but doesn't seem to always work on Windows.
Unable to recreate. Recreation steps would certainly help.
I also was unable to replicate the issue. I tried a number of steps to attempt to recreate this:
The only scenario to have an issue for me was the last. In this case, Insomnia opened on the second monitor, but on the far edge of it closest to monitor 1, and only about 50 px of it. Without confirmation from @CtrlNull , I believe that this may be the issue that they were encountering? From the source code though, this is actually the intended operation. The application will open and move itself so that it is 50px on to an active monitor.
If however the issue is happening WHILE the application is open and they are changing their monitor/dock configuration, then I would think that that may be a driver issue, as Windows by default handles window configuration during monitor state changes and moving application windows to active monitors (as I was able to replicate with all of the previous replication scenarios).
At this point, I basically have two questions:
1 - @CtrlNull , can you elaborate on the issue that you're facing some more so that we can confirm the steps to reproduce it? Is it one of the scenarios I listed above?
2 - @gschier , as for the final scenario where the application reopens with only 50px horizontal application viewable, I partly feel that this should be changed to reposition the application fully within the bounds of the active display. Have any thoughts/feelings on this? If you agree, I can do a PR pretty easily to center the application or move it so that it is at least fully visible within the bounds of the active display.
@tostringtheory a PR for that would be great!
Also, thanks for the very thorough write up!
@gschier - I'll try and get a PR for that in the next couple days.
workaround if your window is offscreen:
edit the "bounds" file in %APPDATA%/Insomnia/localStorage
this is how mine looked like when insmonia was off-screen
{"x":-1928,"y":-8,"width":1920,"height":1040}
i changed it to
{"x":0,"y":0,"width":1920,"height":1040}
and i could recover the window
hope this is helpfull to anyone
best regards
Hey, for my pc the file bounds was located at AppData\Roaming\Insomnia\localStorage
workaround if your window is offscreen:
edit the "bounds" file in %APPDATA%/Insomnia/localStorage
Another way to get the window back onscreen without having to edit the bounds file (mine was also in AppDataRoamingInsomnialocalStorage)
A quick work around if your Insomnia app is loading off screen
Ensure it is the active app by clicking on the app Icon in the task bar and press F11
Most helpful comment
workaround if your window is offscreen:
edit the "bounds" file in %APPDATA%/Insomnia/localStorage
this is how mine looked like when insmonia was off-screen
{"x":-1928,"y":-8,"width":1920,"height":1040}i changed it to
{"x":0,"y":0,"width":1920,"height":1040}and i could recover the window
hope this is helpfull to anyone
best regards