Bug 150747 - Too many keys without nodes
Too many keys without nodes
Product: projects
Classification: Unclassified
Component: Generic Projects UI
All All
: P3 (vote)
: 6.x
Assigned To: Milan Kubec
: 150750 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-10-20 16:38 UTC by t_h
Modified: 2009-02-19 22:56 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT

API for more effective filtering, if one can base the decision on plain FileObject (no apichanges yet) (12.09 KB, patch)
2008-10-20 17:34 UTC, Jaroslav Tulach
Details | Diff
diff (6.56 KB, text/plain)
2008-10-30 14:46 UTC, Milan Kubec
Updated patch from main_63608ddca04e which applies cleanly against release65_fixes (9.23 KB, patch)
2008-11-19 14:47 UTC, rbalada
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description t_h 2008-10-20 16:38:50 UTC
For optimal performance of lazy Children.Keys it is necessary to minimize number of keys without nodes. If there is a
key for which a node is not created during node lazy computation it is necessary to create temporary "dummy node" and
fire remove change. If there is a lot of "empty" keys which are often changing it may result in unpleasant visual
experience as well as unnecessary performance degradation especially if there is rich FilterNode hierarchy above such
Node (see user comments in Issue 143824).
Comment 1 Jaroslav Tulach 2008-10-20 17:30:14 UTC
This is a problem of VisibilityQuery usage in Favorites, Files and Projects views. The old implementation created data 
objects first, and they did the filtering. We need to update all the usages to use more effective alternative.
Comment 2 Jaroslav Tulach 2008-10-20 17:34:18 UTC
Created attachment 72285 [details]
API for more effective filtering, if one can base the decision on plain FileObject (no apichanges yet)
Comment 3 Jesse Glick 2008-10-21 01:16:34 UTC
[JG01] "Lowlevel" should be "LowLevel", or preferably something more descriptive such as "FileObjectFilter".
Comment 4 Jaroslav Tulach 2008-10-21 09:31:00 UTC
Re. JG01: should FileObjectFilter be a top level interface? There already is ChangableDataObjectFilter and the base 
DataObjectFilter, so it might make sense to have another top level interface. On the other hand making it a nested 
class of DataObjectFilter follows the principle of locality - just I do not want to call it 
DataObjectFilter.FileObjectFilter which duplicates the "filter" word. I want to use DataObjectFilter.FileObject 
neither, as that would clash with FileObject interface. Maybe DataObjectFilter.Preprocessor?
Comment 5 Jesse Glick 2008-10-21 22:36:31 UTC
DataObjectFilter.FileBased, perhaps? I would be careful with avoiding duplication in names of nested classes, though;
you have no guarantee that it will actually be used qualified by the name of the outer class. (Fix Imports seems to like
to import the nested class directly.) I would have a slight preference for a top-level interface. DataObjectFilter is
already outside its logical scope of FolderNode.
Comment 6 Jaroslav Tulach 2008-10-29 08:35:06 UTC
I'll change the name to FileBased and integrate tomorrow.
Comment 7 t_h 2008-10-29 14:56:49 UTC
*** Issue 150750 has been marked as a duplicate of this issue. ***
Comment 8 Jaroslav Tulach 2008-10-29 15:22:59 UTC
Implemented in Favorites. Similar change needs to be done in Projects and Files view. Reassigning to Milan to do that.

changeset:   106833:f09a57440fd7
tag:         tip
user:        Jaroslav Tulach <jtulach@netbeans.org>
date:        Wed Oct 29 15:21:07 2008 +0100
summary:     #150747: API and change in Favorites to speedup folder expansion
Comment 9 Milan Kubec 2008-10-29 15:32:07 UTC
What repository are we using these days?
Comment 10 Quality Engineering 2008-10-30 05:00:19 UTC
Integrated into 'main-golden', will be available in build *200810300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/f09a57440fd7
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #150747: API and change in Favorites to speedup folder expansion
Comment 11 Milan Kubec 2008-10-30 14:46:52 UTC
Created attachment 72914 [details]
Comment 12 Milan Kubec 2008-10-30 14:49:02 UTC
I've attached diff file with changes in places that I think should be fixed. Are there any other places?
Comment 13 Jesse Glick 2008-10-30 15:19:57 UTC
Perhaps there should just be

public static /*Changeable,FileBased*/DataFilter DataFolder.visibilityFilter();

since that seems to be a popular filter?
Comment 14 Milan Kubec 2008-10-31 08:04:49 UTC
I think it's question for Jarda.
Comment 15 Jaroslav Tulach 2008-10-31 08:39:17 UTC
Perhaps. I have no problems to accept such patch.
Comment 16 Milan Kubec 2008-10-31 10:30:55 UTC

Comment 17 Quality Engineering 2008-11-01 05:11:53 UTC
Integrated into 'main-golden', will be available in build *200811010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/d0fd193b04a6
User: Milan Kubec <mkubec@netbeans.org>
Log: #150747: VisibilityQuery uses FO for filtering
Comment 18 t_h 2008-11-04 11:39:14 UTC
Projects view still remains to be fixed.
Comment 19 Milan Kubec 2008-11-04 12:08:02 UTC
Should be fixed now.

Comment 20 Quality Engineering 2008-11-05 04:36:02 UTC
Integrated into 'main-golden', will be available in build *200811050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/3e5149d247e5
User: Milan Kubec <mkubec@netbeans.org>
Log: #150747: VisibilityQuery uses FO for filtering; missing Node fixed
Comment 21 matthies 2008-11-11 15:09:54 UTC
Appears to be fixed (tested with build 200811071401).
Comment 22 Lukas Hasik 2008-11-11 19:56:18 UTC
this is candidate for patch1 for 6.5

Tomasi, Milane, could you summarize all the changesets that need to be transfered into release65 for sustaining? Thank you.
Comment 23 Milan Kubec 2008-11-12 08:41:32 UTC
My part is summarized in following changesets:

Comment 24 t_h 2008-11-12 15:24:32 UTC
I think all relevant changesets are mentioned in this issue:
Comment 25 pgebauer 2008-11-12 17:45:18 UTC
Since this issue is P3 priority, in accord with rules "How to include issues into patch"
(http://wiki.netbeans.org/NetBeansPatches) it must include an explanation as to why its backport is necessary and how
safe it is.

Could you please provide such explanation?
Comment 26 matthies 2008-11-12 19:31:51 UTC
One could argue that it's actually a P1, "Regression in functionality or performance". Only half-serious here. For me 
it's a significant usability issue as I work a lot in the Project and Files views, and this defect regularly causes a 
visual annoyance there (see issue 150750), compared with NB 6.1.
Comment 27 Lukas Hasik 2008-11-13 09:17:24 UTC
@sustaining: matthies summarized all the reasons in his comment #27 why we would like to add it into the patch
Comment 28 rbalada 2008-11-13 17:03:10 UTC
I've ported referred changesets into release65_fixes repository.

http://hg.netbeans.org/main/rev/f09a57440fd7 as http://hg.netbeans.org/release65_fixes/rev/764b02d4d2df
http://hg.netbeans.org/main/rev/d0fd193b04a6 as http://hg.netbeans.org/release65_fixes/rev/eb0902049c80
http://hg.netbeans.org/main/rev/3e5149d247e5 as http://hg.netbeans.org/release65_fixes/rev/f04c1bdfacea

I had to update specification version numbers specified and used across those changesets, which eventually causes little
inconsistence in file http://hg.netbeans.org/release65_fixes/file/764b02d4d2df/openide.loaders/apichanges.xml which
still states that "<change id="DataFilter.FileBased">" has been implemented in "<version major="7" minor="4"/>", but
http://hg.netbeans.org/release65_fixes/file/764b02d4d2df/openide.loaders/manifest.mf says openide.loaders modules in
release65_fixes repository has got specification version number 7.2.2 (after increment for NB 6.5 Patch1 7.2.1->7.2.2).

Comment 29 Jesse Glick 2008-11-17 23:44:33 UTC
Milan's commits are wrong, I think. They make acceptFileObject behave differently from acceptDataObject. I have tried to
correct it in core-main #63608ddca04e.

DataFolder.visibilityFilter() is not worthwhile; only Favorites and PhysicalView use a filter with no conditions other
than VisibilityQuery.isVisible.
Comment 30 Quality Engineering 2008-11-18 16:37:27 UTC
Integrated into 'main-golden', will be available in build *200811181401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/63608ddca04e
User: Jesse Glick <jglick@netbeans.org>
Log: Fixing fix of #150747; FileObject-based filters should use the same criteria as DataObject-based.
Comment 31 rbalada 2008-11-19 11:56:12 UTC
matthies, t_h,

would you please re-verify the latest fix made by Jesse?
Comment 32 rbalada 2008-11-19 14:47:58 UTC
Created attachment 73914 [details]
Updated patch from main_63608ddca04e which applies cleanly against release65_fixes
Comment 33 matthies 2008-11-19 16:29:19 UTC
The fix appears to work fine in build 200811181401.
Comment 34 rbalada 2008-11-20 12:24:23 UTC
I've ported the changeset http://hg.netbeans.org/main/rev/63608ddca04e into release65_fixes repository as
Comment 35 Tomas Danek 2008-12-02 13:18:37 UTC
verified by steps to reproduce (Issue 150750) in 6.5 patch 1

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo