Created attachment 25223 [details]
screenshot

I was just about to file this bug, luckily paolo already did it for me. 

The usability issue is it causes the users a few extra steps to use the expanded
dialog.  Instead of just expanding and then searching for a location I've
observed users expanding, re-centering the dialog and then locating the folder
they are looking for.  The dialog should re-center itself on expand so that
those with smaller screens are not left with half the dialog off their screen.

At the same time I wonder if the re-center should be done if you go from
expanded to not.  Probably, and since that situation shouldn't arrive very often
I'd say it's probably a non-issue.

The Mac HIG says that you should reposition the dialog when initially expanded,
but then do *not* reposition again if it shrinks.

Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.

*** Bug 144045 has been marked as a duplicate of this bug. ***

Created attachment 30060 [details] [review]
patch to implement proposed behaviour

Hi, 
this patch should implement proposed behaviour, that is: recenter on expand
only.

The default behavior of the dialog is not centered but rather centered
on the parent so centering on the screen could move the dialog a long
ways. I'm not sure that centering is correct at all here ... rather
perhaps the window should just be moved as far as necessary to keep it
entirely onscreen. CC'ing Havoc in case he has ideas about the 
correct window manager interaction.

An idea would be to:
* horizontally center on parent
* vertically align with the top of parent

Sort of like this:
----------Parent----------
|       | File-  |        |
|       |Chooser |        |
|       |--------|        |
|                         |
|-------------------------|

The Mac OS X like effect are not needed ;P but this does quarantee maximum
visibility for the dialog on small screens

Lemmit's idea sounds interesting. I don't know whether it is good to behave in
such an inconsistent fashion, though. What about centering it on the parent
window, moving it as far as required to the left/up to make it fit on the screen
if it doesn't fit?

IMO, this is a Metacity bug and no gtk+ changes need/should be made (this is a
general bug so adding a gtk+-specific hack will merely bandage over one of the
specific cases where the problem manifests itself).  I have an idea of how to
fix this cleanly--which will also handle the all-to-common case of having a
terminal near the bottom of the screen and adding an extra tab, only to have the
bottom of the window (which I painstakingly aligned with the bottom panel)
disappear.  My idea would simultaneously handle bug 122196.

Unfortunately, I won't have time before 2.10.x, but I'll visit this in a couple
months or so.

Reassigning to Metacity and marking as blocking 155458.

What's the idea?

It seems dubious to move windows on configure events that only resize. It might
be better if gtk could send some kind of "replace this window" request maybe?

To explain, let me first consider a different situation:

What if an app requested to resize itself such that it's top edge went off the
top off the screen?  It's really bad to violate constraints, and especially the
top-edge off the screen one.  So, we say that this would violate our constraints
and we force the window back onto the screen--thus moving the window when it
merely wanted to be resized.

(Clarification note: While I'm still not an expert in X, it appears that moving
the top of the window while keeping the bottom edge fixed is considered a move
and a resize; however, moving the bottom edge while keeping the top fixed is
considered a resize only.  So technically, what I said above is different than
just a resize, though it's really dubious to present contrasting behavior to the
user that is dependent on obscure implementational details like this--the user
thinks of both as resizing)

Connection to this problem:
Users want to see windows they are interacting with in most cases.  We need a
constraint to reflect that.

Obviously, we don't want to prevent users from dragging windows offscreen if
they want (though some heavy edge resistance will be nice when I or someone else
gets around to it...).  But it does make sense to prevent apps from doing so. 
To enable this, we could add an 'onscreen' bitfield to window.h, and if it is
set, then constraints requires all move or resizes that don't come from user
interaction to result in the window remaining on the workarea.  (We would need
to provide constraints.c the ability to distinguish between user and application
actions, but Rob has stated that it could be added readily)

I believe that this change would fix this bug, the annoying
terminal-gets-bigger-when-a-second-tab-is-opened problem I have (since I often
have terminals at or near the bottom of my screens), and bug 122196.  It would
also be consistent with why we raise windows on click (users like to see things
they are interacting with), as well as the change we want to make in bug 143145
(clamp windows to screen size when mapped).  In all cases we are following the
principle of allowing the user to see what they are interacting with (unless
_they_ tell us they don't need to see part or all of the window).


Okay, now that I've talked up this solution and how it's supposed to solve world
hunger, I'm ready for it to get shot to pieces.  ;-)

I think I said previously that it'd be very difficult to make the constraints
separate for each.

You'd have weird situation where the user would try to move or resize a window
and it would suddenly jump somewhere else on the screen since its now a user
action and not an application action, or the user puts a window somewhere but
then the application resized itself and jumps somewhere else because its not
subject to a different set of constraints.

The "onscreen" bit has a similar set of problems.  Once the "onscreen" bit is
set, the window can be happily and totally hosed by ConfigureRequests.  Riddle
me this: top panel covers only part of the top edge of the screen.  User moves a
window so that the titlebar is partially covered by this top panel.  "onscreen"
bit is now unset.  Application uses a ConfigureRequest to move itself over or
up. Now the title bar is completely covered.  User doesn't know how to recover
the window.

Also, moving the top edge of the window is a resize without a move if you set
the window gravity to something with South in the title (i.e. South, SouthWest,
or SouthEast).  As far as I can tell though, nothing ever changes the window
gravity to anything but NorthWest, but its possible to do so.

I think I'm just going to have to implement it and have you take a look, because
either I'm missing something fundamental, or else I'm not explaining what I'm
thinking about correctly.  The scenarios you state just don't make sense as
possibilities from what I have in mind (it sounds to me that you're imagining a
different algorithm or something because I can imagine some algorithms that
would have the exact problems you pose but would otherwise be similar to what I
have in mind), but it may just be that I'm not understanding something
important.  I'll code it up and send it to you for finding problems if I still
think it works.

The problems I state are fundamental to any system that applies a different set
of constraints at different times, unless the constraints are isomorphic.  It
may be possible to design a system such that these problems are mitigated
somehow, but I don't really see a way.

Note that I'm not talking about the window disappearing completely off the
screen.  presumably the window onscreen constraints wouldn't ever be violated,
so alt-moving would always work.  But alt-move simply isn't discoverable for the
user, though I could imagine users accidentally using it (sticky keyboard, cat,
whatever).  We shouldn't have ways for alt-move to disable their ability to
manipulate the window using only the mouse either, except in extreme cases like
the window not fitting at all on the screen.

This is basically the reason for enforcing the titlebar onscreen constraint. 
There's no way currently for the user to get in a weird sitation that requires
knowledge of specialized keyboard shortcuts in order to escape.  I simply don't
see any sort of use case for moving windows off the screen that isn't met easily
with shade or minimize that would lead me to believe sacrificing this property
would be worthwhile.

This bug and my proposal here aren't about moving the titlebar offscreen, so
your last two paragraphs aren't relevant here.  (Though you do make a good point
that's relevant to the other bug on this subject).

> The problems I state are fundamental...

I don't see any fundamental or inherent problems with what I want to do, so let
me go through some of the cases you presented then.  If this explanation doesn't
work, I'll just have to try using code to explain it...  :)

> You'd have weird situation where the user would try to move or resize a
> window and it would suddenly jump somewhere else on the screen since its now
> a user action and not an application action

No.  User actions are less stringent constraints; any application movement that
previously occured puts a window in a position where it will obviously satisfy
any user constraints.

> or the user puts a window somewhere but then the application resized itself
> and jumps somewhere else because its not subject to a different set of
> constraints.

Also no.  When the user moves the window such that it isn't entirely on the
viewable workarea, the "on-workarea" bit gets cleared.  The constraints are
based on that bit, so the when the application later resizes itself it will
still satisfy all constraints.

(To restate, you could say that my proposal only distinguishes between user
actions and application actions by allowing user actions to clear the
on-workarea bit.  My proposal uses the value of the on-workarea bit (not the
"user action vs. application action") to determine where the window is allowed.)

The on-workarea bit is probably OK since you're not allowing important
constraints to be violated, so it doesn't have the problems of the onscreen bit
(though be careful with off-by-one errors when you do the rectangle intersections).

Though one potential problem is that you're going to be expanding the set of
possibilities that lead to there being no solution to the
constraint-satisfaction problem imposed by all the contraints.  In this case,
the constraint-solver will end up leaving the window in a position that violates
some difficult-to-predict set of constraints.  We may end up needing to add code
to either relax the extra constraints or to try to find a position that violates
the fewest constraints or some other heurisic.

You guys have no idea how long it would take me to review a constraints.c patch
;-) My inertia would be terrifying.

Elijah you're right that my worry about moving-in-response-to-resize was crack.
We already do that pretty often.

Given that, I think this bug could have a very simple solution. If a window
expands vertically by configure request such that it would extend outside the
work area, just change the configure request to also move the window upward;
never move it upward off the top of the work area though.

This change would not be a new constraint or change the constraints code,
instead it would "edit" the configure request.

The same could be done for horizontal of course, but less important probably.

Just one thought. We'd have to try it, it might not work.

Havoc, your idea may solve this bug but then we would need separate solutions
for things like bug 122196 (windows get placed underneath vertical panels) and
the problem with windows specifying offscreen coordinates for their original
placement when the windows are small enough to fit on the screen (one example of
which would be bug 147384).  We might be able to tailor a solution to each case,
but I feel like we would be attempting to enumerate and workaround a bunch of
cases (of which we may not yet know all that exist) which could be solved
simultaneously by just enforcing the correct constraints...  Anyway, for what
it's worth, that's my $0.02.  :-)

You aren't wrong, but I am still really unhappy about constraints.c...

Well, after spending a while looking at it last night for a different bug, I'm
not so happy about it either...   :-(

Just for reference: It looks liks this proposal would also fix a set of
accessibility bugs; see bug 167367 and bug 156699.

While I don't know if we'll be able to fix this in time for 2.12, I'm going to
throw it on that target milestone anyway.  I really hope we can get this tackled
by that time...

*** Bug 169395 has been marked as a duplicate of this bug. ***

*** Bug 318203 has been marked as a duplicate of this bug. ***

Would it be hard to implement it that way that the window is centered on the
screen as if it would be expanded? 

Almost filed a dupe of this - maybe adding words "filechooser" or "file dialog"
to the summary could help?

and, yeah guys, great job, thanks and respect for that!

This particular bug has been fixed on the constraints_experiements branch. 
However, please note that the code on that branch isn't ready to be merged to
HEAD yet (in particular opening a dialog from gedit in order to test this bug
seems to cause it to crash, meaning I have to restart at least once in order to
test this particular issue...)

[Cue Wizard of Oz music]

Ding! Dong!  The bug is dead!
The wicked bug,
The wicked bug,
Ding! Dong!  The wicked bug is dead...