Bugzilla – Full Text Bug Listing
| Summary: | [problems view] Show errors/warnings based on project by default, increase overall limit | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Andrey Loskutov <loskutov> |
| Component: | IDE | Assignee: | Lars Vogel <Lars.Vogel> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Arne.Goos, daniel.p.jaeger, daniel_megert, eclipse.sprigogin, Lars.Vogel, lufimtse, markus.kell.r, Mike_Wilson, psuzzi, sxenos, tmccrary |
| Version: | 4.7 | ||
| Target Milestone: | 4.7 M1 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=497942 https://git.eclipse.org/r/77489 https://git.eclipse.org/r/77491 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8ee78022817a942a5c60552ec4186a6b7ffea005 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=828242bb518db40e0c04360a31d1aa39c10b727a https://git.eclipse.org/r/77711 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=08a2f5857f264d07f7f471d9d85af670b0ec9dcb https://bugs.eclipse.org/bugs/show_bug.cgi?id=498356 |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 498125, 498127 | ||
|
Description
Andrey Loskutov
+1 New Gerrit change created: https://git.eclipse.org/r/77489 New Gerrit change created: https://git.eclipse.org/r/77491 Gerrit change https://git.eclipse.org/r/77489 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8ee78022817a942a5c60552ec4186a6b7ffea005 Gerrit change https://git.eclipse.org/r/77491 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=828242bb518db40e0c04360a31d1aa39c10b727a By default, all errors in the workspace must be shown. (In reply to Markus Keller from comment #6) > By default, all errors in the workspace must be shown. I disagree. Why do you think so? +1 (In reply to daniel jaeger from comment #8) > +1 Which alternative you are +1? On project or on workspace? I support the "Show errors/warnings based on project" option. +1 Workspace With the intention of having a clean workspace (= no errors/warnings in any project) it is important to immediately see if something anywhere is going wrong. E.g. if I make changes in one project which influences other projects and invalidates them, this should be visible. Maybe a compromise could be to have the summary line show more information: Current: "X errors, Y warnings, Z other" Suggestion: "project: X errors, Y warnings, Z other; workspace: A errors, B warnings, C other" With such additional information, I would vote +1 Project I support the base on project solution as well +1 (In reply to Lars Vogel Unavailable until 15 August 2016 from comment #7) > (In reply to Markus Keller from comment #6) > > By default, all errors in the workspace must be shown. > > I disagree. Why do you think so? It's unbelievable that a PMC member needs an explanation for this. Please think a bit more about it or read Hauke's comment 11 if you still don't get it. (In reply to Markus Keller from comment #14) > It's unbelievable that a PMC member needs an explanation for this. Please > think a bit more about it or read Hauke's comment 11 if you still don't get > it. As a PMC member ;-) I still see no need to insult people, please avoid doing this in the future. I did sent an email to platform UI to get more feedback on this proposed change. (In reply to Lars Vogel Unavailable until 15 August 2016 from comment #15) > I did sent an email to platform UI to get more feedback on this proposed > change. https://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg07285.html I think the root of the issue is that the mechanism used to switch between sets of problems isn't very obvious (you have to go to the view menu, etc). Perhaps some UX work should be done to make it easier for the user to notice and change the problems filter. In most cases it is more convenient to have errors limited to the selected project, but it is also very error prone. Since error proneness trumps convenience, I vote against the proposed change in its current form. I would support the change if the error proneness was mitigated, for example in a way proposed in comment #11. Also agree with comment #17. > default item limit to 1000 -2 for increasing the marker limit without extensive profiling first. I've personally investigated many of these performance issues and can assure you that they get very bad very quickly. Before increasing the marker limit, I'd like to see a test case which continuously refreshes the problems view as rapidly as possible and confirms that it never blocks the UI thread for more than 32ms. We'd need to make sure it passes this test on both GTK and windows. For background, we introduced the marker limit for bug 44443. Thanks Markus, Hauke, Stefan and Sergey for the additional perspective. I also agree with Stefan that we should only increase the limit to 1000 if we have verified via a test. @Andrey looks like we should work on the easier switch which you also suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=497942#c8 I prepare a patch to switch back to "All errors in workspace" and change the limit back to 100. New Gerrit change created: https://git.eclipse.org/r/77711 I'd like to propose a different option. I think users generally want to see errors related to the project they are working on, but - as mentioned in comment 11 - they also want to keep a clean workspace. Rather than using filtering, I'd suggest we use sorting to address this problem. Using a more clever sorter we can show a lot more markers in the problem view but prioritize it such that: - If there's an error anywhere in the workspace, you'll see an error marker in the problems view. - If there's errors in your current project, you'll see them in the problems view. - If your workspace is otherwise free from errors but your current project has warnings, you'll see them in the problems view. - Errors will be sorted such that problems which tend to cause a cascade of other problems will appear first. Such a sorter would accomplish the goals from comment 11, but by actually showing error markers for the other projects it would provide a very fast way to navigate to the project with problems and provide some sort of context for the nature of the problem. One such sort which matches these criteria would be: 1. Show errors from the current project. 2. Show errors from other projects, with a limit of 3 error markers per project. 3. Show all other warnings/infos from the current project. When showing error markers, build path errors would be shown before other error marker types, followed by "could not find class" errors. With this kind of sorter, it should be easy to both clean up your current project, keep tabs on other projects for downstream breakage, navigate between projects with errors, and get a feel for what sort of breakage has occured. ...and it wouldn't be necessary to flip between filter types when you move between cleaning up the current project and fix downstream breakage. -1 for the sorter solution, I think that will be hard to understand for the user. Gerrit change https://git.eclipse.org/r/77711 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=08a2f5857f264d07f7f471d9d85af670b0ec9dcb Note that I don't expect the test in comment 19 to pass... however: if it did, I would support increasing the marker limit. (In reply to Eclipse Genie from comment #24) > Gerrit change https://git.eclipse.org/r/77711 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=08a2f5857f264d07f7f471d9d85af670b0ec9dcb This changes the limit back to 100 and restores the "Show all errors" default. I mark this bug as won't fix, alternative solution or the increase of the limit backed with a bug report should be handled via a separate bug. Note: I left the resorting of the different detailed filter option in, so if the user remove the "Show all errors" flag, the project selection is selected. If people find that unacceptable, please reopen. Re: comment 23 Fair enough. What if we use a filter that only shows warnings/errors in the current project as suggested, but if you don't have a clean workspace we insert one error marker right up at the top of the view that says something like: "You have 10 other projects with errors" That would be self-explanatory and avoid any complicated sorting. Double-clicking on that error marker would provide some way to navigate to the projects with errors. For example, the entry in the problems view could be a tree node and expanding it could open the list of projects containing errors. Double-clicking on the project could open the first error in that project. (In reply to Stefan Xenos from comment #27) > What if we use a filter that only shows warnings/errors in the current > project as suggested, but if you don't have a clean workspace we insert one > error marker right up at the top of the view that says something like: > > "You have 10 other projects with errors" I personally like that. Even without the change of defaults that would be helpful. I suggest to open a new bug report for that. Re: comment 26 Let's not close this prematurely. I think Andrey has identified a real problem... I just don't think a simple change of the defaults is necessarily the best fix for that problem. Let's brainstorm ideas. > Even without the change of defaults that would be helpful. So what about a change to the view header as suggested in comment 11, combined with a new special "grouping" marker as suggested in comment 27, followed by flipping the filter to as originally suggested in comment 0. I believe that should address both the original concerns from comment 0 along with the error-proneness mentioned in comment 18. Reopening for consideration of the approach from comment 30 (and to elicit other ideas). (In reply to Stefan Xenos from comment #29) > Re: comment 26 > > Let's not close this prematurely. I think Andrey has identified a real > problem... I just don't think a simple change of the defaults is necessarily > the best fix for that problem. > > Let's brainstorm ideas. I think this bug had a narrow scope, so new ideas should go into new bugs. Other bugs for the problems views are for example Bug 497942. In general I share the view from https://bugs.eclipse.org/bugs/show_bug.cgi?id=497942#c8 that the Problem view has an "exceptionally complicated/over-engineered Problems view configuration". I think comment 17 indicates a legitimate problem with our current capability, and suggest that we look at fixing that before going after more pervasive changes. Even something as simple as a toolbar with icons for the two or three most common cases, plus a "custom" icon to pull up the full filter dialog would be enough. Perhaps if this bug is WONTFIX, we could open a new one to cover improving discoverability and usability of the filtering support? +1 for WONTFIX. Another solution could be a new contents configuration which allows to see all errors and warnings for the selected project and (recursively) the ones that require that project. See Bug 498356 for follow up. |