Bugzilla – Full Text Bug Listing
| Summary: | 'Compare With > Each Other' opens two dialogs and flickers editors | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Compare | Assignee: | Michael Valenta <Michael.Valenta> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Kevin_McGuire |
| Version: | 3.3 | ||
| Target Milestone: | 3.3 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Markus Keller
I've fixed the double prompt. Originally, we left the editor open with a message but the general consensus was that this had no benefit (i.e. all the user could do with it was close it anyway). Sure, the compare editor makes little sense after a dialog has been shown. But why do we need the dialog at all? All other results of this operation are shown in a compare editor, so why not showing the "No differences" result in the editor as well? I find the opening and closing of the editor in the background visually distracting. Since that flashing is an unsolvable chicken-and-egg problem with the new asynchronous comparison, I would prefer an editor that says "No differences". I believe the optimal solution would be to avoid opening the editor at all until the computation is complete, at which point, either the editor would be opened or the "no changes" prompt would occur. However, this is problematic because the user is used to seeing the editor immediately and will think the operation failed if they don't. As I said, I originally did leave the editor opened but changed the behavior after some discussions with Kevin. We felt that the best compromise was to open the editor immediately but to close it if it didn't have any results to show. Kevin, do you have any comments on this? Kevin, do you really think the heavy flashing that occurs when the editor is opened and closed in the background is better than just showing the result in the editor? An additional interruption occurs when the compare takes some time. While the compare editor is busy doing its job, the user can switch to another editor. When the compare is done, a dialog pops up out of nothing and the editor is closed. You can glance that something happened with the tabs, but you have no idea what it was because it was not user-initiated. This is confusing. This isn't a big deal, it just seemed to lack a bit of finesse it the way it played. But I understand why it works as it does. The issue of the computation potentially taking a long time seems to be at the root. Markus, your last comment about time passing and the user then getting a dialog is important - there's very little cue for the user to tie the dialog back to the originating action. Having an empty editor, and a prompt, is redundant though, perhaps we can just do one or the other. A dialog that had no contents except the message "there are no differences" would perhaps be best given the async nature. In the future additional information might be added, such as the time stamps of each, the MD5 hash ... kind of making things up but the idea is that "no differences" IS in fact a result. If we think of editors as web pages we wouldn't be surprised by a "no results" message in the page. |