Comments on: Save Changes Integrated 2

By: Sven Neumann

Sven Neumann — Sun, 20 May 2007 13:49:37 +0000

BTW, your argument with Alan about the Close button is most probably a misunderstanding. He talks about Close buttons in the action area of dialogs and I think you are talking about the Close icon in the window decorations.

GTK+ 2.10 has API to convince the window manager not do draw the Close button in the window frame (and some window managers might even respect this). This might even be useful in some cases but it is not possible to change this after the window is already visible. So it wouldn’t work as you suggested it here.

By: Sven Neumann

Sven Neumann — Sun, 20 May 2007 13:35:49 +0000

If the title bar is your concern, use a window manager that doesn’t draw a title bar for transient dialogs.

By: thorwil

thorwil — Sun, 20 May 2007 11:58:58 +0000

Sven: The problem with the Save changes dialog is actually much the same for all modal dialogs refering to document windows.

The current dialog already shares focus and minimizing with the document window. That’s good as hiding only one of the 2 would lead to an ugly situation. The dialog being a separately movable window is only useful to move it off the canvas for free sight. If you want that, we can do better by automatically arranging things (within the limits of screen and window size). If you don’t want that, having a separate window with its own title bar is useless.

Like said earlier, for too small windows, the dialog part could be larger, resulting in the shape of 2 overlaid rectangles.

I guess this would be easier to do on a WM level.

By: Sven Neumann

Sven Neumann — Sun, 20 May 2007 11:14:49 +0000

Looks a lot like the messages embedded to the image window, that I proposed years ago. However I don’t think that this concept it well suited for things such as the Save Changed dialog (and fail to see the problem with the current approach). But it would probably be a good idea to use it for informational messages. I once spent a weekend trying to implement this but found that it’s rather difficult to get right. Especially since GIMP windows are often too small for the message to be displayed. And enlarging the window is not an option.

By: thorwil

thorwil — Sat, 19 May 2007 07:31:46 +0000

Alan: screenreaders can’t read the buttons? And as what is a WM close button on a dialog read? If it is just close, it’s the same problem of uncertainty about whether an action is carried out or not.

mpt: When working on icons, I have my image window large enough to contain the menu bar and for zooming in.
But for small windows, the dialog part could be larger than the document part below.
For very wide windows, I would limit the width of the content of the dialog part and left-align the whole block.

By: mpt

mpt — Sat, 19 May 2007 03:50:54 +0000

Ironically, the Gimp is perhaps the best example of a program where this design wouldn’t work well. In the Gimp, unlike other apps, a window can quite often be much narrower (e.g. when editing an icon) than the confirmation alert needs to be.

A program like OpenOffice Writer would have the opposite problem: the window would be much wider than the confirmation alert needed to be, so the alert would be distended and difficult to scan.

Well done for continuing to think of new ideas, though.

By: Alan

Alan — Fri, 18 May 2007 23:56:53 +0000

Close buttons can be read by screen readers and are way more obvious to
users than the window decoration only.

There is also the matter of certian themes (or even window managers) not
providing a suitable X in the window decoration. Most do but that
historical possibility makes us very reluctant to leave out the close
button.