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: | Too many keys without nodes | ||
---|---|---|---|
Product: | projects | Reporter: | t_h <t_h> |
Component: | Generic Projects UI | Assignee: | Milan Kubec <mkubec> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | apireviews, hmichel, jtulach, matthies, mkubec, mslama, sustaining |
Priority: | P3 | Keywords: | API_REVIEW_FAST, PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
API for more effective filtering, if one can base the decision on plain FileObject (no apichanges yet)
diff Updated patch from main_63608ddca04e which applies cleanly against release65_fixes |
Description
t_h
2008-10-20 16:38:50 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. 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. 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 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) 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 Created attachment 72914 [details]
diff
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) Changeset: http://hg.netbeans.org/main/rev/d0fd193b04a6 User: Milan Kubec <mkubec@netbeans.org> Log: #150747: VisibilityQuery uses FO for filtering Projects view still remains to be fixed. Should be fixed now. http://hg.netbeans.org/core-main/rev/3e5149d247e5 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 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: http://hg.netbeans.org/core-main/rev/d0fd193b04a6 http://hg.netbeans.org/core-main/rev/3e5149d247e5 I think all relevant changesets are mentioned in this issue: f09a57440fd7 d0fd193b04a6 3e5149d247e5 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 than VisibilityQuery.isVisible. 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. matthies, t_h, 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 http://hg.netbeans.org/release65_fixes/rev/11e670a38fc8 verified by steps to reproduce (Issue 150750) in 6.5 patch 1 |