A Sun-requested change introduced this problem:

2003-01-06  Arvind Samptur <arvind.samptur@wipro.com>

	* src/window.c: (constrain_position) don't apply
	offscreen height difference. This would get the
	window under the panel on a resize or a move.
	Fixes #102418

So, make up your mind which bug you want, then let me know. ;-)

thanks for filing this Calum.

Havoc, I think the bugfix was bogus.  It is reasonable for tall
windows to be initially positioned with upper-left corner (or
whatever) tiled against docks, but it makes no sense to prevent
windows from being moved under docks; if you do, then you can't use
oversized windows at all, which would be an accessibility stopper (and
probably a stopper for other folks as well).

Many GNOME2 dialogs are taller than 560 pixels or so even using 12
point font, some are too tall with 10 point fonts, and I am surely not
the only person in the world still using an 800x600 laptop display.

I also think this bug needs to be evaluated in the light of the
'maximize oversized windows' behavior which causes gnome-terminal
grief - if we auto=maximize windows that are too big (if they are
resizeable), then we should just make them fit the area not occupied
by docks.  For non-resizeable windows, there's obviously no way to
prevent them from being displayed "under docks" so that behavior is
NOTABUG.  I think the bug regarding their initial placement makes
sense, but probably needs to take into account window-gravity, etc. in
deciding which parts of the window to place "offscreen" (i.e. outside
the available area after the strips occupied by DOCK windows has been
subtracted).
 

I bumped the severity of this bug up, since IMO it's a blocker for
many use cases and dialogs.  For instance, 

* on my laptop, I can't access the bottom of many capplets, including
keyboard-accessibility;
* most dialogs go offscreen if you choose the LargePrint themes and
font sizes (18 point).

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

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

My problem here is that I just don't believe most users know about
Alt+click, and I know a lot of titlebars used to end up under panels
or offscreen before metacity had the constraint. Plus, it's nice to be
able to slam windows to the top. So there are significant advantages
to the constraint for most people.

On the other hand, the case we're trying to fix is people using broken
applications, with crap monitors you haven't been able to buy in 5
years or more, or people with low vision using a friend's laptop
(their own laptop has a large screen).

So what I'd like to do is drop the constraint on Alt+click or keyboard
move only, as someone suggested. I would like to keep the constraint 
for moving via titlebar drag, for initial window placement, and 
for application configure requests. This can be implemented with a 
flag to meta_window_constrain() (post-constraints-code-rewrite 
bug #107010) that changes the "titlebar not offscreen" constraint to 
"bottom edge onscreen", and automatically pretending that flag 
is enabled if the titlebar is already offscreen.

I think that's a good solution...

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

hi Havoc:

In your low-vision comment you are missing an important point;
low-vision users will usually choose the minimum resolution available
on a given machine, i.e. they will choose 800x600 or even lower res if
it is available, in strong preference to a higher resolution.  That's
because they want big pixels, small pixels are just a pain for them.

BTW my laptop is not that old either ;-)

I think enabling this for keyboard nav only might be OK, as long as
any other programmatic means of moving the window also works (i.e. as
long as I can do this via libwnck, for instance, or via gdk).  I am
not sure what programmatic means we have at our disposal currently,
but we will need te capability for an external app to ask the WM to
move windows around, including moving the titlebar off-screen.

*I* certainly know about Alt-click, and I think a fair number of users
use this now.  Why in the world would we disable that capability? 
This I don't understand; if few people use Alt-click, then there's no
reason to constrain it; if many people use it, then there's reason to
expect that window titlebars can be moved offscreen.

I agree about initial placement, but I think Alt-click should allow
placement of the titlebar offscreen just as it allows placement of the
window bottom border offscreen.  The current asymmettrical behavior
doesn't make sense to me.

Allowing libwnck/gdk to do it will result in lots of buggy titlebar
offscreen cases. There are tons of apps that 
ask to be at 0,0 and that will land them under the panel.
This then interacts with panels always being on top, and leads to 
people wanting panels on the bottom. It's a delicate house of cards.

Losing titlebars offscreen used to drive me crazy with sawfish.

The reason it's top and not bottom is because the titlebar is what you
use to control the window, and the restriction is on the titlebar, not
the window. The point is to not lose the ability to control the window.

I think there's probably some way to reinstate the "if window is
larger than screen allow it offscreen by the amount it's larger" rule.
I'll try to figure out how the code should work after I finish the
constraints rewrite. Then only buggy apps can get hosed and land under
the panel.

Hi Havoc:

I take your point about apps that want to be mapped at (0,0); however
we still need a means of asking the WM to scroll windows at least far
enough to get all their pixels onscreen.  So although we may not want
to honor such gdk requests, we need a way to tell the WM "yes, I
really, truly do want you to move the titlebar offscreen".  

The reason for asking for this in libwnck in addition to allowing it
via Alt-click and Alt-space->move is because (for instance) a GOK user
might want to move a window around, without having to synthesize 8-12
keystrokes (each of which is a complex selection action).  Instead of
forcing such a user to synthesize Alt+space+down, down, down, space,
.... etc. it would be nicer to supply a "move window up" button that
the user could select and hold, whilst GOK makes the relevant libwnck
calls.   I hope that use case makes sense to you.

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

I do not know if this is possible, but i would like to suggest, that
in case that a window is too big, metacity will stick on the side of
the X window a scrollbar, that will let you to 'scroll' the whole
window. I believe this is a much more obvious solution, will look much
better while keeping all of the window inside the screen, and is more
simplistic (atleast for a 'joe' type user).

So the whole 'click'+drag hack wont be needed, and also, for a simple
accesibility user, this will make much more sense.

Thank you for your time!

I don't think a scroll bar would be the best option, but a "handle" to
move the window with when the titlebar is obscured on the side of the
window might not be a bad idea.  Not sure if its worth the substantial
effort required though.

But that adds to the hassle of what if the window is too wide...
Take for example the 2 weeks old CVS of abiword. If you maximized it
on a small resolution, half the window would popoff screen and only
the middle would be visible. Now if you maximize it, parts of the
toolbar popoff the right hand side.
Ture, that this is an application bug, and it should have x,y & z so
that as not to do it, but i am just using an 800x600 res. Some
accesability users use less, and have bigger toolbars with different
apps. Also making users have to start moving an app by the toolbar if
the app is too wide is not very 'UI friendly' to those who encounter
it often.

I would think a much better solution would be to find out a better way
to manage windows which dont fit on the desktop. This is an important
usability problem IMHO. Especially with the more 'ui complex' apps
like evolution, etc... on small resolution. I am suprised that no
other wm has any support or fixes for it, and it would be great if
metacity were the first one to have it.

A good a simple solution needs to be found rather then <alt>+click
which wont be that obvious to a simple user, who needs it.

And i think adding somthing simmilar to a scrollbar to be able to 
scroll the window if its too big would be an ideal solution. Its
simple intuitivly, works for both vertical and (the bit common)
horizontal, fixes the simmilar bug with 'faulty' apps.
</rant>

Thank you for your time.

This is a really interesting discussion.  I think the idea of making
the window manager put oversized windows into WM-managed scrollpanes
is pretty cool, but possibly labor-intensive.

My reaction is that we could do this (provide convenient ways to move
windows) from apps other than the WM as long as libwnck allows us to
programmatically move a window _anywhere_ onscreen.  But that doesn't
solve the problem for users who aren't running some special
window-move-thingy.  Agreed, the WM is supposed to be our "window move
thingy", it should allow us to do those window move operations that
are important to us.  

So there are two issues:

* WM should allow windows to be mapped with titlebars offscreen, in
theory (even if default placement is designed to prevent this);
corrolary to this point is, libwnck should allow apps to do this
programatically.
* WM should allow user to move windows as above via both mouse and
keyboard operations (currently it allows neither).

Is that an OK statement of the problem/requirement?  Use cases have
already been discussed above.  

> * WM should allow windows to be mapped with titlebars offscreen, in
> theory (even if default placement is designed to prevent this);
> corrolary to this point is, libwnck should allow apps to do this
> programatically.

And how is this supposed to stop the follwing case:
A user an app open with the title bar as high as possible and a panel
on the bottom of the screen. the user closes the application, and the
app saves its position and state into GConf keys. The user moves the
panel to the top and then reopens the app. The app sets its position
based on GConf kets and now the app has its titlebar hidden under the
panel and cant move the window.

Maybe provide a different way of moving windows (like seperate
functions in libwnk) that allow forcing the move, but should only be
called by apps in severe need.

> * WM should allow user to move windows as above via both mouse and
> keyboard operations (currently it allows neither).

Why should a user be able to move a window offscreen?
If there is a descent and real accesability solution to this problem,
then there is really no need for the mouse & keyboard movement.

Obvioussly, if metacity has no way of doing this, then the
mouse&keyboard movement should be enabled, but that IMHO is a 'hack'
(in terms of UI correctness and accesability) that should be fixed in
a better/'more correct' manner

Perhaps we should include middle-mouse dragging on the frame to move
windows, a feature found in some other window managers.

Also, we could consider a window menu option "Move Titlebar Onscreen"
to windows where the titlebar is off screen.

Not sure if these are good solutions though.

dbrody: I didn't say the WM could not move a mapped window in response
to changes in the placement of WM_DOCK windows; one would expect the
WM to act in such cases.  And apps that set their position via gconf
keys should be very much the exception, not the rule.

we already have alternate ways of moving windows whose titlebars are
offscreen; alt-spacebar pops up the WM menu.

Users need to move pieces of oversized windows _onscreen_.  That of
course means that other parts of those windows must be moved
_offscreen_, it's as simple as that.

It should be doable via mouse and keyboard, I need to do it on my
screen, other people need to be able to do it on their screen, and of
course it should also be accessible.  But this is not about some
special accessibility hack, it's about an already-existing "can't get
there from here" scenario for all users.

PLEASE let's not use middle-mouse, that creates horrible problems for
other reason, not only accessibility but lack of 30button support for
some users, etc.

OK, to clarify my moan about middle-button: it shouldn't be the _only_
way to do this IMO.  We already have alt-leftmouse for moving windows,
we should keep that.

However clamping the alt-leftmouse positioning so that the windowbar
is at the top of the desktop (i.e. not under any DOCKS or offscreen)
just makes no sense to me.  It's fine if we refuse apps that ask to be
placed there (say, via gdk_window_move), but the user is king, and
should be allowed to move windows in this way manually.  Likewise
libwnck should allow such explicit placement.  Unlike gdk_window_move
and such application API, we can be more forceful about what libwnck
clients are expected to do; I agree with Havoc that just honoring
application settings will result in ugliness, but honoring explicit
libwnck requests seems appropriate.  If someone misuses libwnck such
that windows' default placement is bad, that's their bug, not ours.

Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.

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

It would be nice to have _some_ way of moving window titlebars off the
top of the screen, even if it's not the normal mouse-drag way.
(Ctrl-drag?)

On 800x600, there are a few broken applications where the bottom of
the window is off the bottom of the screen, making things very
difficult. I use 800x600.

I think Alt-mouse should allow this; no need for a special (and
probably clashing!) keybinding.  If you find Alt-drag, then presumably
you can find it again to get the titlebar back onscreen if you need it :-)

This means that libwnck clients should be able to do this
programatically too.  Same logic applies to keynav Alt-F7 + arrow
keys; since those mechanisms don't rely on grabbing the titlebar
there's no need to clip the titlebar to the screen.  I don't mind if
we require that at least some fraction of the window remain onscreen
(and not under a panel), as a usability help, so you don't lose the
window completely, however.

Yes, I meant "the modifier you use to drag windows about the screen"
should allow this. On my computer, that's Alt.

This bug is REALLY, REALLY bad for accessibility.  Can we just agree
to fix it?

(I will arrange a patch if it won't end up going to /dev/null)

thanks.
Bill

I'm long agreed to fix it, the question is how. 

I'm open to any patch that *only removes the constraint if the window
is larger than the screen*

If the patch allows a window that fits onscreen to get its titlebar
lost, then that is a major regression.

I think just modifying onscreen_constraint in window.c is probably
right. Probably you only want the exception in the constraint for 
moving, and not in the constraints for resizing - because 
in the constraint for resizing, if your dy would move the window
offscreen, it would also resize the window to be larger, so 
making an exception for larger windows renders the constraint 
meaningless. You don't want an exception for resizing anyhow
I don't think.

So it should be a patch to constraint_onscreen_move_func. Note 
that you will probably get patch conflicts with Rob's changes 
to handle partial-width panel struts.

Thanks a lot Havoc.

I personally don't see why limiting this to oversize windows is best,
but it would solve the primary accessibility problem.

Regarding resizing: I do envision a need for the resize exception, for
applications/windows whose default or even max size isn't big enough
to display all the needed components and which don't make the best use
of scrollpanes.  This happens relatively frequently; for instance an
app may pick a "preferred size" which isn't big enough with using
large fonts.  

My suggestion is that we remove the constraint on user-resizing past
the bottom of the screen.  The user could subsequently move the window
such that the titlebar went offscreen but this would require conscious
action and intent on the user's part.  Thus for instance via keynav
the user could resize the bottom of the window past the bottom of the
screen.  The remaining question is whether in such cases it would be
preferred to keep the moving window border in-view (I think it would)
which would indeed scroll the titlebar out of view.  I do not
understand how this could be a regression since it would be an
explicit user-specified action.

Havoc: And why is allowing titlebar to get lost in case of
alt-leftclick move a major regression? I saw you mention that as a
possible solution, but then subsequently you seem to abandon this view?

Are we saying there will be no way for a power user to move the window
off the top if she so desires?

Why do you want to lose the titlebar when the whole window is already
visible? That's just useless. On the other hand, it's very useful to
be able to slam windows to the top of the screen and have them stop 
at the panel, and it's very useful if windows never accidentally 
or due to application bugs land underneath the panel, and it's very
useful if when you add a panel the windows move out from underneath
the new panel. All these things are useful for power users as well 
as regular users, notably I love these features.

So the exception should be only for windows that don't fit.

Yes maybe some people want to move windows out of the way, 
but there are several other ways to do that (move them to the side, 
minimize them, roll them up, close them, switch to another workspace - 
ok, more than several). So there is no need to break the 
benefits of keeping windows onscreen in order to achieve that goal.

The patch here is not that complicated, it is a whole lot shorter 
than the discussion... someone just needs to write it.

> Why do you want to lose the titlebar when the whole window is already
> visible?

Because this window prevents me to see another windows (see Bug
#115092) for example.

Why to top, not to the bottom?

(a) Because I alvays have panel at the bottom and never have panel at
the top of screen.  Very naturally is to move window to the "free"
corner instead of corner ocupied by panel.

(b) Because movement by hand in the direction "from the body to the
danger/source of exasperation" is reflex or, at least, more reflected
than movement in the any another direction.  And if in your hand is
mouse then this movement will be translated to the "move mouse pointer
in the Up direction on the screen".

And this list can be continued IMO.

Merely as summary: machine is stupid. Trying to do something by
default as good as possible, which makes intrusion of user unnecessary
-- great think, but machine is stupid.  And author of a program, even
genius author, is not a God anyway and can't foresee *all* situations.
 Therefore, jailing of user is the bad think.  And the "double bad
think" if this jailing can be easy avoided.

Is this a babelfish translation?  This last comment makes no sense at
all.  The reason you can't drag off the top is because that's where
the titlebar is...

> Is this a babelfish translation?
No, but my English indeed far from perfect :-(
If you know Russian -- I can send to you "original text".

> This last comment makes no sense at all.
???

> The reason you can't drag off the top is because that's where
> the titlebar is...
And I don't understand why this is the reason.
As for me, the titlebar is the same decoration as e.g. right-bottom
corner of the window (while I drag over keyboard or <Alt>+<Left-Click>
of course).

Havoc was do ask "Why do you want to lose the titlebar when the whole
window is already visible?" -- as answer, I show example for the
"Why?" and try to substantiate my opinion.

Or case is simple in the Russian structure of some sentences and you
just can't parse these?

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

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

Excuse me, Havoc, but changing Summary from
    Summary: Should be able to Ctrl+Drag off top of screen
to
    Summary: Allow windows offscreen by the amount they are larger
than the screen

is not right.

Request (at least my) not anly about "how to see offscreen part of
window", but also about "how to move window [mostly] offscreen in the
convenient to me direction".

Ansver to question the question "why?" already contained in this
discussion.  Search for phrase "Because this window prevents me to see
another windows".

Whether I should to explain why (again)?

If my English is too poor to be understood, please say and I try to
expalain/retranslate.

No, I'm not taking a patch for that. The patch I'm taking is an
exception only for the case where the window is too large.
Thus the summary change.

There's a tradeoff here, not everyone can be happy, the 
goals of:

 - allow slamming windows to edge
 - avoid accidentally getting windows under the panel
   (some apps for example try to hardcode a position at 0,0)
 - do the right thing when a new panel is added

all take priority over being able to move a window out of the 
way off the top, since there are several other existing ways to move a
window out of the way, and all of those ways are more visible than 
ctrl+drag. There's even the current possibility to move a window 
out of the way off the bottom or right of the screen, just 
not the top.

If you want the ctrl+drag feature you need to find a way to 
implement it that doesn't break the three bullet points I 
listed above.

To avoid having fullscreen-sized (but not ewmh enabled) apps pushed
below the panel, a simple hack which avoids the onscreen constraints
for such windows appears effective:

 constraint_onscreen_applies_func (MetaWindow *window)
 {
   return
-    !window->fullscreen &&
+    !window->fullscreen && !meta_window_is_fullscreen_size (window) &&
     window->type != META_WINDOW_DESKTOP &&
     window->type != META_WINDOW_DOCK;
 }

Right, but the general solution for "window larger than area between
the panels" should automatically cover that, so we don't need a
special-case hack.

Havoy, your "CRAPPY MONITORS" are high-tech in development countries.
For example, LCD monitors in Brazil are used only by people with LOTS
of money (they are on the desks of TV talk shows, for example). The
"standard" monitor in Brazil is 15" (max. res. 1024x768). 

Living in Brazil, I'VE NEVER SEEN a monitor running at 1600x1200 in a
decent (above 43Hz) refresh.

Please don't you never forget development countries, which are great
Free Software customers, for obvious reasons.

Fabio, I don't know what you are arguing about. The proposed fix 
addresses the monitor size issue.

Look, we know what change is needed here; it is not a large change; 
someone just code it please.

No more comments on this bug! patches only.

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

Created attachment 18747 [details] [review]
fix the bug

attached patch allows certain windows to break the topmost constraint
as follows:

If the window is resizable according to WM_NORMAL hints but not
according to MWM hints, then consider the "proposed" size as the
minimum size of the window.  Otherwise, use the WM_NORMAL minimum size
as the mimimum size of the window.  Then allow the window off the top
of the screen by the amount that the window is larger than the screen.

Doesn't do anything like require Ctrl-dragging, so theoretically those
running on itty bitty displays with top panels may end up with tall
windows popping up behind the menu panel.  Thems the breaks I guess.

Anyway attaching a second version of the patch that actually works.

Created attachment 18748 [details] [review]
fix the bug both for the mplayer case and the "big 'un" case

I haven't reallly followed this discussion, but instead of banning the
user from draggin the window titlebar offf screen, could
edge-resistance be used to strongly discourage this? Benefits, you can
still slam windows against the top panel, a11y users can still drag
them off screen, others will stop complaining. havoc?

that only addresses one of the three goals I mentioned.

I think that my patch above should be all things to all people. 
Anyone who needs to be able to drag a window bar off the top of the
screen ought to be able to do.  Broken fullscreen clients like mplayer
will work.  Dialogs that are too big will work.  And it's even smart
enough to be able to know that a dialog can simply be resized rather
than dragged off the top of the screen, so I think that most users
won't even notice what's going on; it will Just Work (TM).

If it wasn't clear, I believe that this is a complete implementation
of the consensus solution to this problem.

OK to commit?  We should definitely at least fix mplayer for gnome
2.4, since that's a regression from 2.2.

I don't understand the proposed_rect/mwm exception; is there 
a specific app that sets the mwm hint and not the normal 
hints?

In general I wouldn't expect this patch to work, since I would imagine 
for example many fullscreen apps resize to the fullscreen size
with a configure request, but don't set a min size that's fullscreen.
What am I missing?

Did you try just relaxing the "not off the top" constraint for moving
(but not resizing) a window with window->rect larger than the work
area? (relaxing by the amount the window is larger, of course)

the test case I was using was mplayer fullscreen mode, which sets a
mwm non-resizable hint but doesn't set the WM_NORMAL hints to indicate
non-resizable.  The proposed_rect thing is because the the app uses a
configure request to move/resize itself; and if I use the window->rect
for that, the window will never actually get the exception applied
since the window->rect is small until after the function is called, so
I added the proposed_rect stuff to apply the exception earlier.

This code works for mplayer, which was the only case I knew of for
this problem.  I also didn't want it to suddenly allow you to move
windows off the screen if you just resized the window, since I would
expect that might be confusing, so I thought it was worth some effort
to avoid this.

But I suppose I could remove the min_size stuff and just always use
the proposed_rect.  Or even better use the min_height only if the
window has a frame.  Perhaps that's the best way.

I believe using proposed_rect is equivalent to removing this constraint
altogether, or at least removing it for the top of the screen, so you 
could just as well use a flag "don't constrain top"

Maybe:
 - if the window has a frame and the minimum size exceeds the 
   screen's work area, remove the constraint for the top of the screen
 - else if the window has no frame, always remove the constraint
 - else leave it as it is now

nitpick department:
 - I'd use G_MAXUSHORT or something instead of 0xffff
 - braces around single-line if() bodies are kind of cluttered

some thoughts anyway.

The proposed_rect stuff isn't equivalent to removing the constraint,
since the outermost_onsreen function is used for move constraints, and
the exception will only be triggered if the proposed_rect is larger
than the work area.  So windows that are smaller than the work area
still can't be moved offscreen.  They could in theory be "resized" off
screen though, as long as the user is trying to resize it to be larger
than the work area.  Which is why I was only applying the
proposed_rect to a narrow class of windows.

Ah right, proposed_rect only removes the constraint on resize not move.
That's exactly the opposite of the right thing to do though, I think.
;-) I was suggesting removing it for move but not resize.

My previous comment though suggests removing it entirely in two 
special cases.

I think that you and I are really thinking of the same thing, but are
failing to communicate.  I'll write a reworked patch tonight; I think
that you'll be pleased with the results.

OK I'm attaching an updated patch that uses the frame as a
discriminator.  Windows with frames are assumed to set sane minimum
sizes for the purposes of being allowed off the top of the screen.

The problem right now is apps like the XMMS playlist that are
undecorated and are application-managed through configure requests. 
With these apps, it's possible to resize the application until it's
too large for the work area, and then move the top of it off the
screen.  Of course, for xmms playlist this is really no big deal,
since you can move it by grabbing anywhere.  I can't really think of a
way to improve the heuristic, however. 

Attached patch continues to work well for mplayer or dialogs that have
a minimum size that's too big for the "effective" work area, but
should work for a wider range of legacy fullscreen apps.

Created attachment 18839 [details] [review]
frame as discriminator

Created attachment 18849 [details] [review]
Untested patch

Attached patch shows generally how I think it should be done, though 
I probably screwed up some of the details.

To test, we need an undecorated resizable window and either test with 
keyboard resize, or the window will have to support _NET_WM_MOVERESIZE 
stuff on all 8 resize points.

Also fixes an unrelated bug, namely having onscreen constraints for
right/bottom resize didn't really make sense for windows that have to 
have the top left of the window onscreen anyhow.

I really don't see what the advantage here is over my approach.  In
particular the left stuff seems really unnecessary since you can
already move windows most of the way off the left side of the screen.
 So unless the workarea is less than 75 pixels wide...

Also, I'm not sure that disabling constraints completely for frameless
windows is what we want to do.  There are a number of media-player
type apps that have undecorated windows that should behave more or
less like regular windows.  (xmms, gmplayer, numerous others) Letting
them go completely off the screen seems like a mistake to me.  It
would be very easy for a shaded xmms to be lost forever beneath a top
panel.  It also seems very odd that we let it go off the screen to the
left or top but not the bottom or right.

None of these problems arise with the approach that I used.  With my
patch, undecorated windows only get as much leeway as they need; so
the effect is only noticable when the window is larger than the work
area, and even then it can only go offscreen by as much as it needs to
fit the lower edge of the window on screen.

This constraint-sidestepping stuff I think ought to apply as narrowly
as possible to ensure that every app works, but to remain as
consistent as possible in our behavior.

Your patch seems to also have some weird issues where resizing
undecorated windows causes them to jump around the screen, but I'm
sure those could be resolved.  Probably something trivial.

I didn't mean to comment on the details of which windows are
constrained how, so much as the proposed_rect thing. The constraints
framework very carefully works in terms of deltas in a particular
direction, and the patch here needs to preserve that.
The whole premise of constraints.c was to move away from 
"move rect A to rect B" (which is how the gnome-2-2 branch works)
and instead do "move delta in direction"

You're probably right about the left constraint, I forgot we'd let
windows go off the left anyhow.

Other changes in this patch include renaming bottommost_y to
bottommost_y_p because I feel having "bottom" vs. "bottommost_y" 
when both represent the same conceptual value is confusing;
and adding the check for disable_workarounds().

Created attachment 18852 [details] [review]
merged patch.  Uses deltas instead of proposed_rect.  Disables new code unless it's a move.

OK I'll buy that.  Attached is a merged patch that incorporates the
"best of both worlds".  Also, I disabled the new onscreen-sidestepping
code unless it's called from the move function, which seems like a
good idea.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

You still have the proposed height here. This code:
 minheight = window->rect.height + info->y_delta;
that is the same as "minheight = proposed height"
This is exactly the same as disabling the top constraint 
entirely, you are just jumping through more hoops.

To prove this to yourself, rewrite the code to impose a min delta
and/or a max delta (which is how all constraints have to work).
You will see that in this case your max delta is a function 
of the requested delta, i.e. your max delta doesn't exist.

Wait a second though; 
 minheight = window->rect.height + info->y_delta;
that code runs only if is_move, and in that case y_delta affects 
window->rect.y not window->rect.height; so does it even make 
sense to add it to the height?

yea the is_move stuff is wrong; I was going to remove it when I got
around to working on this again.  It should just run unconditionally.

I of course realize that what I'm doing now is exactly equivalent to
the proposed_rect thing, but you seemed to like the idea of a delta so
I changed it.  The simple fact of the matter here is that without
completely disabling the constraints for frameless windows, we
absolutely have to consider the size of the window as it _will be_
once the entire configure request has been serviced.  I realize that
what it does now is a hack, but it does that to get around a
fundamental limitation of the approach that the whole constraints.c
code uses.

I really don't see any other way of doing that without using something
functionally equivalent to the proposed_rect thing, or ripping out
huge chunks of constraints.c and rewriting, and I really don't think
that disabling constraints for frameless windows is the way to go.  If
you have suggestions, of course, I'm all ears.

But as it stands (once I remove the is_move stuff), the patch works
for every case I could come up with to test.

to address your comment more directly -- its true that the constraint
is essentially disabled for resizing, but only if the window is
already too big for the work area.  In which case this is the correct
behavior, since it's supposed to be able to show the bottom of the
window.  Am I missing something here?

As best I can tell if it was "only if the window is already too big
for the work area" then you'd use window->rect.height by itself, not
window->rect.height + y_delta.
With the delta included, it's "only if the window 
has *asked* to be too big" which means all requests are honored.

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

OK, I accidentally submitted a dupe, but made some good points.

CAN'T WE LET THE USERS DECIDE?

Some of us want this, some don't. Some want wireframe, some want no
minimize animation, etc. etc. etc. I really DO respect Havoc's goals
in improving usability, but this isn't PalmOS or something -- you have
to have a reasonable amount of knowledge to use Linux/UNIX in the
first place.

I guess I'm just getting uptight because I really like GNOME, and esp.
the recent Bluecurve work from RH, but can't stand to see it twisted
into a do-as-we-say desktop because of overly-pedantic issues. If we
all look at our actual, real desks, they're all slightly different --
they have drawers and a top and books on etc., but we like to choose.

I'm no KDE fan but like the fact that they let the USER decide on
their desktop, and not the whim of some developer. Without RH and Sun
, GNOME would get no exposure -- it must say something that all the
other distros CHOOSE to use KDE by default.

Sorry! This is just sad to see. Have a big, red "advanced options" box
so we can enjoy GNOME with the options we want, and everyone is happy.

J

Your comment has nothing to do with this bug. Arguments
about generalities belong on desktop-devel-list or 
other mailing lists.
 
In bugzilla, give specific rationale on specific bugs about what
configuration option should be added and why in order to address that
specific bug. Otherwise you make bugzilla impossible to use 
for actually discussing and tracking the technical issues.

OK, sorry for ranting Havoc. As said, it's because I do really like
GNOME (was amazed after seeing RH 8/9 Bluecurve, being a Linux user
since RH 5.1 and AnotherLevel). Just sometimes I can see why KDE gets
all the attention...

BTW, the rationale was in my initial report -- movement constraint
makes using Metacity pretty much impossible on low-res machines (and
we're talking 10 boxes at the course I'm running). The idea for only
alt+click for moving above the screen is good, and I hope to see it. I
won't rant again!

J

Well, that's why we're fixing this bug.  You don't have to be
melodramatic about it...

But back to the actual technical discussion:

Havoc, sorry I should have been more precise about what I meant
before.  We only allow the constraint to be violated when the
requested size is larger than the whole desktop.

However, tt's not true that all requests are honored, but requests to
resize off the top of the screen by frameless windows will be honored
(As they are now) but will result in the window being moved down until
the top of the window is visible (if the window is small enough) or
just until the bottom of the window hits the bottom of the work area
(if the window isn't small enough).

The reason for using the "proposed" size instead of the current size
is because programs like mplayer will "fullscreen" themselves by
issuing a move/resize configure request to be full screen and in the
top left corner.  In the constraints code, we do a move, then the
resize.  So if we use the current size of the window, when it does the
move constraint, the window will be too small to trigger the special
case.  So only if the window is resized and then moved in a separate
configure request would it work if we used the current window size.

Does this make sense?

Yeah, that makes sense. We need to step back and do the math
so the issues are understood, and then if we do a hack 
at least we know its implications.

Re-reading the comment at the top of the file, basically the issue
is that for any move/resize we have four deltas (motion X/Y, 
resize X/Y). Currently the code assumes that these deltas 
are unrelated; that is, modifying one delta does not affect the 
others. Or maybe more precisely; we move first and resize second, 
so we assume that moves may affect resize constraints but not vice versa.

The "proposed rect" solution seems to be: we 
assume the resize will succeed (be unconstrained), we let that affect
the move constraints, then do the resize constraints.

Another possible solution is: just do the resize constraints first, 
assuming that resizes affect move constraints but not vice versa.

Adding complexity, I think there was discussion on wm-spec-list about 
how to interpret a move/resize in terms of window gravity 
(does the gravity calc use old or new window size, etc.) which 
we need to understand.

I'm starting to think we need to go back to the 
old "rect A to rect B, is rect B allowed" code from the stable 
branch, and then rethink a new solution for the problem 
this delta-based code was intended to solve. I don't want 
constraints.c to become just a really elaborate and unmaintainable
way to implement "is this rect allowed?" constraints.

It's possible that configure requests have to be interpreted as 
"is this rect allowed?" and user resize operations have to 
be interpreted as deltas. In fact that seems kind of likely.
But yuck, what a mess that will make. On the other hand 
cleanly separating the "moveresize to rect" and "move an edge by 
a delta" codepaths conceivably simplifies _some_ of the code.

If we do a short term hack I think it needs to be in terms of the 
deltas, which probably has to mean "if no frame, simply disable
constraints"

OK I think that we're on the same page here again.  I'll experiment
with trying to resize then move; that may end up being the solution,
but I'm awfully hesitant to do something that drastic for a 2.4
release.  Though it might still get enough testing in the RC1 release.

I've worked up a version of the patch that works by doing resizes then
moves as opposed to moves then resizes.  It actually seems to work
really well.  I can't think of any reason not to just do resizes then
moves.  Was the original code done that way arbitrarily, or was there
a specific reason to do the move first?

I'm attaching the patch.  Play around with it a bit and see if you
can't find anything wrong with it (other than all the comments being
wrong now).

Created attachment 19207 [details] [review]
no proposed rect (or equivalent); just do resizes before moves.

ignore the metacity-window-demo stuff.  That was just for testing and
won't be in the final patch.

Also note that this still doesn't address gravity issues; the
configure request may not work quite as expected if the app sets a
weird gravity on the resize.  This is probably so rare as to never
actually happen though.

See bug 109553 for the gravity stuff and how to test.

The test-gravity results end up the same when resizing then moving as
when we move then resize, which was pretty much expected.

I'm not sure that it would work correctly if, for example, a program
tried to fullscreen itself setting southeast gravity on the configure.
 Which is what I meant when I said that it was probably so rare as to
never happen.

We should eventually figure out what's going on with gravity, but I
don't that that's a 2.4 thing.  Hopefully 2.6.

But could you perhaps comment on doing the resize then the move?  This
seems to me like the solution to this problem, and at least puts off
the day when we have to have two separate codepaths for constraints
(which I really hope never to have to see; I think we'd want to write
a constraint solver before we do that)

Let's commit your patch for now, and see what happens.

(Meaning your latest patch of course)

Committed.  Calling on anyone who might listen to test out their weird
apps to see if anything breaks.

I updated metacity this morning and now maximizing an epiphany window
is broken.  The window maximizes but it is shifted to the right.  I'll
attach a screenshot to clarify.

Created attachment 19240 [details]
Screenshot of a broken maximized window.

Can we open a new bug on the maximization issue?

This bug is kind of huge, and I'd rather have separate bugs for 
each problem with the current cvs metacity.

Havoc,

I opened bug 119988 for the maximize bug.

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

Created attachment 19366 [details] [review]
a hack to allow alt+drag off of the top of the screen

Hi.  I know this bug is closed and that my patch will not be accepted
fo r inclusion in metacity.  Many of the people who are likely to
receive notification of this posting, however, are people who have
expressed interest in the functionality that my patch impliments.

It's a total hack.  It uses an ill-placed global variable to determine
if an alt+drag is in progress and allows temporary suspension of the
constraint rules if so.  It then allows windows with a negative y
location to stay put.  It works for me, ymmv.

It addresses the 3 requirements listed above:
(1) you can "slam" against the top by dragging using the titlebar
(2) windows created at 0,0 (as 0 is not a negative number) are still
subject to contraints as normal
(3) creating a panel behaves as normal as well, again, assuming the
window has a non-negative y location.

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

unfortunately this fix seems to have regressed GOK; GOK's calls to
gdk_window_move_resize now seem to work very badly and result in a
continuously-shrinking GOK window.

it sounds like the current code does 'resize then move', which is a
problem for some programs that call gdk_window_move_resize, if the
resize would not fit on the screen without the corresponding move.

ouch.

yea we basically knew that would be broken in certain cases.  Fixing
it is hard though.  It may involve a very major rework of the
constraints code.

sounds like the current patch is not acceptable though - "the cure is
worse than the problem".

I have read the lengthy previous comments and I still don't understand
why we can't reverse the move/resize order, or else just make the test
for "allow this move/resize" a little more complex, so it can handle
the case where the result of a move+resize is still valid.

by the way, the 'gok problem' I refer to makes GOK unusable in GNOME
2.4.0, so it's a serious issue..  needs fixing before 2.4.1 at the
latest I'm afraid.

That was basically what the proposed_rect-style patches were doing. 
Could you try reversing out the "no proposed rect (or equivalent)"
patch and using the "merged patch." patch and see if that one works
better for GOK?

thanks Rob, I'll try that.  Is 'no proposed rect' the same as the
patch applied to HEAD (i.e. patch -r should revert it), or should I go
to CVS and pull pre-commit before applying proposed-rect ?

i _think_ you'll be able to do -R from HEAD but I may be wrong; some
other subsequent change could have broken that.

Let's create a new bug for remaining issues, this one is huuuuge. 
Of course the new one should link to this one for background.

I believe to fix all the issues someone is going to have to think
about this hard and really do the math and get it right. Understand
the comment at the top of constraints.c, and review the old GNOME 2.2
constraints code.

I am afraid my earlier comment may be correct:

  It's possible that configure requests have to be interpreted as 
  "is this rect allowed?" and user resize operations have to 
  be interpreted as deltas. In fact that seems kind of likely.
  But yuck, what a mess that will make. On the other hand 
  cleanly separating the "moveresize to rect" and "move an edge by 
  a delta" codepaths conceivably simplifies _some_ of the code.

Adding code that is mathematically equivalent to the "moveresize to
rect" approach from GNOME 2.2, yet 10x more complicated to understand,
is really not right at all. That's why I would not favor the
proposed_rect approach. If we're going to do it that way we should
just revert to the 2.2 code and find another way to fix the bugs in
user-driven resize.

If anyone is hacking on this, keep in mind that there's a test-gravity
program in the metacity tree that lets you test move, resize, and
moveresize with each window gravity.

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