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).
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.
Created attachment 72285 [details]
API for more effective filtering, if one can base the decision on plain FileObject (no apichanges yet)
[JG01] "Lowlevel" should be "LowLevel", or preferably something more descriptive such as "FileObjectFilter".
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?
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.
I'll change the name to FileBased and integrate tomorrow.
*** Issue 150750 has been marked as a duplicate of this issue. ***
Implemented in Favorites. Similar change needs to be done in Projects and Files view. Reassigning to Milan to do that.
user: Jaroslav Tulach <email@example.com>
date: Wed Oct 29 15:21:07 2008 +0100
summary: #150747: API and change in Favorites to speedup folder expansion
What repository are we using these days?
Integrated into 'main-golden', will be available in build *200810300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <firstname.lastname@example.org>
Log: #150747: API and change in Favorites to speedup folder expansion
Created attachment 72914 [details]
I've attached diff file with changes in places that I think should be fixed. Are there any other places?
Perhaps there should just be
public static /*Changeable,FileBased*/DataFilter DataFolder.visibilityFilter();
since that seems to be a popular filter?
I think it's question for Jarda.
Perhaps. I have no problems to accept such patch.
Integrated into 'main-golden', will be available in build *200811010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Milan Kubec <email@example.com>
Log: #150747: VisibilityQuery uses FO for filtering
Projects view still remains to be fixed.
Should be fixed now.
Integrated into 'main-golden', will be available in build *200811050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Milan Kubec <firstname.lastname@example.org>
Log: #150747: VisibilityQuery uses FO for filtering; missing Node fixed
Appears to be fixed (tested with build 200811071401).
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.
My part is summarized in following changesets:
I think all relevant changesets are mentioned in this issue:
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?
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.
@sustaining: matthies summarized all the reasons in his comment #27 why we would like to add it into the patch
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).
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
Integrated into 'main-golden', will be available in build *200811181401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: Fixing fix of #150747; FileObject-based filters should use the same criteria as DataObject-based.
would you please re-verify the latest fix made by Jesse?
Created attachment 73914 [details]
Updated patch from main_63608ddca04e which applies cleanly against release65_fixes
The fix appears to work fine in build 200811181401.
I've ported the changeset http://hg.netbeans.org/main/rev/63608ddca04e into release65_fixes repository as
verified by steps to reproduce (Issue 150750) in 6.5 patch 1