This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFC] New Non-modal Dialogs


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

GIF image

GIF image

>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]