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: Modal dialogs again


Tom,

On Monday, May 21, 2001, at 10:43 PM, Tom Tromey wrote:

"Jim" == Jim Ingham <jingham@apple.com> writes:

Jim> Error messages like "Couldn't connect to target board" or "Your
Jim> program just crashed" certainly should be modal, and SHOULD be
Jim> dialogs.

I don't think these are similar enough to be treated similarly.

For the first, I agree, especially if there is some reason attached so
that figuring out the why of the failure to connect might reasonably
begin.

For the second, I think there are already plenty of other indications
that a program crashed. For instance the buttons ought to change
state (you can no longer "Next" a crashed program). The dialog that
pops up for this never fails to annoy. Or, to look at it another way,
shouldn't we also pop up a dialog when we hit a temporary breakpoint?
Or when a watchpoint is taken? Or a signal handled?

I don't agree about crashes. If the program just stopped at some random PC, the buttons became inactive, and I couldn't step anymore, it would take some work to figure out that the program has crashed. It doesn't seem like a great idea to put the use to this work when their program has just crashed. After all, you still have a stack, and local variables, so not all the UI is inert...

If there were a message in the status area, that might be enough. But it is easy to overlook the status bar - certainly when I was working on Insight we got bug reports which would have been obvious if the user had looked at the status bar. So I don't think a dialog box is out of line. OTOH, it would be nice for it to be a "don't show this dialog any more" type dialog.

Temporary breakpoints don't require dialogs, since they are things the user asked to have happen. When they looked at where the PC is, it is obvious. Watchpoint hits are more exceptional, but when you look at where the PC is, you will see a variable getting set which YOU asked to watch, so it would be pretty easy to figure out what went on.

Signals and crashes go hand in hand, since crashes are almost always signals... For the ones not SIGSEGV & SIGBUS, you might want to see a dialog.

I guess I don't find dismissing a dialog that onerous; having "Don't show me ones of these type again" controls can help out here...

Jim> 2) Configuration panels:

Jim> Does is happen right when you change one of the combo boxes?

Unfortunately Insight already suffers from confusion on this issue.
Sometimes I think the answer is yes, sometimes no. This is worse than
making the "wrong" choice for the modality of the dialog (or, rather,
confusion *is* the only wrong choice :-).

Yeah, but this argues for starting with the simplest model first, doesn't it?

Jim
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham jingham@apple.com
Developer Tools - gdb
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]