DisplayFusion RSS: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Thu, 10 Jul 2014 19:59:20 GMT

Awesome, glad to hear it!

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Thu, 10 Jul 2014 16:38:12 GMT

The beta works great in all three cases. Thanks!

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Thu, 10 Jul 2014 16:02:35 GMT

We've just released a new DisplayFusion beta version (http://www.displayfusion.com/Download/Beta/) with the new option wording, and it should no longer move a window if the new location would overlap the old location. Please let us know if you run into any trouble after updating.

Thanks!

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Fri, 04 Jul 2014 18:32:33 GMT

Yep, great idea! I like the wording, though we may tweak it a little bit, but I think that makes sense

Thanks again for your feedback, it's much appreciated!

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Thu, 03 Jul 2014 21:11:24 GMT

Thanks, Keith. The help text would also need to be changed to indicate that child windows are always centered when moved between monitors: http://www.displayfusion.com/Help/?Version=6.0#settings-windowmanagement

Sorry, you're right about the modal windows. I was just getting hung about the case of moving modal windows to a different monitor, but not centering them. But windows are always centered if they are moved to a new monitor. Thus, it's behaving as expected.

The wording is confusing because it's really a two-step action: moving a child window to the same monitor as the parent, and centering it over the parent. But you could conceivably move without changing its position -- for example, the DisplayFusion command "Move Window to Next Monitor" preserves the position of windows. Or, you could center a child window that's already on the same monitor, even though this means it's not otherwise getting moved.

May I suggest the following text and defaults:

Code
Copy
Select All

(X) Center child windows over the parent window
    (X) Move only modal windows (windows that block input)
    ( ) Move child windows that are on the same monitor as the parent window

This would better capture DisplayFusion's actual behavior for these options. When you center over the parent, then by definition, you're also moving it to the same monitor as the parent. So that wording captures both aspects.

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Thu, 03 Jul 2014 19:22:05 GMT

Ok, your comments on the "Centre child windows" option make sense. We'll update the wording for that option, and we'll look into ignoring the child window if it wouldn't move more than the size of the child window itself.

Regarding the modal windows, I'm not quite sure what you're getting at. The point of that option is to allow DisplayFusion to only move modal windows, like the unsaved change dialogs in Paint.NET and Notepad, rather than moving all child windows (i.e. chat windows that are separate from the main contact list in IM apps, etc). From what you described, that option is working as expected. Am I missing something here?

Thanks!

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Wed, 02 Jul 2014 19:36:10 GMT

But you know exactly where Paint.NET thinks the dialog should be. It's where the dialog was located on the screen before it got moved.

Monitors are so wide these days that centering is a useful feature, even if it's on the same monitor. You just don't want it to cause misclicks. The way to do that is to center only if there is no overlap -- i.e., if the user cannot click on the wrong option.

The idea is that if the program put a dialog over the main window, then it probably knows what it's doing. DisplayFusion shouldn't second-guess it and move it anyway. Before moving a child window, it should check its position, check for overlap, and then cancel.

--

Actually, there's another bug here. I have "Only move modal windows [...]" checked. And the Unsaved Changes dialog in Paint.NET is modal. So it shouldn't have been getting moved at all, even if Center was checked.

In fact, DisplayFusion is even moving the Unsaved Changes dialog in Notepad! This is not a custom dialog like the Paint.NET dialog -- it's a standard Windows dialog. If it's even happening to Notepad, then the whole thing is broken.

--

As for your suggested workaround:

Quote:

if you disable the "Centre the child window" option in the Settings, it will only centre it if it had to move the child window from a different monitor. If the child window is already on the correct monitor, it won't get moved by DisplayFusion.

If it works as you describe, then the text of the option is misleading.

"Center the child window [...]" is currently a suboption under "Move child windows to the same monitor [...]". Because it is a suboption, you expect it to control what happens when the parent option is activated, i.e., only when moving child windows to a different monitor.

If it works as you describe, then it's always centering child windows after moving them between monitors. (This makes sense since monitors can be different sizes.) The option is actually doing the reverse of what its position implies -- it's controlling the centering of child windows that are not moved to a new monitor.

The text of the option should be revised to say this.

RE: Centering child windows: should be more restrictive

Binary Fortress Software — Wed, 02 Jul 2014 18:01:27 GMT

There isn't a way for us to know where Paint.NET thinks the centre should be, but if you disable the "Centre the child window" option in the Settings, it will only centre it if it had to move the child window from a different monitor. If the child window is already on the correct monitor, it won't get moved by DisplayFusion.

Hope that helps!

Centering child windows: should be more restrictive

Binary Fortress Software — Mon, 30 Jun 2014 21:24:18 GMT

The "Center the child window over the parent" feature currently moves all child windows. This is interfering with programs that calculate their own centered dialog positions, but come up with a different value than DisplayFusion.

DisplayFusion only moves windows after a slight delay, enough for the dialog “jump” to be visible. Unfortunately, this also means that a user with fast reflexes may click on the wrong dialog. This can have severe consequences.

For example, in Paint.NET, the dialog position is almost at the center, but slightly offset. When the "Unsaved Changes" dialog appears, then DisplayFusion moves it up by about 80 pixels. Unfortunately, this is a task dialog, in which the options are listed vertically. If you react too quickly, then you click on the original position of “Save”, except that it’s now over “Don’t Save.” You lose all your unsaved changes!

See attached screenshots showing the problem caused by the centering.

Desired behavior: Center the child window only if it is not over the parent window.

Alternative behavior: Center the child window if it does not overlap the calculated center position. This solves the problem for modal dialogs, but not for non-modal dialogs, because the click could go to the parent window.

DisplayFusion RSS: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

CodeCopySelect All

RE: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

RE: Centering child windows: should be more restrictive

Centering child windows: should be more restrictive

Code
Copy
Select All