UI Framework for new features
based on MDR
Authors: Dusan Pavlica
Last update: 10/13/2003
Table of Contents
- UI specification
- Refactoring mode
- Main flow and refactoring steps
- Invocation of refactoring commands
- Possible warning messages
- Set of parameters
- Possible Problems
- Suggested changes with or without a preview
- Confirmation and execution in the Output Area
- Undo action
- Example of Rename refactoring action
- First step with options and filters
- Second step with confirmations
- Browsing mode
- Class Browser
- Toolbars of Class Browser
- Description of History function
- Combo Box Content
- Navigation in Class Browser
- Context menu above areas
- Behavior of Preview Area
- Searching mode
- Search possibilities
- Two modes of search will available
- ToolBar in the Output window
- Navigation mode
- Code Navigator
- Hierarchy View
- Outline View
- Support mode
- Support with indication
- Support with suggestion
- Refactoring mode
- Open Issues
Metadata Repository (MDR) will be used as a foundation for many functionalities in next
releases of NetBeans. Main goal of this document is to describe basic UI framework
for them. Many documents about this problematic have been created yet, but complex UI
and main user flow are missing still.
There are more different places (Explorer, Editor, Contextual Menu, Output area - Task List, etc.) where is possible to invoke UI intended for actions (searching, renaming, moving, assisting) build on MDR. These actions, places and possible functionalities will be summarized in this document too.
The Java-MDR Integration is being added as a separate module aimed at providing a basic
feature set for JavaOne 2003. After the initial release the module and supported feature
set will be expanded to include more views on Java metadata and management for refactoring
code. So, the MDR project has two phases. First one should demonstrate basic usage of the
MDR and then full support for refactoring, searching in a structure and complex
navigating will be implemented. This second phase is the long process of course.
There are older documents detailing the direction and goals of the MDR functionality and two User Views. The first is newer and includes the features discussed in this spec
- Model Based Java Language Support
- Metamodel for the Java Language
- User View: JavaOne Features - This is user view with simple features (Find subclasses, Find Implementors, Overridden methods).
- New Java module based on MDR - User View - Second User View which describes the MDR integration UI
There are four important and major sections where Java MDR could be used (some updated citation from mentioned resources):
- Browsing through hierarchy - We have simple view on members under class node in the Explorer tree, but it's limited and should be improved.
- Searching and editing capabilities - User needs tool for easy searching for usage. E.g. looking for method callers, field accessors, looking for class instances, etc.
- Refactoring and analysis capabilities - support for renaming references, moving classes between packages, try-catch auto-completion etc.
- Source code navigation - In current modules, support is good enough, but we can add additional features related to searching capabilities, e.g. finding subclasses of a class, implementors of an interface etc.
- Source code proactive support - We have only code completion support but we should provide more capabilities. It could contain looking for unused elements, looking for repeating code blocks, performance techniques analysis - e.g. suggest listener conversion to outer class, anonymous classes reduction etc.
When we want to cover all of these above successfully, clear and logical UI should be created. Mentioned functionality could be invoked or used from different places:
- Explorer - It should include chance to invoke refactoring functionality from Context menu still (e.g. rename of class, method).
- Source editor - Three cases are exist. Shortcuts, Context menu, Proactive popup
- Output area - Intended for a search result which is linked with code.
- Class Browser - More sophisticated UI with class hierarchy and with different looks on it.
- Main Menu - Right place for refactoring action which aren't context sensitive (e.g. Scan code for unused methods, fields, etc.).
We have to think about user flow, smooth changeovers and collaborations among these mentioned modes and places.
The new functionality will be relevant for all users of NetBeans. There are five following modes and each has typical group of user. Let's mention any cases:
- Browsing - It is intended for user that wants to browse throw structure of code and its hierarchy. Expert developer will use this UI concept for searching through a complex inheritance of classes or interfaces. Intermediate developer could use Browsing mode for familiarize with code of somehow else. Beginner user could look on easy structured classes and their meaning in a package.
- Searching - This part of the UI Framework is mean to work when user is mostly focused in Source editor and she doesn't need to browse structure of code. She wants to find selected element quick without break flow of coding.
- Refactoring - When project grows (Intermediate and Expert developer), then refactoring is necessary for any changes in a code.
- Navigation - Expert developer familiar with the IDE will definitely appreciate each UI concept which will speed up developing more.
- Support - This functionality is intended for a basic user by suggesting solutions (e.g. in a error prone coding style). This support could help create more clear and logical (e.g. suggesting code patterns) code for Advanced users too.
Next chapter is about possible scenarios and workflow, when user will use mentioned functionality.
User is in a situation, when she needs to change amount of code by any rename of class (method), move class throughout all package (project) etc. Then she is in need of a tool, which will search for changes and will provide necessary confirmation for each of them. User should be able confirm all changes at one time. This tool could be invoked automatically (e.g. after change of class name in the Explorer) or user could invoke it from Context Menu in the Source editor or in the Explorer.
Clear confirmation should exist in this refactoring tool. Then its functionality could be put into dialog which checkboxes by each search output. Output window is another possible place for refactoring framework, but then joint with Searching mode needs to be discussed. And confirmation will be indistinct, then in the proposed dialog.
Let's imagine that user wants to explore structure (not code) of unknown package (project) without concrete goal except to understand of his size and structure. Then she needs to see hierarchy and relationship of classes, subclasses, implemetors, implemented and inherited method. Hierarchy hasn't complete information without JavaDoc, so it should be visible too. We could suppose that during this browsing he would like to see concrete code for a while maybe and then continue with browsing again. Browsing throughout hierarchy should be quick and types of this hierarchy easy accessible for change.
For this navigating we could reuse physical structure of a Java source tree in the
Netbeans Explorer, but lets notify, that this structure won't be in Explorer in the future
maybe. Then any kind of Outline View could exit.
Another possibility is to have complex dialog (Class Browser) with JavaDoc or short summary info about selected object. Navigation into history (back&forward) plus chance to Find all instances of currently selected node could be supported as well.
When user are familiar with structure of code and started work (continue) on this code, then she needs more sophisticated method for searching links among classes, interfaces and methods. Then some kind of search support i necessary. Results of this search should be more permanent then in the browsing scenario because we presume that user would like to open linked code and switch between code and results more frequently. Any history of results is acceptable for her too. Two modes of Searching could exist. First is about quick searching without any settings (e.g. Give me a quick info about usage of this method). But user would like to use any filters on the other hand, then dialog before searching or by Output area should be available.
Right place for search results seems to be Output window which currently contain similar type of information (e.g. output with active links into a code). Output is sufficiently wide to include active links on source code with information about position in a hierarchy or surrounding occurrence of code. Dialog for Search should be invoked from the Source editor primarily (shortcuts or Context menu), but Context Menu in the Explorer and Class Browser dialog are acceptable too. Set of filters should be accessible near results too. Dialog witch filter rules invoked before searching is open issue. Any redesign of current dialog for searching is possible as well.
Let's suppose that user is really touch with code and wants to go into another code quick. User is focused on concrete part of code and would like to obtain group of navigation which is logical to cursor's position. We have 'Go to Source' and 'Go to Declaration', but more cases could be supported.
Navigation inside code is most natural in source Editor then everywhere else. Then main
support for it should be there (e.g. Keyboard shortcuts, Context Menu, part of Code
Assistant?). Additional navigating is possible in the Explorer but only for that time,
when Java structure will exist there.
User needs to be inform about any other not mentioned possibilities. This includes more different cases but we could define three main proactive support for Information, Warnings and Suggestions. These could user obtain during her work with (or move over) current code in the Source editor. Typical examples are: unused elements, wrong modifier, errors with usage of '=' in conditions, null pointer prevention, try-catch correction, parents usage etc.
User should invoke this support tool by keyboard easily and by keyboard as well. Then user needs to know that such kind of support exists. Popup menu like Code Completion is for this case too disturbing but small sign (by current cursor position or in the Left Margin of Source Editor) says, that something is accessible is enough.
This chapter is about concrete parts of UI framework for features based on the MDR.
Each following UI concept covers certain mentioned scenarios (modes).
This part is draft still and will be updated unceasingly till a final version will be done. There are still any open issues which should be discussed and solved.
Main goal of refactoring support is to improve user's source code without changing its
This chapter describes mainly manual invocation of any refactoring action and automatic detection, when refactoring is needed is defined in Support chapter. But main flow remains the same.
A basic group of refactoring actions is specified here as well (e.g. Rename..., Move..., Copy..., Save Delete..., Extract, Inline, Push members Down or Pull members Up, Change method parameters, Organize Imports, etc.).
We should provide consistent flow for each action of refactoring group and it it's defined by these steps:
- Invocation of refactoring command - Manual invocation from source editor or automatic one (e.g. after renaming any class name in the Explorer ).
- Possible warning messages - User would select code wrong, then isn't possible to process selected action. Or any problems with unsaved sources could happen. Then any quick information should be displayed.
- Set of parameters - What should be changed for what and where, new name or position in package, allow preview mode etc.
- Possible problems - If refactoring action could cause big problems after execution of it, then warning message with list of that warnings should be displayed. This step could be merged with next one maybe > open issue
- Suggested changes with or without a preview - List of recommended changes with confirmation by each. If Preview mode was selected, then it will be presented too.
- Confirmation and execution - User confirms all changes and execute refactoring action.
- Undo action - This is important part of each refactoring action and should be promoted.
It isn't necessary provide all steps for each refactoring action or set of parameters
could be split up into more steps sometimes.
User could leave out confirmation or preview step and invoke execution of refactoring action exclusive of that two steps as well.
Follow part defines each step at length.
Invocation of refactoring commands
There are two cases how refactoring action could be invoked:
- Manually from Context Menu in the Explorer or in the Source editor (possibly from Main menu> open issue). There will exist menu item with name "Refactoring..." with all refactoring actions as sub Items.
- Automatically after any change of code, when is its need is recognized. Or any change of name or place of object file in the Explorer could happen. Then this change could affect more places (files) then only current one and refactoring should start again.
Possible warning messages
When user invokes refactoring from a source code, then there are cases, when isn't possible process it. These cases include following:
- Bad position in code (e.g. The caret should be positioned at the name of the method to be refactored).
- Wrong selection of object in source code (e.g. Selected Block should represent a set of statements or an expression).
- Action which is forbidden in current context (e.g. Inner classes could not have static method for refactoring action called "Make Method Static").
- Syntax error in source, then it isn't compilable
- ...others ?...open issue
Then right and clear warning and description about it should be displayed.
Set of parameters
This step could be expressively different for each refactoring action and here user
affects next course of them.
There are any examples:
- Rename Class ... New name, Checkbox Search in comments and Strings, Checkbox Search in non-java files
- Move Method ... New receiver, New Method name, Original Receiver parameter
- Inline Method ... Choice about Inline style (Inline all invocation and remove the method, Inline this invocation only and keep the method)
- Inline Local Variable ... No settings, only count of occurences
- Inline constant (static final field)... Choice between all references or only selected one, Checkbox for delete constant declaration
- Extract Method ... Name of method, Table with Parameters, Small Preview Area
- Change Method Signature ... Name, Access Modifier, Return Type, Customizable Parameters
- Made Method Static ... CheckBox Replace usage qualificators with class references
- Encapsulate fields ... List of all possible fields from current code, chance to set name for getters and setters, fields visibility (private, package local, protected, as is), accessor visibility (public, protected, private, package local)
- Move Inner Type to Top Level ... Name for enclosing instance, Checkbox for Mark the enclosing instance field as final.
Concrete design of some mentioned refactoring action you can find at this address: http://ui.netbeans.org/docs/hi/javamdr/refactoring_design.html
Typical components at the bottom of parameter dialog:
- There is possibilities to show preview of all changes in the Output area (a checkbox in left-down corner of dialog should be persistent).
- Finish button - It will finish action immediately with all changes.
- Cancel button - It cancels actual refactoring action completely.
- Help button - It invokes Help page which describes actual refactoring action and its parameters.
Additional behavior of parameter dialog:
There is area above buttons on the bottom, which is intended for:
- Online error checking - When is possible to detect any error during change of
parameters, then user should be informed about it immediately with this style:
- Non editable TextField with grey border
- Fatal error - Red text "Error:" with black text of description. Finish button is disabled.
- Non fatal error - Red text "Warning:" with black text of description. Finish
button is enabled and user could continue with Refactoring action.
When Finish button is disabled, then user should repair parameter, which causes this error warning or could Cancel refactoring action at all. Error message will disappear and Finish button will change itself to Enabled state, when parameters are ok.
- The same area should be used for a progress indication - User selects Finish button and
then indication about progress of Refactoring action will appear:
There could exist more steps of Progress indication and Buttons plus Checkbox are disabled during each step.
Error panel will appear (see figure below) on the same place as parameter panel exists, when some problems is detected after click on Finish button. It contains a list of fatal or non-fatal errors.
Buttons on the bottom have following behavior:
- <Back - It invoke Parameter panel again, then user could change any parameter quick.
- Finish - It's disabled when there is some fatal error. If not, then user could continue in refactoring action.
- Cancel - User could Cancel actual refactoring action in each partial step.
- Help - Will invoke help content, which describe fatal and non-fatal error meaning.
There is another possible way how to inform user about errors, but it should be discussed more:
- The same dialog could appear above dialog of parameters with another title (e.g. Founded Errors ? )
- It will contain the same content as above, but name of buttons will be different (Repair Parameters, Continue Anyway) and there will not exist Cancel Button.
- Dialog will disappear, when user selects Repair Parameters button and user will catch in Parameter dialog again.
- Both dialogs will be closed by Continue Anyway button.
Suggested changes (with or without a preview)
This list will appear when user affirms settings for a appropriate refactoring action.
Any actions are simple and suggested change will affect only one place in a code, but
there are massive actions (e.g. Renaming or Move any code element) on the other hand,
which affect many places in a Project. First steps of flow are the same, but then two ways
exist. Output Area is right place for list of suggested changes in a case, when many of
them are founded. But some refactoring action are better to provide and finish in the
dialog (e.g. Change method signature).
Confirmation and execution in the Output Area
List of suggested changes will occur in a tree structure in the Output Area. Then user won't be blocked from code, give her more freedom to see a code during a refactoring action. But there should exist any technique for that case, when user make changes in a code on the other hand.
Content of the Output area:
- Each refactoring action has own "Refactor TAB".
- Content inside is in a tree structure.
- First node of that structure contains text information about actual refactor action.
- Following four categories could exist under this root node (Changes in the Java code,Changes in a Java Doc,Changes in Comments and Strings,Changes in non-Java files).
- Then suggested changes are displayed in the tree view with checkboxes by each node under each category.
- The tree has these two state:
- Logical view - Nodes with changes are visible under structure of packages, classes and methods as a leaves.
- Files view - Nodes with information about changes are visible under file nodes.
- Information about change contains part of affected code (short preview) and position in this code.
Design of the Output Area:
Basic user action:
- Include or Exclude concrete change by clicking on Checkbox.
- Double click on node will open code in the Source Editor as a new TAB and cursor will appear at a concrete position.
- User uses "Do Refactoring Now" button for final confirmation and completion of refactoring action.
- User could cancel all suggested changes by "Cancel Refactoring" Button.
Actions on a Context menu:
- Show in Source - This action will open Source code after double click on a node.
- Show Diff - Will open source code as a diff (i source editor or in dialog> open issue).
- Refresh List of Changes - It runs searching for changes again.
Possible Tool Bar with additional actions:
Toolbar has a logical place on left or right side of Output Area and it could contain these actions:
- Refresh list of Changes
- Invoke Parameter Panel again
- Expand or Collapse All Nodes
- Show Logical View
- Show File View
- Export Into File
- When user changes code then some checkbox (by affected suggested changes) will change state to disabled one.
- When user invokes "Do Refactoring Now" action with some of disabled checkboxes, warning about it and offer for refresh changes action will appear.
- When Do Refactoring action is preformed, then Progress indication will appear and content plus buttons will be changed to disable state.
These steps should work for all refactoring actions. Then user will trust to refactoring at all. System should recognize, that Undo history invoked from Menu or by shortcut is relating to Refactor action, then information about reverting of all changes will displayed as a dialog. User needs to know, that bigger Refactor Undo action is prepared.
Example of Rename refactoring action
When user would like to rename any element (package, class, interface, method, field)
from "Context Menu>Refactoring" Menu Item, then small dialog for setting
parameters will be invoked.
The same dialog appears when user use suggestion offered by proactive support icon after element name change in a code or in the Explorer by double-click.
First step includes set of options and follows confirmation step with suggested changes in the Output area.
Step with options and filters
User sets new name for selected element and chooses places where should be element searched. There are these possibilities:
- Search references in the Java code
- Search references in comments and string literals
- Search references in non-Java code
Then user could continue in the Rename action with or without preview. Action will be accomplished immediately by "Finish" button or canceled by "Cancel" button.
Step with confirmations
Preview of suggested changes exists in this step. Founded places in a code are
displayed as a tree structure (packages, classes, methods and places where element is used
at the end).
Each founded place has a preview text with a piece of code, where concrete element is highlighted (by bold text).
User can open each suggested change in the Source editor or she could remove some changes by checkboxes situated by each node in the tree structure.
Finish button invokes last step of Rename action and progress indication will inform about rest of work.
Then she can compile sources and test functionality of code. If refactoring action causes any error, then she can use Undo action, which reverts code to a state at the start.
Current Explorer isn't right place where user could obtain sufficient exploring structure of classes and their interconnections. Moreover, Explorer will change more to logical view because of Projects implementation in the future. And we need a better method (place) for inspecting a code structure. Class Browser could solve this.
User needs a tool for inspecting a code structure and which could provide information about meaning of elements (classes, interfaces, methods, fields) at the same time. New and complex Class Browser window will cover browsing mode easily. It has four parts:
- Toolbars on the top - It contains buttons and Combo box, which affects content of left or right tree. Combo Box is filled dynamically and its content depends on selection in the left tree.
- Left navigating tree - There is visible structure of Filesystems (File View in Projects in the future!). It means packages, classes and all members under classes (interfaces too).
- Right content area - Content of this area depends on selected element in the left tree and on a choice in the Combo Box situated in the Toolbar.
- Preview area at the bottom - It's intended for showing information about selected element in the left or right tree. It could contain two different information (element description and code preview).
+--------------------+----------------------------------+ |[<] [>] [O] [F] | [Looks in a Combo] [E] [Filters] | +--------------------+----------------------------------+ |Left structure tree | Right content Area | | | | | | | | | | | | | | | | | | | +--------------------+----------------------------------+ |Preview Area | | | |Info about selected element | +-------------------------------------------------------+
All windows will be docked into Source editor, because there will be only dialogs and
docked windows (no undocked window) in the new Window System.
User could invoke this window from Main Menu>View. Another place will exist in a Context menu of Source Editor as a Menu Item (right name and place is open issue).
Toolbars of Class Browser
Two ToolBars exist at the top of the Class Browser window. It's situated above left and
right content area.
Their visual appearance should be the same like a ToolBar in the Source Editor has. It means color and height.
Left ToolBar contains these buttons:
- History Back [<] - Navigates one step back in the History
- History Forward [>]- Navigates one step forward in the History
- Open Button [O] - It opens selected element in the Source Editor as a new TAB and navigates into exact position.
- Find [F] - Invokes dialog where user will define expression for search with group of filters. Then results will appear in the Output window (see details in the Searching chapter).
And right Tool Bar contains these elements:
- Combo Box - User could change content of right Area by this Combo box selection. Content of Combo Box depends on a selection in the left side structure view.
- Expand Toggle Button [E] - It's situated by the right side of Combo Box.
- Filters [Filters] - Each look could have any filters associated. We have to define them => open issue
Description of History function
- History in this window means sequences of selection in the left tree, selection in the Combo Box and state of the Expand Toggle Button. Then right area will have exactly the same content like previously.
- User is able to navigate through history by two Buttons (History Back, History Forward). Navigating by any shortcuts is open issue.
- This history should exist only till when Class Browser will be closed.
Combo Box Content
Combo box contains something like set of looks that affects the Right area.
When isn't selected any node, then "<No Choice>" text appears in the Combo Box.
When any node in the left tree is selected, then Combo Box will be filled by following combinations:
- for selected class:
- members (inner class too)
- super class
- all subclasses
- implemented interface
- throw sites
- where used
- for selected interfaces:
- super interface
- sub interface
- for selected constructor:
- where used
- for selected method:
- who overrides
- where used
- for selected field:
- where used
If user changes a choice in the Combo Box, then the right area is filled by conformable content.
There is open issue about looks with usage meaning in this Combo Box. The better place
for this usage is in the Output window then in the Class Browser maybe.
Another open issue is default settings inside the Combo Box.
Navigation in Class Browser
Let's mention user flow and appropriate actions in the Class Browser.
- User will browse through a left content. Then preview area will display description of selected element and active links on its parent and its close member.
- Active links from Preview Area opens element on the left side when user clicks on it.
- Logical right content which is linked with left selection depends on Combo Box active choice and could be shown like a tree or like a list.
- When element from the right area is selected then preview area will display description for it.
- User is able double click on element in the right area and then element under mouse opens at the left side.
- Another way to open a selection from a right side on the left side and select a right look quickly, is possible from Context menu by "Show As" menu item.
Context menu above areas
Left and Right content area should have these Menu Items:
- Show As - Sub menu contains the same choices like Combo Box
- Open Source - Opens code of a selected element in the Source Editor
- Find Usage - Invokes Searching mode, concrete dialog with option for searching. Details are in the next chapter.
- Help - Any idea for a content ?
Contextual menu for Preview Area...open issue
Behavior of Preview Area
When is selected node on the left side, then Preview Area includes these two parts:
- Top - There is simple description about selected element plus additional info (e.g. nearest superclass or sub class > open issue)
- Bottom - This part consists from maximum three information which is assumed from Java
- Return value
Each title of noticed information will be displayed by bold and following information in normal text.
When is selected node on the right side, then Code Preview will be shown in the Preview Area (has it sense ?).
We have two different Find actions ("Find" and "Find in Files") in the IDE. But we need some different results when we need to search for logical usage of elements. So there is open issue about merge of search dialogs together or have different one in the future. My opinion is, that better solution is to merge standard Search in Files and Find usages together and use one place for results consistently.
Searching mode could be invoked from a Context Menu (in the Project TAB and from the Source Editor) or from a ToolBar of the Class Browser. Then Dialog will contain different settings, which depends on a type of selected element. Then user confirms settings and results will be displayed in the Output window as a special TAB with name Usages (or Where Used > open issue). User could go through history of results (back and forward) by Buttons situated in a ToolBar of the Output window.
- Read Access
- Write Access
- Occurence in File
Two modes of search will available:
- Quick search - When user invokes this, then usages in output depends on selected element in source code.
- Search with settings - Dialog with setting will appear before search action. There are parameters for type (Field, Method, Package, Constructor and Type) and limitation (Declarations,References,Implementors,Read Access,Write Access,Occurence in File, All occurrences) of search. CheckBox for Case sensitivity is next setting. Another possible (regular expression or characters * and ? as vicarious strings) > open issue.
ToolBar in the Output window:
It's situated in the Output area on the left side and contains following buttons:
- Run Search again - Only run Search once again
- History of Search results - It invokes popup list with all (any limitation is needed) previous search results.
- Previous occurence -
- Next occurence -
- Remove selected occurence -
- Remove all occurences -
- Export into file - Possibility to export current search results into structured file.
- Collapse all nodes - Search results have tree structure and it could be helpful to expand all nodes all of a sudden.
- Expand all nodes - The same as for Collapsing above.
- Group by packages - Toggle button, which makes package structure visible.
- Group by methods - Toggle button, which makes class and method structure visible.
There are these features which could improve navigation during developing of a code:
- Navigation throughout Context menu in Source Editor for:
- Open declaration
- Find Usages
- Navigation by icon in the left Margin column in the Source editor - E.g. When method overrides or implements any other, then clickable icons appear there.
- Code Navigator - Special component which improve navigation inside out active source and in classes around (superclass or subclass) too.
Code Navigator is tool which will support Navigation mode. It should be docked close to the Source Editor or created as a part of it (open issue). It's intended for a these users:
- User that knows a code structure well and needs to be navigate throw structure quick.
- User that searches something (fields, methods, linkages) in current source code or around it.
Code Navigator has two parts. First contains a tree Hierarchy View and second contains
the Outline view of currently selected node in Hierarchy View (node of current source is
selected by default). Typical place where Code Navigator has sense is by the side of
Source editor or under it.
There is a visible tree hierarchy related to current code in Source Editor. Type of this hierarchy depends on selected look in Toolbar of Code Navigator. There could exist three look:
- Type hierarchy
- Superclass hierarchy
- Subclass hierarchy
Outline View shows members of current selection in Hierarchy view with possible filters.
Here will be mention about proactive Code Assistant and cooperation with Task List.
Automatic detection, when refactoring is needed is defined in this chapter.
Also Inspection of Code feature is described here.
- Select Methods to Override...List of available methods, Checkbox for copy JavaDoc
- When system cannot resolve any symbol, then he could offer Create Class or Create Interface with estimated name
- Navigation by proactive icon at the left side by margin column in the Source editor.
Support as indication
This is used right in code as text with different color - This indication could be useable for unused fields, local variables, methods, imports.
Support with suggestion
This kind of support responds to current position in code. When any suggestion is available, then visible proactive icon will appear on the same row of code. It's positioned on the left side, where could not disturb user from coding. User could show suggested list of action by mouse click or by keyboard shortcut easily.
Then following list of choices should be maintained:
- When cursor is over declaration followed by = ... Split into declaration and assignment
- When selected void method cannot return a value ... There are two possibilities: Change method return type to 'Object', Remove return statement
- When selected non void method ... Create return statement
- When caret is after extends and xy is written there ... Create Class 'Xy'
- When caret is on any recognized class for import ...Create import statement
- Over import's position ... Remove unused import, Organize Imports
- next ones...TBD...
- There is open issue about looks with usage meaning in this Combo Box. The better place for this usage is in the Output window then in the Class Browser maybe.
- Another open issue is default settings inside the Combo Box in the Class Browser section.
- Right name and place for menu item which invokes the Class Browser.
- Filters associated with Combo Box in the Class Browser should be defined.
- Navigating by any shortcuts in the Class Browser.
- Contextual menu for Preview Area (Class Browser)