92861 - windows filepicker should appear centered wrt parent

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect)

Description

[Chad Austin]

Like all modal dialogs should.  ;)
I've got this one.

Comment 1

[:deanis74]

Should they really?  If I resize an Excel XP window to be really small and hit
Save, the dialog isn't centered over the parent.  And Notepad's Save As dialog
appears to be positioned at 0,0 of the client area.

Comment 2

[Chad Austin]

By default, GetOpenFileName positions the dialog box at (0, 0).  Since notepad
is the most trivial of trivial apps, that makes sense.  From a UI standpoint, I
think it should at least be offset from the corner of the window at least a
little.  I don't have Office XP on here, but VC++ centers file dialogs.  MFC's
CFileDialog does too.

The MacOS HIG (yeah, I know this is Windows, but the HIG has a lot of very nice
general concepts) says that modal dialogs should be centered with respect to
their parent document window.

Can you think of a reason they shouldn't be centered?  I'm willing to listen. 
Either way, though, this work will have to be done no matter how we want to
position the native dialogs.

Comment 3

[:deanis74]

Point taken about Notepad.

There seems to be no standard in Windows apps.  IE 5.5 puts the Save As dialog 
at 0,0.  Now that I think about it further, I don't think I was testing things 
properly with Excel.  The small app window I had may have been too far in the 
top-left of the screen.

I'm fine with centering based on the parent window, of course ensuring that the 
dialog is entirely on-screen.  It would be nice if this work could be done as 
generically as possible, so that it can be reused for the other dialogs that 
should be centered.

Comment 4

[Chad Austin]

Attachment: proposed patch

Comment 5

[:deanis74]

Should add checks to ensure sure that:
  x >= 0
  y >= 0
  x + (child_rect.right - child_rect.left) <= ::ScreenWidth()
  y + (child_rect.bottom - child_rect.top) <= ::ScreenHeight()

I think that ScreenWidth() and ScreenHeight() should suffice, the dialog should 
appear on top of any task bars.

Comment 6

[John Morrison]

I don't really have standing, but I protest. Why is it considered useful 
to _not_ bring up the filepicker dialog reasonably close to where you are
currently using the mouse? "Yes, I know you're mouse is in the upper left
hand corner of app window, but I think I will open the dialog half a screen
away ..."

Comment 7

[:deanis74]

(I, of course, meant GetScreenWidth() and GetScreenHeight().)

Comment 8

[Warner Young]

Actually, the Visual C IDE centers its file picker wrt the screen, not the
parent window.  And MS Word only centers its file picker horizontally;  it's
offset by some amount vertically, but not centered.

Comment 9

[Chad Austin]

Attachment: new patch

Comment 10

[Chad Austin]

Anyone have a multiple monitor setup and want to test?  I'll be getting one in 
a month or so, so I can test then.

jrgm:  We don't follow any standards with respect to initial dialog placement 
at the moment.  We persist some, we center others, others yet we place flush 
with the upper-left corner.  Maybe I'm getting a grand UI vision like mpt, but 
I think it would be good if we chose a behavior to implement across the entire 
product.  Making the file picker follow the MacOS HIG seems like a reasonable 
place to start.  And I have no idea where to even start with the rest of the 
XUL dialogs...

Comment 11

[John Morrison]

The HIG. Oh, good. Well, while you're at it, can you remove the titlebar from 
modal dialogs on Windows, and make it so that modal dialogs cannot be moved on 
Windows. 

Comment 12

[Chad Austin]

You know as well as I do that people wouldn't like that.  ;)

Either way, if people would rather we make some sort of dialog box standard on
Windows, you just have to change a few lines of code in this patch to position
them in accordance to that standard.

Comment 13

[:deanis74]

Sure, GetSystemMetrics() does the same thing.  That's probably what 
GetScreenWidth/Height() call anyway.

Re: < 0, > screen width check, I'd rather do it the other way around.  This way 
there's a chance that it can be pushed too far to the top-left.  I know, not 
realistic with this dialog but it could happen.  We should make sure the dialog 
never opens at less than 0,0 so that the system menu, caption, and caption 
buttons are always accessible.

Comment 14

[John Morrison]

Oh, yeah. That wouldn't go down well :-]

I don't disagree with having consistency in the UI (and having it bend to 
platform convention as appropriate). I'm just saying that having the filepicker
open in the upper left of the parent window is a perfectly reasonable place 
for that dialog to appear [and, yeah, I don't like the idea of centering all 
modal dialogs, especially not "just because"].

By the way, there is a statement on secondary window placement in the Windows
guidelines. (Yes, many apps don't follow this spec, but it's not unreasonable,
particularly in that it notes "display it in a location that is convenient
for the user to navigate to and that fully displays the window" and doesn't 
mandate a one-location-fits-all-contexts behaviour).

http://msdn.microsoft.com/library/en-us/dnwue/html/ch09b.asp

> Window Placement: When determining where to place a secondary window,
> consider a number of factors, including the use of the window, the overall
> display dimensions, and the reason for the appearance of the window. The
> first time you open the window, display it in a location that is convenient
> for the user to navigate to and that fully displays the window. In a
> multiple-monitor configuration, display the secondary window on the same
> monitor as its primary window. If neither of these guidelines apply,
> horizontally center the secondary window within the primary window, just
> below the title bar, menu bar, and any docked toolbars. If the user then
> moves the window, display it at this location the next time the user opens
> the window, adjusted as necessary to the current display configuration.

Comment 15

[Chad Austin]

Dean:  huh?  Too far to the top left?  I don't understand.
jrgm:  Thanks for the link.  I wouldn't mind following those guidelines, but
they'll probably be much harder to implement.  Let's at least put a *little*
space between the new dialog and the parent window.  I'm not sure why, but
having the dialogs show up completely flush like that makes me cringe.

Comment 16

[:deanis74]

Chad, you've got this:

+    if (x < 0) {
+      x = 0;
+    } else if (x > screen_width - dialog_width) {
+      x = screen_width - dialog_width;
+    }

If x starts at, for example, 20, this falls into the else.  If screen_width =
800 and dialog_width = 840, you're going to push the dialog off-screen to the
left.  Unlikely, I know, but it could happen.

My suggestion:

if (x > screen_width - dialog_width) {
  x = screen_width - dialog_width;
}
if (x < 0) {
  x = 0;
}

If you always run through ifs, you'll make sure that the dialog is as
well-positioned as possible and that the top and left edges (access to the
system menu, caption, etc.) are always visible.

Comment 17

[timeless]

i think my views match jrgm's

Comment 18

[Chad Austin]

Attachment: third patch

Comment 19

[:deanis74]

Looks good to me.  r=dean on the third patch, I'll let everyone else work out
whether it's used or not, as it doesn't matter that much to me.

Comment 20

[Chad Austin]

I no longer have time for these.  Anyone else want to take them?

Comment 21

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 22

[Jonathan]

Still off-center?

Comment 23

[BugBot [:suhaib / :marco]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.