Community
Participate
Working Groups
As part of our current plan to eliminate dialog boxes from Eclipse, an easy candidate could be the preferences dialog. Rather than hosting this content in a dialog box, I'd suggest the following behavior: - The content of the editor can be essentially the same as the current content of the dialog box, including the cancel/ok buttons in the lower-right. (*) - Enter and escape would no longer dismiss the dialog (there's many preference pages where these keys are useful for other purposes). - "Saving" the editor would do the same as the "Apply" button. - The editor would be dirty if and only if there are unsaved changes. - The editor will have a shared working copy, so multiple preferences editors can be opened at the same time and will share the same state. (*) I'm proposing that we keep the look & feel the same as the dialog box initially since it's easy to do and familiar to existing users... but having a nonmodal editor may offer some cool new UX paradigms in the future. If anyone has a UX team at their disposal, it may be neat to explore somem other possibilities.
+0 changing the preferences is not necessary a regular task, so this change will not result in a lot of benefit. I think we move other items which would help the goal of avoiding dialogs much more, e.g., Bug 99294.
> +0 changing the preferences is not necessary a regular task There are a number of preference pages which require copying-and-pasting stuff from other locations such as the code templates preference page, the Available Software Sites page, and any preference page that accepts a filesystem path. Currently, such pages require closing the preference dialog, copying what you need, then reopening the preference dialog to paste. Some workflows require doing this multiple times in a row. This has often been a source of inconvenience for me and I believe that if the preference dialog were available as an editor people would actually start using these features more often.
(In reply to Stefan Xenos from comment #2) > > +0 changing the preferences is not necessary a regular task > This has often been a source of inconvenience for me and I believe that if > the preference dialog were available as an editor people would actually > start using these features more often. I'm not against this change, and solving a personal inconvenience is one of the best motivations.
New Gerrit change created: https://git.eclipse.org/r/81976
(In reply to Lars Vogel from comment #1) > +0 My opinion has evolved (I recently had the case in which I needed a non blocking preference dialog). +1 for this change.
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/81976 Here is a WIP patch that already allows to play with such an editor for Preferences. It's accessible via "Open With" on any resource at the moment. My first impression with an editor for preferences is that it is great, much better than a dialog, and that preferences match properly the concept of an editor (edit, save...) so it's not disturbing for users. The main issue I see right now in term of UX (there are other issues, but not very important and that can be easily fixed) is that there is no way to properly set a "dirty" state. So the current behavior is to always mark the preference editor dirty.
(In reply to Mickael Istria from comment #6) > (In reply to Eclipse Genie from comment #4) > > New Gerrit change created: https://git.eclipse.org/r/81976 > > Here is a WIP patch that already allows to play with such an editor for > Preferences. I like the result. Regarding the dirty event, you could hook up on PreferenceDialog.setValid(boolean) (i know this not a true reflection of a change, but at least it will make the dirty state change when a page is changed and the change is valid)
By 4.7.M4, it would be nice if we could ship it into the IDE, as opt-in and experimental: there would be a preference to use an editor for preferences (marked as experimental). Same for project settings. I'm assigning this to me as I've started a patch for that, but any help would be really welcome!
I have recognized that this is worked on in todays talk by Lars. I personally don't like editing the settings of my IDE in an editor. IMHO that should be separated and I like the preferences/settings dialog to change these. Editors should be used to edit content with the IDE, not content of the IDE. I also heard remarks from Mac users that this would break the user experience on Mac where you expect a dialog to come up for such settings. But to be honest, I am not a Mac user so I can't say anything more about that. Nevertheless I totally agree that the dialog should be non-modal to be able to interact with the IDE in case you need to copy&paste something.
(In reply to Dirk Fauth from comment #9) > I personally don't like editing the settings of my IDE in an editor. IMHO that > should be separated and I like the preferences/settings dialog to change > these. Don't worry, there would be a preference to decide how to show the preferences ;) > Editors should be used to edit content with the IDE, not content of > the IDE. Ok, and what do you think about editing project settings in the editor area? > Nevertheless I totally agree that the dialog should be non-modal to be able > to interact with the IDE in case you need to copy&paste something. I didn't find a bug on this topic. Can you please report one and link it as see-also?
(In reply to Mickael Istria from comment #10) > (In reply to Dirk Fauth from comment #9) > > I personally don't like editing the settings of my IDE in an editor. IMHO that > > should be separated and I like the preferences/settings dialog to change > > these. > > Don't worry, there would be a preference to decide how to show the > preferences ;) I know, Lars mentioned that. I just wanted to document my remarks at the right position, so later nobody can say "you didn't raise your hand" ;-) > > Editors should be used to edit content with the IDE, not content of > > the IDE. > > Ok, and what do you think about editing project settings in the editor area? Good question. From the perspective of an Eclipse user a project setting is something special to the IDE. The files are typically hidden to a user. Therefore IMHO the dialog should also stay. But for so called "power-users" of Eclipse it could be quite useful to have a nice editor for the project settings. Such a user typically knows where to find the corresponding files in the project .settings folder. And if some refactoring went wrong and you need to fix it, you need to be able to edit that file in a more convenient way. > > Nevertheless I totally agree that the dialog should be non-modal to be able > > to interact with the IDE in case you need to copy&paste something. > > I didn't find a bug on this topic. Can you please report one and link it as > see-also? Done Bug 506677
> there is no way to properly set a "dirty" state. So the current behavior is to always mark the preference editor dirty. Despite I like A LOT the Preferences in editor, I have to admit that this really looks bad, incomplete and can easily make users anxious as there is no way to know whether their changes were actually saved, and it makes the editor feel buggy. I've had another look, but it seems to me that this problem doesn't have a solution, except by adding dirty management on Preference Pages interfaces and all extenders; which seems to not be affordable. In the last patch set, I've added the preference to decide whether preferences should be shown as dialog or editor. Maybe this could be merged "for the fun" and to encourage further work on this domain, but I do not see any end-user preferring the editor over the dialog as long as this issue of dirty state is there (~= forever).
Note that we could also make the PreferenceContainer being a IPropertyListener and the PreferencePage being ISaveable and write the glue. Would it be worth it?
As explained in comment #12 and comment #13, I think we still need important stuff before we can consider going for an editor, so I remove it from my TODO-list and from any target. A preleminary change would be to implement a "dirty" state per PreferencePage and to let the dialog use it; then making an editor would be doable.
Removing target as this seems realistically not worth the effort right now, although the idea is still worth keeping this ticket open.
