This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: [RFC] New Non-modal Dialogs
- To: Keith Seitz <keiths at cygnus dot com>
- Subject: Re: [RFC] New Non-modal Dialogs
- From: Jim Ingham <jingham at apple dot com>
- Date: Wed, 16 May 2001 13:00:34 -0700
- Cc: Fernando Nasser <fnasser at cygnus dot com>, Insight Maling List <insight at sources dot redhat dot com>
Keith,
Two separate issues here... One is WHETHER error dialogs need to be
modal, and the other is whether Insight's Dialog class is particularly
good. There are long-standing Tk tricks to keep a modal dialog on top
of the window stack, and not hideable, etc... If you look in the
Harrison-McLennan book they have a good section on those tricks. I bet
the IncrTk dialog classes use them as well, though it's been a while
since I looked at this. So you shouldn't throw out Modal dialogs just
because the ones we have currently don't behave particularly well...
I personally think that an error dialog should be modal. What is the
intent of allowing error dialogs to pile up? It just allows the whole
application to get messy. So in this case, forcing the user to
acknowledge, and then going on from there is cleaner both in the code,
and in the UI. So if I were still working on the code I would certainly
argue against moving away from modal dialogs for this sort of thing.
BUT, I don't care enough to carp when I am not doing the work...
Jim
On Wednesday, May 16, 2001, at 11:08 AM, Keith Seitz wrote:
> Hi,
>
> I posted some notes on modal dialog problems. Actually, the problem is
> that all of our dialogs are modal. Really. Try opening a memory window
> and
> entering a bad value for a location. It uses tk_messageBox to display
> the
> error message. Without dismissing the dialog, try to do anything. In
> particular, drag the source window over it. Notice that the focus has
> been
> grabbed. The dialog demands attention, but does not keep itself raised.
> This is just plain bad. I really don't understand why the error dialog
> needs to be modal. I don't think it matters.
>
> To combat this, I've created an "IconDialog" class which is supposed to
> look/behave like tk_messageBox except without the annoying grab/focus
> problems. Right now, it only displays a single button ("OK"), but you
> can
> add buttons at will in derived classes.
>
> There is a base "Dialog" class which does very little, but it is
> explicitly ignored by ManagedWin, since we don't want dialogs to show up
> in our active window list. I plan to check modal.tcl and merge it with
> this, since I noticed it, too, had some problems doing the right thing
> (TM).
>
> I have also added an "ErrorDialog" class, which is simply a non-modal
> error dialog. I've put in some cheesy graphics for the icon. I'd like to
> change this, but for now, it looks like the Windows one. (Note: we are
> losing some native look 'n' feel with this. Does anyone care? If so, we
> need to do a lot more work to fix this problem "properly".) I will check
> if tk8.3 has fixed this problem before I go committing anything.
>
> The attached snapshots were taken on my Linux box and my Win2000 cygwin
> box. Both were opened via:
>
> (gdb) tk ErrorDialog::create -title "Well?" -message "How do you like
> it?\nI know, it's not perfect,\nbut it's a good start at getting
> something\nwhich works better than tk_messageBox."
>
> [Yes, you can also specify a "-parent" flag to center the dialog over a
> parent widget/toplevel."]
>
> These dialogs are non-modal. They will just sit there forever if the
> user
> does not get rid of them. This will replace all the calls to
> "tk_messageBox" for non-fatal errors.
>
> Sound plausible?
> Keith
>
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer