Navigation Improvements

Provide results when "Go To Type" action invoked immediately

Objective: Improve user perceived performance.

JST: Perceived? It really speeds up the GoToType and eliminates waiting. Ondrej: But it can commonly give incomplete results if the variant with asynchronous project loading is used (see Problems section).

6.0 state

Environment: NetBeans IDE, existing userdir with several opened projects.

When user invokes "Go To Type" dialog immediate after start and writes value to "Type Name" field, he has to wait until scanning dialog is finished to see the result of a search. Many users are bored especially when they work on large number of projects. Often, there is no need to wait until up-to-date check ...

Desired 6.1 state

It would be fine to allow user to open class even when scanning is running. It is possible and not so difficult to implement - but it can lead to incomplete or inaccurate results. Consider following use-case: User has huge source base and when he comes to work, he starts update of the source base. When update is finished user starts IDE. Scanning has been started automatically and user invokes "Go To Type" and writes class name to "Type Name". There are several possible results, class:

1. hasn't been changed or has been updated only - it is found and offered to user to open,
2. class was removed during update - it is found and offered to user to open,
3. class was newly created (checked out) - there are two possible results: Either scanner already recognized that, then class is offered to open or scanner didn't know that and obviously it can't make out what happened.

UI spec for incomplete results available

Problems

• list of opened projects is notified asynchronously - e.g. dialog can be visible without knowing of any opened projects, these can be notified later
• results are shown while classpath scan is running - e.g. may be inaccurate until the classpath scan finishes
• IZ 124980

Principle #1: Show as most as we can at given time, but avoid showing only small subset of available types

Ondrej (xDesign) recommends that the dialog shows the data it has as soon as it is "almost sure" that what user is looking for is present. This is when all projects have been loaded. Classpath scan can still be in progress so the data may not be completely up-to-date (due to versioning update described above), but this can be considered a rare case (UI spec defines how to indicate this situation). The up-to-date data are being recomputed at background and at suitable user gestures, the data are refreshed to be as up-to-date as possible.

Principle #2: Forbid adding while user does nothing

The user needs to invoke refresh of the data, it is not good to do this automatically, as it might badly influence use of mouse or other means of user navigation. So far the currently known points that allow change of data:

• list is empty => it is OK to populate it
• user changes the search string => OK to replace the data with new ones
• user explicitly invokes refesh (UI spec defines details)