Re: #101293, again

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-12-15 at 15:31, Federico Mena Quintero wrote:
> On Thu, 2003-12-11 at 12:31, Gregory Merchan wrote:
> 
> > The presence of the window manager close button on modal dialogs is
> > itself a bug. On this point, even Windows and MacOS HIGs agree, though
> > for Windows the button may be just disabled. The reasons are plainly
> > stated in Cooper's About Face 2.0.
> 
> So, a few things about the change I'm about to make:

I think that it's premature here to decide on the API without having
a solid idea of what the user interface should be.

I've asked Federico to back out these changes until we actually
have some sort of consensus, and he has nicely agreed to do that.

Regards,
					Owen

> 1. Hitting Escape will activate the "close" signal.  We need this signal
> due to the way actions and bindings work.
> 
> 2. The default signal handler for "close" will synthesize a delete_event
> on the dialog.  No checking for Cancel buttons or anything like that.
> 
> 3. If you don't want Esc to close the dialog, or if you want to pop up a
> confirmation window or something, just connect to "delete_event" and
> override the signal.  This is what you do to do, anyway, if you have a
> toplevel document window and want to present a close-confirm dialog when
> the user hits the window manager's [X] icon.
> 
> 4. Not having an [X] icon in a window frame is the shared job of the
> application, which should indicate that the window does not support that
> function, and the window manager, which should note that and not paint
> the icon.  If the GtkDialog API can help in any way here, please make
> suggestions!  Otherwise, you can just call gdk_window_set_functions()
> and hope that the window manager will do the right thing.
> 
> 5. You *will* get delete-events even if you disable that function in
> your application, as the user may be running a sucky window manager.  So
> the best place to override things, anyway, is the delete-event handler.