Bugzilla – Full Text Bug Listing
| Summary: | Validation dialog is now modal | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Simon Archer <sja.eclipse> | ||||||
| Component: | UI | Assignee: | Ankur Sharma <ankur_sharma> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | ankur_sharma, caniszczyk, curtis.windatt.public, darin.eclipse, jeffmcaffer, remy.suen | ||||||
| Version: | 3.6 | Flags: | curtis.windatt.public:
review+
darin.eclipse: review+ |
||||||
| Target Milestone: | 3.6.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 319940, 322637 | ||||||||
| Attachments: |
|
||||||||
|
Description
Simon Archer
It was made modal due to the bug #295878. This is a huge regression in the usability of the user interface. Please reconsider. Alternatively, enhance the user interface to make resolving dependency problems easier. I agree that making this modal is a big workflow regression. It was very convenient to have the list of problems and fix them as you go. With it modal you have to remember a couple prolbems, fix, validate, repeat... Very tedious. Of course it would be even better to have an explicit workflow for fixing the problems. Funny, I never realized it was non-modal. It's so in-my-face I never thought otherwise. :o Reopening due to Simon and Jeff's comments. To me, the dialog feels like it should be modal, it simply displays validation results. However, if it hurts your workflow that badly, we can look at alternatives. Could one of you look into making a fix for bug 295878 that doesn't require a change to non-modal? What ideas do you have for an 'UI to make resolving dependency problems easier'? In reply to comment 4: Yes, Remy, the dialog being non-modal is often a surprise, be it a pleasant one, to most people. It certainly was to me when I accidentally realized it. But being modal really does hurt the workflow, as Jeff describes. A non-modal dialog allows you to fix the problem in-place without having to remember what's broken, fix it and the re-validate: You just leave the dialog open and re-click the Validate Bundles button as you fix each problem back in the launch configuration dialog. Modality is a big problem for the launch configuration dialog as a whole, and frankly it would have been better to implement it as an Editor, but we cannot re-write history here. An alternative to making the dialog non-modal is to provide a way for the user to fix the reported problems and then re-validate from within the Validation dialog. For example, maybe the Validation dialog could suggest the bundles that, if chosen, would resolve a problem. But that's probably quite a costly operation and might not meet Eclipse's strict scalability requirements. Another option is to allow the user to add/remove bundles directly from the Validation dialog, but that would be duplicating behavior that already exists in the launch configuration dialog. There are no easy answers here, I'm afraid. The workflow issues are easy to see. Create a launch configuration for an RCP app and add only your app bundle to the config. Then click validate. Oh, a list of 20+ things to add. Fix a few then rinse and repeat 4-5 times. Note that in general we do not recommend "Add required" as it adds too much and does not make it easy for users to know what has been added. Perhaps this is an opportunity to address both issues. For example, something akin to quick fixes could be used. The validation button shows the problems (e.g., the things that would be added by Add Required but shown related to the individual validation problems) and the user can Ctrl-1 on each and chose a bundle to add to the launch config. In the case of feature based validations perhaps the set of features that would include a solution to the invalidity could be presented as well. Using this kind of approach the user gets an easy workflow (i.e., what Add Required gives) but also the visibility (i.e,. what Validate gives) Created attachment 173746 [details] Patch This patch restores the old workflow without Bug 295878. This shall unblock you while we decide on new workflow. Let me know if its good enough for M1. Patch works well for me Ankur, I wasn't able to get any widget disposed exceptions. Since it is parented off the launch dialog it closes when you launch. Marking as 3.6.1 candidate. Delivered to 3.6.1 and HEAD Thanks very much. I can rest peacefully again now that I have my non-modal dialog back. I appreciate it. Re-opening. Although the dialog is modal, I now get a new validation dialog opened for each press of the "validate" button. (So I end up with many dialogs open, one on top of the other). The dialog should be re-used and updated when validate is pressed additional times (see 3.5 behavior). Created attachment 176003 [details]
Dialog reuse patch
Since the pointer to the dialog is stored in the different block implementations, you can end up with multiple dialogs with the following steps: 1) Open a new config to the plugins tab 2) Press validate (dialog 1) 3) Change to "features selected below only" 4) Press validate (dialog 2) This isn't a major problem, but if we can do better we should. Looking at this again, I think we can live with the possibility of having two validation dialogs. To improve it, we would have to push something to the block containing both selection blocks. Fixed in HEAD (3.7 M2) and 3.6.1. Verified in M20100827-0800 |