|
| Re: Is there a way to change Eclipse preferences to open eclpise dialog boxes non-modal? [message #506307 is a reply to message #506218] |
Wed, 06 January 2010 16:32   |
 Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
On 1/6/10 10:21 AM, sixsigma1978 wrote:
> I find the default MODAL dialog boxes of Eclipse extremely limiting to
> my work. Once a dialog box is opened (saw windows->preferences) in
> Eclipse, you cannot do anything else (say compare two project
> properties) since Eclipse won't let u click on anything else until the
> OPENED dialog box is closed.
>
> Is there anyway I can change this so that dialog DONT open modal by
> default?
No, and there should not be, in my opinion. The decision to make a
dialog modal or not is made by the person who writes the code to create
that particular dialog. Some dialogs, like Preferences, only really make
sense as modal because managing the user experience otherwise would be a
nightmare, or because the app should not proceed until the contents of
the dialog have been dealt with by the user.
Many dialogs in Eclipse are (intentionally) non-modal, for example the
progress reporting for background jobs. If a dialog is modal it is
intentionally so. If you disagree with the modal-ness of a specific
dialog then feel free to discuss it here and/or enter a
bug/feature-request about it, but be specific.
Hope this helps,
Eric
[Updated on: Mon, 23 February 2015 13:45] Report message to a moderator |
|
|
| Re: Is there a way to change Eclipse preferences to open eclpise dialog boxes non-modal? [message #1385875 is a reply to message #506307] |
Wed, 11 June 2014 21:24 |
bohemian prodigy
Messages: 1
Registered: June 2014 |
Junior Member |
|
|
No, dear Eric, it doesn't help. I regularly find the fact that Preferences dialog is modal appalling because I can not see the effects of the changes on the fly. I have to close the dialog. To make it more annoying some aspects of the state of the dialog (i.e. the scroll bars, window size) get reset.
I understand that in order to properly have the dialog non-modal and consistent with application state, the whole paradigm has to be abandoned. Ideally, all changes have to be "OK'ed" immediately (in web ui terms, "onBlur.") If reducing amount of clicking is part of building good ui, this would make Eclipse have a better ui. "oh but what if Eclipse's user wants to just experiment with settings hitting cancel to go to original state of preferences?" the designer of the current ui may say. Well guess what, we can't see the effects of the changes until we press Ok anyway. The Cancel button is completely useless. If you want a useful safety mechanism that enables the user to go back to a previous preferences state, implement the stack of states and the Undo button.
I wouldn't expect Eclipse to make such drastic change this late in the game. But I have idea for a solution that allows Eclipse to ameliorate this modal preference ui flaw, keep the state of the application consistent with the state of preferences dialog and avoid major overhaul needed for implementing onBlur in Preferences dialog. Apply button makes the state of dialog consistent with state of the application. Make the dialog non-modal after user presses Apply and before he makes any other change to the state of the dialog. This is a trivial change and would make a HUGE difference in my experience with the IDE, my opinion of it and the likelihood of me recommending it.
I hope this is specific enough.
|
|
|
Powered by
FUDForum. Page generated in 0.03083 seconds
] 
Search
Help
Register
Login
Home
