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.
JavaFX_NB_Plugin_Franca_NB_65_fixes_latest_SDK_installer Product Version: NetBeans IDE 6.5 (Build 200901141801) Java: 1.5.0_17; Java HotSpot(TM) Client VM 1.5.0_17-b04 System: Windows Vista version 6.0 running on x86; Cp1251; ru_RU (nb) Userdir: C:\Users\Maria\.netbeans\6.5 Editor UI for resolving ambiguous imports should be the same as for standard Java project.
Assigning to Rasta, the new UI author. Rasta what do you think? Will you change the UI for Java as well? ;-)
Should be is not enough. Please provide usability study which requires same approach and specify which one is better. Then we can discuss more about this requirement.
There is only one dialog that allows to choose a correct import for all non imported classes in the Java editor.
reassigning to new owner.
Number of dialogs is just one of many criteria, I UI reviewed the two approaches and they both have their pros & cons. However, the Java FX approach seems to be better of the two for the following reasons: 1) User can see the context the class is used in. 2) Typically when adding code gradually, there is only 1-2 broken imports. In this case, it doesn't make the process any longer. When a large piece of code is copy&pasted or a new project is opened, there are many broken imports, but user is more likely not to be familiar with the code, so the context the class is used in is of even more importance (see point 1). However, the current Java FX implementation has some problems which need to be addressed before it comes into general use: a) the identifier imports are being fixed for is not clear. It needs to be highlighted in the text. b) the drop-down menu is sometimes shown beyond the editor boundary (when the identifier is on the last visible line) c) after all imports are fixed, user should be returned to the original "frame" - they should see the same code area as when they invoked the code. Also discussed with msauer (adding to CC), responsible for the Java editor. As a result, I suggest to close this issue as wontfix and create a new issue to Java to change their approach.
I have re-assigned the issue to Max and changed the category to Java. Also added Rasta and myself to Cc. Max - as the UI should be the very same for both Java and JavaFX (and maybe for other languages) I suggest that you think also about being able to provide some API so we don't duplicate the code in all the languages (if that would be possible).