Author: Jan Rojcek, Jan Becicka

UI Specification of Unavailable Features during Classpath Scan

This is a proposal for UI indication that some features are unavailable while the classpath scanning is in progress. Progress of scanning is indicated as regular background task using Progress API.

There are 4 categories of features that are affected by classpath scanning still in progress:

1. Unavailable feature invoked by action showing a dialog
   • Refactoring actions
   • Find Usages
   • Override Methods
2. Unavailable feature with special invocation showing a dialog
   • Refactoring Rename (invoked by inplace rename)
   • Refactoring Move (invoked by DnD, or Cut&Paste)
3. Unavailable feature invoked by action, performed immediately (no intermediate dialog)
   • Goto Source
   • Goto Declaration
   • Goto Super Implementation
   • Fix Imports
   • Correct Javadoc
   • Synchronize
4. Unavailable component (other than a dialog window)
   • Class hierarchy node in Project and File window
   • Navigator hierarchy
   • Code completion
   • Goto Source (the Matching Classes list inside the dialog)
   • Auto Comment

UI Design

For A) B) C) after invoking an action, the IDE shows an information alert informing the user that the feature is not yet available due to the classpath scanning. The modal alert would look like this:

+------------------------------------------------------------+
| Change Method Parameters                                   |
+------------------------------------------------------------+
|                                                            |
|     o                                                      |
|     |     Please wait, classpath scanning in progress...   |
|     |                                                      |
|                                                            |
|                                                            |
|                        [ Cancel Change Method Parameters ] |
+------------------------------------------------------------+ 

The title bar contains name of action the user invoked.
Cancel button has label "Cancel" + name of action.

The progress itself is indicated in the status line by progress bar. This message should tell the user that she should wait for scanning to finish. If the user decides she doesn't want to wait, she clicks Cancel and alert disappears. If the scanning finishes while the alert is open, it automatically closes the alert and the interrupted action continues as normal (e.g. the Change Method Parameters refactoring dialog appears).

This is not ideal for B) as the user might want to perform actions (Move, Rename) without refactoring, but she still have to wait for progress to finish. So, if she clicks Cancel the action is not performed.

For D) after showing the component (subtree, navigator window, code completion) the component displays an in-place hourglass icon with "Scanning in progress..." label. Please note that this label is different from "Please wait..." which is used if the component doesn't wait for *scanning to finish*, but waits for regular slow data fetching.

Implementation

Javamodel API users should use following pattern to make their actions compliant with this UI spec. Lets have some swing action:

public class MyAction implements javax.swing.Action {
.
.
  public void actionPerformed(ActionEvent ae) {
    //do some work
  }
}

This action should transformed this way:

public class MyAction implements javax.swing.Action {
.
.
  public void actionPerformed(final ActionEvent ae) {
    Runnable run = new Runnable() {
      public void run() {
        //do some work
      }
    };
    JavaMetamodel.getManager().invokeAfterScanFinished(r, nameOfAction);
  }
}

JavaMetamodel.isScanInProgress() and JavaMetamodel.waitScanFinished() can also help implement this UI spec.