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.

Bug 111681 - Rewrite IncludeExcludePanel to match UI spec
Summary: Rewrite IncludeExcludePanel to match UI spec
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
Keywords: UI
Depends on:
Blocks: 49026
  Show dependency tree
Reported: 2007-08-01 22:49 UTC by Jesse Glick
Modified: 2014-07-08 09:15 UTC (History)
2 users (show)

See Also:
Exception Reporter:

Nonfunctional patch-in-progress (55.56 KB, patch)
2007-08-23 22:58 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-08-01 22:49:59 UTC
See wiki for UI spec.
Comment 1 Jesse Glick 2007-08-23 22:58:22 UTC
Created attachment 47222 [details]
Nonfunctional patch-in-progress
Comment 2 Jesse Glick 2007-08-23 23:13:01 UTC
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.
Comment 3 Jesse Glick 2008-02-15 16:15:27 UTC
This is only a "technical" P2, i.e. mismatch with UI spec, not a real bug. I am no longer working on this area.
Comment 4 Tomas Zezula 2008-02-18 12:43:21 UTC
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.
Comment 5 Tomas Zezula 2014-07-08 09:15:08 UTC
No complains about the current regexp panels.