Skip to content

Conversation

@SiboVG
Copy link
Member

@SiboVG SiboVG commented Jun 23, 2022

This PR fixes #1470 by moving a component config dialog to the center of its parent's screen (the main OR window) when the config dialog is initially located on another monitor as the parent, or if its location is outside of the visible region of the screen.

Steps to reproduce:

  1. Open a blank design file
  2. Create a body tube; the body tube config dialog will pop up
  3. Move the config dialog to a second monitor
  4. Close the config dialog
  5. Edit the body tube
  6. The config dialog should now be centered on the screen of the monitor that the main OR window is opened in

So note: it's still perfectly possible to move the edit dialog on another monitor, but it will reset its position if close and reopen the config dialog.

@neilweinstock
Copy link
Contributor

This definitely fixes the problem of config dialogs getting "lost"... but will it break people's use case where they want the config dialog on the other monitor? For those users having the dialog keep moving back each time would be very annoying indeed. I don't know how many people this would effect.

Here's an alternative: what if this behavior were applied only once when the app is first started up? That is, after starting the app, the first config window would open on the same monitor as the app, but after that the app will respect wherever the user puts it. This way, it's still very easy to find a lost config dialog (just restart the app), but those who want to keep the config elsewhere will be able to do it without going mad.

@SiboVG SiboVG marked this pull request as draft July 11, 2022 16:14
@SiboVG SiboVG marked this pull request as ready for review July 11, 2022 23:22
@SiboVG
Copy link
Member Author

SiboVG commented Jul 11, 2022

Latest commit only resets the edit dialog's position at startup (when it's outside of the main window's monitor).

@hcraigmiller
Copy link
Collaborator

hcraigmiller commented Jul 11, 2022

I don't have 2 monitors, so this is of limited use; functions as expected, no anomalies found using a single monitor.

Build 793
[Windows 11 Pro; Version 21H2; OS Build 22000.739; Windows Feature Experience Pack 1000.22000.739.0]
[Java "11.0.15" 2022-04-19 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.15+8-LTS-149)]

@SiboVG
Copy link
Member Author

SiboVG commented Jul 11, 2022

I did get to test it on 2 monitors, but the behavior may be different for macOS and Windows. I may have a chance to test it this week on Windows.

@hcraigmiller
Copy link
Collaborator

Okay, two monitor setup complete.

Functions as described; no anomalies found.

Build 793
[Windows 11 Pro; Version 21H2; OS Build 22000.739; Windows Feature Experience Pack 1000.22000.739.0]
[Java "11.0.15" 2022-04-19 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.15+8-LTS-149)]

@SiboVG SiboVG merged commit d78e595 into openrocket:unstable Jul 14, 2022
@SiboVG SiboVG mentioned this pull request Sep 22, 2022
@SiboVG SiboVG deleted the issue-1470 branch September 30, 2022 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Edit window can go outside of monitor

3 participants