This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Rewrite IncludeExcludePanel to match UI spec | ||
|---|---|---|---|
| Product: | java | Reporter: | Jesse Glick <jglick> |
| Component: | Project | Assignee: | Tomas Zezula <tzezula> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | CC: | anebuzelsky, dsimonek |
| Priority: | P2 | Keywords: | UI |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://wiki.netbeans.org/wiki/view/Excludes49026_UI | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 49026 | ||
| Attachments: | Nonfunctional patch-in-progress | ||
|
Description
Jesse Glick
2007-08-01 22:49:59 UTC
Created attachment 47222 [details]
Nonfunctional patch-in-progress
After spending several hours trying to implement the spec I have decided to abandon the effort for 6.0. While the existing panel works, has relatively straightforward behavior, and is known to be reasonably fast, there are a number of unresolved problems with the proposed spec. 1. I think most people would expect a checkbox tree. The spec says nothing in detail about what would be displayed on the Excludes side, but it would have to be a collection of files and dirs, which I think would look quite strange if they were not siblings. 2. The spec seems to assume that a package list will be used, but this would interact very poorly with attempts to exclude subtrees, so I was implementing a tree view instead. 3. The root nodes in the spec seem to be project names, but really (absolute) file paths are needed. 4. The Include button cannot work in all cases if the user has manually edited the text fields (since there can be arbitrary wildcard patterns with complicated interactions). It would probably have to be disabled in some cases. 4a. "Include" would be tricky to implement even if there were no manual edits: if you exclude foo/ and then include foo/bar/, what to do? Excludes always override includes. The dialog would have to know to remove the foo/ exclude and replace it with a list of excludes of bar's siblings. 5. The display has to be responsive even on enormous source trees. The current panel uses a background updater thread for this purpose. In the proposed spec, it would be more complicated to update the lists asynchronously (since a tree can be in various states of expansion); and there would be race conditions if the user tried to use the include/exclude buttons while the display was being updated. Given the implementation difficulties, I don't think it makes sense to spend much time on a relatively infrequently used customizer panel, when there are plenty of "hard" bugs for 6.0. This is only a "technical" P2, i.e. mismatch with UI spec, not a real bug. I am no longer working on this area. There are no complains about the current excludes panel, seems rather as an enhancement. When real complains about it from users will come we can change it. No complains about the current regexp panels. |