GNOME Bugzilla – Bug 440649
Better handling of modal / message dialogs, especially Save Changes
Last modified: 2020-11-06 20:07:55 UTC
Modal dialogs like Save Changes are currently represented by what looks like just another normal window. This doesn't do the close relation between document window and dialog, the combined focus and minimizing, justice. Centering the dialog on the document window obscure the likely most informative part of the document results in quite some distance between the doc windows close button and the dialog buttons (which a user that prefers mousing will have to cross). Also, the dialog should not have title bar close button, as it is unclear if it means cancel-close or do-whatever-close. Please see: http://thorwil.wordpress.com/2007/05/20/save-changes-integrated-3/ Addition: On how the dialog would be movable and how that would be discoverable: It could be moved by dragging on any non-text part. This would be discoverable by changing the mouse cursor to an 4 way arrow or maybe a hand. Alternatively, there could be a handle bar on the top. An alternative to all above that would require window resizing: http://thorwil.wordpress.com/2007/05/18/save-changes-integrated-2/ Other information:
You wouldn't have to do the four-way arrow business: there's no reason the window can't have a titlebar even if it doesn't have a titlebar close button. So let me see whether I understand what you're saying: 1. Making the close button change appearance if there are unsaved changes. I like this idea (although you run into the problem that it now looks just like Vista's close button), but that's a GTK problem and not a Metacity problem. 2. Removing the close button on all "save changes" dialogues? or all modal dialogues? We could remove the close button from *all* modal dialogues, but the application authors would probably be kind of upset with us for doing so unilaterally. It's not trivially obvious which dialogues are "save changes" dialogues, so it'd be harder to remove the button just from those. If you want to make a general rule like this across the desktop, the thing to do is to make it policy and then get the application authors to implement that policy. The people you need to talk to about this are the HCI team. 3. Don't put modal dialogues on top of their parent windows. You've made an interesting case for this. So, where should they go instead? This is also something HCI would probably like to be consulted about.
Even an empty titlebar would still imply a double-click action (maximize, roll up and whatever the 3rd option was). On 1: It's a theming issue, yes. On 2: Removing the close button from all dialogs that have action buttons of which one has the same effect as the WM close button. On 3: top right as in my mockup moves the dialog close to the parent window's wm buttons and minimizes the obscured canvas area. If the parent window leaves enough screens pace, the dialog could appear attached to the right, left or bottom edge, with a little overlap, perhaps.
Well - I hope I'm not too false wiht my opinion here: Most dialogs should not be modal. At least 'save'-Dialogs shouldnt. Why? Because the file might be a class DoubleBufferImageFactory which should be named DoubleBufferImageFactory.java. You open the dialog, and the class-name is hidden, and you can't pick it from the file, to enter it in the save-dialog. You have to close the dialog, copy the name, open the dialog again... I wrote a bugreport for launchpad here: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/363945?comments=all but they told me to use bugzilla.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.