After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 333328 - Need constrain_titlebar_onscreen constraint to be written
Need constrain_titlebar_onscreen constraint to be written
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
trunk
Other Linux
: Normal normal
: 2.14.x
Assigned To: Metacity maintainers list
Metacity maintainers list
: 345522 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-04 03:18 UTC by Rob Adams
Modified: 2006-08-07 23:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Rob Adams 2006-03-04 03:18:08 UTC
Create a left or right panel not in "expand" mode, then make it quite wide to more easily see the problems.

Take a window and move it as far right as constraints will allow in a place where the panel doesn't cover, then move the window up or down.  The windows gets "stopped" when you get to the panel as though it were a top or bottom panel.  The only way to get past the panel is to move the window _all the way around_ the partial panel so that at no time does the window overlap.

I would expect that as you move the panel down, it would get moved to the left or right as needed, as it did with the old contraints code.

Also, if you move the window down, the contraint seems to be tied somehow to the _top_ of the window, so it happily allows you to have the whole title bar covered up, but then you can't move the window any further than simply having the title bar covered up.

With top and bottom partial width panels, I can take a window and move it up next to the panel, then move it horizontally left or right so that the title bar is completely covered.  Worse, once I do that, it seems to decide that from then on the titlebar can be offscreen and then I con continue to move it up off the top of the screen.

None of these movements ever involve "Alt".

I don't remember it being this broken before; was there a change made recently?
Comment 1 Elijah Newren 2006-04-27 20:25:32 UTC
*** Bug 333995 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2006-04-27 20:33:47 UTC
Note that this isn't just with partial struts -- see bug 333995 for how to get the titlebar under a full width panel by just resizing from the frame.

The problem is that I never implemented the keep-titlebar-onscreen constraint.  When I was messing around with edge resistance and trying different types of resistance, I experimented with an "infinite resistance", which I noticed effectively had the same desired effect as the keep-titlebar-onscreen constraint when moving or resizing from the top of the frame.  I then thought "gee, that seems to cover all the cases needed for a keep-titlebar-onscreen constraint so I guess I don't have to write it; I'll just keep this funny way of doing it since it'd mean no more work."
Comment 3 Elijah Newren 2006-04-27 20:37:35 UTC
So, this should be a good project for someone new.  The basic steps to fix this:

  1) Nuke the infinite resistance stuff in edge-resistance.c, including the
     allow_past_screen_edge data member of the RestanceDataForAnEdge struct
  2) add a require_titlebar_onscreen bitfield to MetaWindow similar to
     require_fully_onscreen and updated in the same ways
  3) write a constrain_titlebar_onscreen() function in constraints.c similar to
     constrain_partially_onscreen()
  4) Add a flag to meta_display_begin_grab_op() (and
     meta_window_display_begin_grab_op()) for whether the action was initiated
     from the frame; set a new display->grab_<something> var for tracking this
     and use it in constrain_titlebar_onscreen()
Comment 4 Elijah Newren 2006-08-07 23:56:51 UTC
I wanted this in 2.16 and with enough time to test, so I fixed this today just before releasing 2.15.34.
Comment 5 Elijah Newren 2006-08-07 23:56:56 UTC
*** Bug 345522 has been marked as a duplicate of this bug. ***