GNOME Bugzilla – Bug 52833
resize grips for all corners
Last modified: 2011-02-04 16:11:52 UTC
in gtkstyle.c and the gdk code that emulates resizing on lame wm's, only lower-right grips are handled
Created attachment 6713 [details] [review] Fix
The patch only does the GDK part, not the gtkstyle.c part.
Yes, so I've been told :) I'll try to fix it this weekend if it's OK.
Also, need test case... might be neat to have testgtk test which drew grips on all corners of a window and allowed resizing from all of them.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Moving some hard to fix bugs onto 2.4.0 milestone.
Anders, do you have any code to handle the other corners in gtkstyle.c ? The reason I'm asking is that I tried to implement RTL flipping for status bars (bug 96832), but I'm lacking the artistic talent to draw good-looking resize grips for the south-west corner.
I have code that handles SW, S and SE. Let me attach the patch.
Created attachment 11885 [details] [review] Patch to implement grippy drawing
Thanks. I've extended the code to handle the remaining edges.
Created attachment 11890 [details] [review] patch
The drawing patch looks fine to me to me; the resize-emulation patch is going to need updating for multihead and GTK+-2.2.
Drawing patch committed now.
Note for whoever works on the rest - the testgtk addition hasn't been committed, and should definitely go in.
I also think resize-emulation is broken for N, NW and NE.
I've committed the testgtk code for this.
Resize emulation is completely broken currently. Doesn't work on any corner. I tried it with blackbox and twm. Any ideas what needs to be changed here ?
I've fixed the typo which broke emulation. Here is a patch which seems to work for the other edges.
Created attachment 12205 [details] [review] patch
Patch mostly looks reasonable. Does it work right if the application has changed the resize gravity of the window using gdk_window_set_geometry_hints? It seems to me, for example, that if the window's gravity was static, you'd want get_origin(), not get_root_origin().
Testing reveals that you want to use get_origin () instead of get_root_origin () in all cases. Otherwise, press-release cycles on a resize grip give you jumping windows. But with get_origin () to code works with all gravities (tested on both blackbox and twm).
I spoke too soon. Things appeared to work, because twm and blackbox don't properly compute the reference point as explained in the EWMH. Testing the emulation code with metacity shows jumping windows for all gravitys but static. So I tried to fix this by using the reference point as moveresize_orig_x, moveresize_orig_y (should't there be a gdk_window_get_reference_point (GdkWindow *window, gint *x, gint *y) ? But this doesn't help. What makes me wonder is that xwininfo still reports Window Gravity State: NorthWestGravity even after I called gtk_window_set_gravity () on the window...
Remember that window gravity is different than resize gravity as defined in the ICCCM. You want 'xprop', not 'xwininfo'
Yea, remembered that shortly after writing above comment.
Ok, finally produced a patch that works with all gravities and all WMs with fully ICCCM-compliant reference point handling. I've tested this with Metacity. Unfortunately, these WMs are likely to implement _NET_WM_MOVERESIZE and don't need emulation anyway. twm and blackbox both exhibit jumping windows with this patch (even for NorthWest gravity, which is sad). But I think there is no real alternative to assuming ICCCM compliance, since the legacy WMs have probably all different bugs in the reference point handling.
Created attachment 12245 [details] [review] patch
The patch is not perfect though, even for metacity. Occasionally you can see edges wiggle around a bit which are supposed to stay put. E.g when dragging the north edge with gravity center, the south edge moves up and down by a few pixels. This may be due to the metacity implementation of moveresize or just rounding errors, don't know.
Metacity isn't using emulation mode, is it? So the confusion is just a metacity bug. Note that metacity will get confused if you try to resize a window off the top of the screen. It will constrain the window position but won't then compensate by decreasing the resize, result is moving the window's bottom edge downward. This is what the new constraints.c code is supposed to fix someday. There are a bunch of comments in there that attempt to explain it.
I forced testgtk to use emulation with all WMs for testing purposes. I noticed the fun effect you describe for the top edge also on the left edge.
Maybe the only way to make this work perfectly would be to temporarily change the window geometry so that we can get the desired effect without moving at all, just be resizing. But a) I don't know if gdk is supposed to muck with window geometry b) it would probably be even more broken with legacy wms.
The one suggestion I'd make here is that we probably should special case the south-east case to make it a pure resize rather than a move-resize, so at least we can avoid triggering WM bugs in that most common case. Other than that, the patch looks fine to me.
Since I'm not entirely sure how to implement this best (temporarily changing window gravity ?), I have commmitted the patch as is for now. We can improve the emulation if it turns out to be a problem.