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 231532

Summary: Slow go to type waits for all providers
Product: utilities Reporter: Egor Ushakov <gorrus>
Component: Jump ToAssignee: Tomas Zezula <tzezula>
Severity: normal CC: markiewb, tzezula
Priority: P3    
Version: 7.4   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description Egor Ushakov 2013-06-19 15:10:32 UTC
Steps to reproduce:
- open small java project
- open big c++ project
- try to do "go to type"
As a result request may be really slow even if your requested type exists only in java project because go to type is asking all providers and waits for all of them to return before showing any results.
Comment 1 Egor Ushakov 2013-06-19 15:11:15 UTC
see slowness report in bug 231282, because of c++ slow I was unable to go to java type as well
Comment 2 Tomas Zezula 2013-06-19 16:10:18 UTC
Unfortunately it was a requirement from UI team, the items cannot be added later when user navigates on the list. But it's quite common behaviour on Mac where spot light dynamically changes the list of found items and adds new ones. As the UI team has changed we can try to reevaluate it again. The same holds for Go To File and Go To Symbol.
Petre, what do you think about it? Can I change the behaviour?
Comment 3 Petr Somol 2013-07-08 09:07:39 UTC
With respect to time consuming buildup of lists I believe it is now generally accepted that any available results should be made available to users as soon as possible, but some additional concerns should be taken into account. To make it right, it should be ensured that a result of interest does not "flee" from the user due to the list grow process. In other words, if user has not not touched anything yet, then it is all right to let the list grow in the head, tail or anywhere in the middle, what may shift individual items out of view. However, if the user has selected an item in the list and the list needs grow further, then it should be ensured that the selected item does not move in the view. The list as a whole can then grow before the item or after the item, what would be displayed by possibly changing the items above or below the selected item, and scrollbar would keep adjusting. But the selected item should remain where it is. To make things even easier for the user, it should work like that even if no item has been selected, and the user just has scrolled the list to some position. After the manual scroll, the view should stay focused roughly to the same place even if the list grows further (this is of course tricky to define - which items should be kept in view when the list can grow anywhere inbetween them).

What I described above is the "ideal" state which is followed in some software (I guess MacOS is reasonably good in this respect?), but ignored in other (try Search for file in Windows 7, or open Control Panel - Programs and Features, the growing lists are not very convenient in the respect described above)

Anyway, keeping known results hidden from users does not seem to be defendable, unless there is some extremely serious reason to do so.
Comment 4 Tomas Zezula 2014-06-17 15:45:42 UTC
Fixed jet-main

Fixed as explained, when files from index are known they are displayed.
The file list is then updated by files found by file system crawling.
Comment 5 Tomas Zezula 2014-06-17 15:45:58 UTC
Fixed jet-main

Fixed as explained, when files from index are known they are displayed.
The file list is then updated by files found by file system crawling.