Bugzilla – Full Text Bug Listing
| Summary: | Do not block user on every keystroke in Smart Project importer (scanning operation blocks UI) | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | UI | Assignee: | Mickael Istria <mistria> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bsd, daniel_megert, gautier.desaintmartinlacaze, Lars.Vogel, loskutov, mistria, psuzzi, sxenos, zulus |
| Version: | 4.6 | Flags: | Lars.Vogel:
pmc_approved+
|
| Target Milestone: | 4.7 M4 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/80925 https://bugs.eclipse.org/bugs/show_bug.cgi?id=492821 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9dc142efc9b8252e1c07716db1286e1cbe0e1c7e |
||
| Whiteboard: | |||
| Bug Depends on: | 510098 | ||
| Bug Blocks: | |||
|
Description
Lars Vogel
IMO, the ideal solution would be to: 1. Not disable the wizard control when scanning is happening (only disable tree and related buttons maybe), so users can still change values while scan is running. 2. Abort current scan (and start a new one) whenever some input changes. Item 2 could be implemented in the wizard even if we don't support item 1. About the suggested approaches, adding a delay after a text change seems good. (In reply to Mickael Istria from comment #1) > IMO, the ideal solution would be to: > 1. Not disable the wizard control when scanning is happening (only disable > tree and related buttons maybe), so users can still change values while scan > is running. > 2. Abort current scan (and start a new one) whenever some input changes. > > Item 2 could be implemented in the wizard even if we don't support item 1. > > > About the suggested approaches, adding a delay after a text change seems > good. Sounds all good. Adding a delay might also be sufficient. Our new ISideEffect API might be useful to model this. *** Bug 494189 has been marked as a duplicate of this bug. *** Current state is a disaster. Just try to type c:\ on windows and it starts immediately to scan over your entire hard drive, there is no possibility to type next letter because it disables the text input, so one has to harry clicking on the red cancel button (which requires to leave the keyboard and to change to the mouse or trackball). After that one can try to type the next part of the path, which results again in the multiple interruptions if the path is something like c:\work\eclipse\projects\maintenance... I've tried to add a delay but it doesn't feel better. Same in green. IMHO the right solution is to avoid automatic search start while typing. We should add "enter" listener and focus leave listener, and this will be good. Ideally I would see "OK" button appearing next to the text field as soon as one starts typing and the field contains existing directory, but this is not easy to implement I guess. (In reply to Andrey Loskutov - on the beach till 12.09 from comment #4) > IMHO the right solution is to avoid automatic search start while typing. > We should add "enter" listener and focus leave listener, and this will be > good. Ideally I would see "OK" button appearing next to the text field as > soon as one starts typing and the field contains existing directory, but > this is not easy to implement I guess. IMO, proposal in comment #1 is much more user friendly. Let's focus on the very thing that is annoying in that case: it's not that scanning happens automatically, it's that scanning disable possibility to modify the text field without clicking stop. If we can skip the textbox and other dialogs active and reactive, then we're fine. Another approach, that most likely requires more effort, is to change the way progress is reported. Currently, it's reported by the wizard dialog, in a blocking way. Instead, it could be a regular background job who's progress is reported on the affected part: the list of proposals. So instead of using the whole dialog as progress monitor, we try to show progress and a stop action inside the list widget which is going to change. Although, this may feel inconsistent with the other UX in some other wizards, I believe it would be quite user friendly. New Gerrit change created: https://git.eclipse.org/r/80925 *** Bug 501403 has been marked as a duplicate of this bug. *** A review of the proposal would be welcome if we want to make sure we reach a good result for 4.6.2 > Instead, it could be a regular background job
+1 for that approach.
(In reply to Stefan Xenos from comment #9) > > Instead, it could be a regular background job > > +1 for that approach. I've tried a to have progress reported in the usual wizard progress monitor and to not black the whole dialog by default (only the affected part). I like the result. See Gerrit patch for more details. (In reply to Mickael Istria from comment #10) > (In reply to Stefan Xenos from comment #9) > > > Instead, it could be a regular background job > > > > +1 for that approach. > > I've tried a to have progress reported in the usual wizard progress monitor > and to not black the whole dialog by default (only the affected part). I > like the result. See Gerrit patch for more details. I've tried this. It is one step in the right direction (because UI is not disabled anymore), but it is one step back too.. I saw no (obvious) way to stop scanning through directories once it starts because the usually shown red stop button is disabled and there is no visual hint in the wizard how to stop something ... except "Cancel" button, which will ... surprise ... close the wizard. So I failed multiple times to stop scanning my C:\ drive with this UI - "Cancel" closed the dialog, "Esc" key closed it too! So *not* obvious way to stop scanning is ... to manually set focus back in the field where I typed the path (because it was stolen once the scan begun), and to continue to type, until next directory was detected by scanner and the pain continued. I don't think this is acceptable UI. What I would propose: can we disable this automatic scan and split the wizard in two pages. The first page should ask for path and do a trivial "directory/archive is empty or not existing" check. If there is a sign of life in the selected path, the "next" button will open the next page with the table and immediately start the job with usual wizard progress bar and stop button. This will additioally make the second page less complicated as the current page today, and there will be no questions how to stop this job etc. Thanks a lot for having a look Andrey. (In reply to Andrey Loskutov from comment #11) > I saw no (obvious) way to > stop scanning through directories once it starts because the usually shown > red stop button is disabled I believe that was a bit too disruptive. Concretely, there should never be need to stop scanning with this approach: if you change the "root" to lookup or cancel the wizard, current scan is canceled automatically and a new one starts up. Anything that makes user need to stop scanning can be considered as a UX bug on that wizard. That said, I could simple try to have the stop button enabled to remove ambiguity. > to manually set focus back in the field > where I typed the path (because it was stolen once the scan begun) Ok, I can also try to have focus remaining in the text field > What I would propose: can we disable this automatic scan and split the > wizard in two pages. The first page should ask for path and do a trivial > "directory/archive is empty or not existing" check. If there is a sign of > life in the selected path, the "next" button will open the next page with > the table and immediately start the job with usual wizard progress bar and > stop button. This will additioally make the second page less complicated as > the current page today, and there will be no questions how to stop this job > etc. I dislike the idea of having 2 pages, as this operation should be as straightforward as possible, and multi-pages wizards don't give an impression of being straightfowrard. Also, the current page is as complex as the "Import Existing projects" or "Import Maven projects" wizards, and look similar to those. I don't think this 2-pages wizard would be simpler than the proposed 1-page one (assuming it contains the fixes mentioned above). Gerrit change https://git.eclipse.org/r/80925 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9dc142efc9b8252e1c07716db1286e1cbe0e1c7e Mickael, if you plan backport the fix to 4.6.3, please consider to take fix from bug 510098 too. +1 for downport from lead and additional committer (In reply to Lars Vogel from comment #15) > +1 for downport from lead and additional committer "Mickael Istria - away until February 20th" Lars, if this is important for you then please backport. Otherwise mark it fixed. (In reply to Dani Megert from comment #16) > Lars, if this is important for you then please backport. Otherwise mark it > fixed. I think it is fine to wait for 4.7. If someone disagrees, please provide Gerrit. |