Community
Participate
Working Groups
I20040113 We had an error in one of our jobs which runs when the selection changes. This caused the new Job error dialog to appear. But first I could not close it since it was automatically reopened when the editor got focus. After I noticed that the dialog isn't modal I could close it by first selecting another editor. There should be a way to minimize the dialog and then later bring it up again.
From bug 42858: I see an accessibility problem: If the dialog takes focus when it comes up, how can a blind user get out of the loop by only using the keyboard? I'm not aware of a shortcut to re-activate the editor when the non-modal dialog is shown. If the dialog wouldn't take focus when it comes up, how could a blind user activate the error dialog to see what's in there and to close it?
I agree that if the errors are not cleared from the dialog, there needs to be a way to open it back up again. It's also not intuitive that the errors don't disappear when you close it... I've had several people ask me why the same errors kept appearing over and over again. From looking at how this is handled in other products, one possibility is: The dialog could have both "Close" and "Hide" (or "Minimize") buttons. "Close" will discard all errors and close the dialog. "Hide" will just minimize the dialog. The most common case (Close) is that the user acknowledges the error and wants to throw it away. Hide is for the less common cases when several errors occur, errors occur repeatedly, etc, in which case it's useful to leave the dialog open to prevent the dialog from continually flashing in your face. The "Hide" button makes it more obvious to the user that the dialog is non-modal and can be kept open. Markus: I don't see any accessibility problem - the dialog has to take focus to cause the screen reader to read the dialog. The dialog can then be minimized from the shell context menu, which is keyboard accessible.
John: If the dialog could be minimized, that could solve the accessibility problem. But if I e.g. evoke bug 48502 in the current I20040127, I see no way to get back to the editor without clicking the mouse (the problem is not reading the error, but getting back to the workbench).
*** Bug 54346 has been marked as a duplicate of this bug. ***
Close now clears the errors in the progress manager.
I20041201-1139 Currently, there's no way to get the focus back to the workbench window with the keyboard alone. E.g. when you reproduce bug 79967, the error dialog keeps popping up whenever you close the dialog. The error dialog is not minimizable (any more?). A blind user has no way to get out of the loop. IMO, the non-modal dialog should look and behave like a (native OS) palette and give focus to the editor on F12 (like a detached view already does).
This was significantly reworked in 3.1 so these comments are now obsolete.
