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 643597 - Attached dialogs not resizable, even by app request
Attached dialogs not resizable, even by app request
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 643765 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-03-01 15:57 UTC by Owen Taylor
Modified: 2011-03-21 23:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window: Allow resizing of attached modal dialogs (1.62 KB, patch)
2011-03-21 17:47 UTC, Florian Müllner
committed Details | Review

Description Owen Taylor 2011-03-01 15:57:18 UTC
GTK3 puts resize grips on all resizable windows. They are implemented by _NET_WM_MOVERESIZE grips.

But Mutter currently considers attached modal dialogs in no way resizable - not by keybinding action, not by menu, not by these messages.

So the grip simply doesn't work.

There's obviously a problem with figuring out how an attached modal dialog should behave when resized:

 - Should it recenter? This might make resizing feel weird - it resizes twice as much as you drag. (Don't know how it would feel exactly.)
 - Should it not recenter? That would look weird, and it would take a bunch of code to avoid the dialog bouncing back to centered at some unpredictable time.

If we consider the resizing to be a bad idea, we could try to communicate back to GTK+ that the window won't be resizable, but sometimes an attached modal dialog doesn't come up at the right size. We don't control the design of many apps, but they still must be usable. And for sufficiently complex dialogs - like a GTK+ file chooser in browse mode, trying to predict a "right size" that works perfectly for all possible content, font sizes, screen, sizes is *hard*, and maybe the user should be able to make the window bigger if it would be useful for them.

Another conceivable option would be vertical only resizing.
Comment 1 Dan Winship 2011-03-01 16:14:01 UTC
(In reply to comment #0)
>  - Should it recenter? This might make resizing feel weird - it resizes twice
> as much as you drag. (Don't know how it would feel exactly.)

If you hold down Shift while using the Rectangle tool in inkscape, it will draw a rectangle centered on the starting point (rather than having a corner at the starting point), which is similar. It feels a little weird, but not that bad.
Comment 2 Owen Taylor 2011-03-16 19:23:49 UTC
*** Bug 643765 has been marked as a duplicate of this bug. ***
Comment 3 Florian Müllner 2011-03-21 17:47:30 UTC
Created attachment 183968 [details] [review]
window: Allow resizing of attached modal dialogs

Currently attached modal dialogs are not resizable, but we don't
communicate this to GTK+, so the dialog may end up with resize
grips anyway. As a fix, allow resizing, but account for the dialog
being centered to its parent.
Comment 4 Owen Taylor 2011-03-21 23:23:08 UTC
Review of attachment 183968 [details] [review]:

Patch feels good, seemed OK to mccann as well. Think you need to check meta_window_get_transient_for() to avoid double resizing modal dialogs without a parent.

Resizing from the top is a bit weird, but if someone notices they can feel proud in noticing.
Comment 5 Florian Müllner 2011-03-21 23:27:59 UTC
Attachment 183968 [details] pushed as 5500c2b - window: Allow resizing of attached modal dialogs

Pushed with proposed check for meta_window_get_transient_for()