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.
The instructions in the import management wizard say "By default, import statements are created when fully qualified names (FQN) occur more than the Maximum FQN specified." Specified where? There is no clue to help the user find this setting. It would make the most sense for these to be editable within the wizard. For example, I prefer to use package imports a lot of the time, and so usually what the tool does is not actually what I want. It should be easier to change this when you already have the wizard open.
Assigning to subcomponent owner.
"Specified where?" There is a help available for each panel of the wizard (just press help), all information (about the setting too) are in this appropriate help page.
Probably would be good to open this on nbui@ , I'm also changing this issue from a defect to enhancement.
CCing Maya, HI that helped to design this wizard.
I don't think reading the help is the right thing here for three reasons: - The wizard is a modal dialog. Even if I read in the help where to change the defaults, I can't actually change them without closing and reopening the wizard. - The help will disappear when I close the wizard, because the modal wizard dialog owns the window. So I have to hope I remember where in the options tree the help said to go. - Depending on what I'm writing I may want different settings - for example, if I am writing example code for someone to read, I probably want FQNs because they will not be familiar with the packages. If it's for my own use, I don't want the clutter. - You can see very quickly if the tool's defaults are not to your taste, on the second screen of the wizard. Since the point of the tool is to automate something and save time, it's much better to be able to tweak the settings and get it right within the tool. BTW, it doesn't have to expose the numbers - just a drop-down with "Minimal use of FQNs" and "Heavy use of FQNs" would do it (ignore whether to do individual or package imports - it's low impact).
There are several pending issues about the IMT - many of those have resurfaced here and in the nbui thread. So I am hoping we get a chance to (re)design this in the 4.0 time frame....
In the interest of doing more than just whining about an issue (as Jarda says, one thing about open source is that if you want something to happen, you have to actually write the code), I'm working on a patch for this enhancement in my spare time. If it actually turns into anything, I'll attach it.
Tim, I Look forward to seeing that ! Being able to spend some time on design before the design is implemented and having that design reviewed by peers before it is implemented has been known to work.... :):)
Created attachment 5609 [details] Patch for the Java module which adds settings to the dialog in question
Created attachment 5613 [details] Binary patch - put in $NB_HOME/modules/patches/org-netbeans-modules-java/
The attached patch adds a component to the screen with a drop down for some sane defaults and a button for accessing the full property sheet for ImpToolSettings. Note - probably the new component should be moved *above* the TreeTableView - the form editor in my current build of NetBeans complained about the .form file in the CVS checkout, so the code manually adds it to a free region of the layout, which happens to be at the bottom of the pane.
Note that the TreeTableView dynamically updates itself when you change settings in current dev builds. In NetBeans 3.3.1 the TreeTableView seems to ignore replacing its root node, so the FQN/import settings don't change immediately when you change settings.
Hmmm, I sent this patch in almost a month ago - I'm pretty confident the code is quite solid and could be integrated without any problems. Has anyone looked at it, and would anyone consider integrating the patch, or is it being quietly ignored? It does, IMHO, make a significant improvement to the effectveness of the import management tool.
The main problem is not your code but feature itself. 1) I don't think that settings for IMT are used very frequently. They are likely to be experimented with when the user discovers the tool, or during large-scale setup and customization of the whole IDE to suit the user's working style. After that initial phase, they will be accessed rather rarely. 2) Adding setting to the tool itself seems to me strange from UI/HIE view. What makes them so special? If there is not special about them, why aren't there editor settings in Editor? Why are not there substitution keyword table in New from Template wizard? Did you ask someone from UI/HIE to agree on your UI? 3) It seems to me strange to create new code just for the reason that you was not able to find documentation and/or documnetation is incomplete and it is hard to read documnetation from modal dialog. I am sorry, but at the moment I do not consider integration of the patch for NB 3.4.
> The main problem is not your code but feature itself. > 1) I don't think that settings for IMT are used very frequently. > They are likely to be experimented with when the user discovers > the tool, or during large-scale setup and customization of the > whole IDE to suit the user's working style. After that initial > phase, they will be accessed rather rarely. I agree, they are not used very frequently. But honestly, which is the more likely behavior pattern, with it set up as it is now: 1. User sees "Import Management Tool" and says "Oh, cool - this will save me a lot of time!" Then uses the tool, and finds that it does not do what they want with the defaults. To, for example, exclusively use package imports, the defaults need to be changed, or the contents of the TreeTableViews need to be manually edited. User closes the dialog (after maybe bringing up the help, which will also get closed), then navigates through the massive options tree to find the setting, reopens the tool with the new defaults - maybe they are right, or maybe they need to close it again and change the defaults once more. Finally they get it doing what they need. or 2. User sees "Import Management Tool" and says "Oh, cool - this will save me a lot of time!" Then uses the tool, and finds that it does not do what they want with the defaults. The current dialog doesn't help them to find or change the defaults. User says: "Screw this - it's faster to just make the changes in the editor" and never uses the Import Management Tool again. I think 2. is the more predictable scenario. > 2) Adding setting to the tool itself seems to me strange from > UI/HIE view. What makes them so special? If there is not special > about them, why aren't there editor settings in Editor? It might be a good idea to have editor settings in the editor. If I were clueless, that's the first place I'd look for editor settings. Two points: 1. This is not a "slippery slope" case - if we add settings to one tool we must therefore add them to all of them. 2. The editor is not a *modal* dialog. You can be using it, and go adjust the settings painlessly. The import management tool is a modal dialog. The current behavior is sort of like entering a locked room, and then finding out that you need something that's behind the locked door. Maya, you're on the CC list. Is it strange workflow to be able to modify settings for a wizard that will perform its action based on those settings from within the wizard? > Why are > not there substitution keyword table in New from Template wizard? > Did you ask someone from UI/HIE to agree on your UI? Maya is on the CC list. I'm adding Jirka and Ian. > 3) It seems to me strange to create new code just for the reason > that you was not able to find documentation and/or documnetation > is incomplete and it is hard to read documnetation from modal > dialog. Please reread the rest of the discussion on this bug. It has nothing to do with finding documentation. The problem is that the wizard will do something which probably isn't exactly what the user wants, and there are way too many barriers between the wizard and the settings for it. It is not a documentation problem, it is a workflow problem. Completely unconnected to documentation - the documentation will not help you, because you still are in a modal dialog, and so you have to close it to change the settings. > I am sorry, but at the moment I do not consider integration of the > patch for NB 3.4. Thank you for the feedback - I hope my comments above clarify why I suggest changing the dialog. -Tim
It appears I'm not the only one with issues regarding this - see: http://www.netbeans.org/servlets/ReadMsg?msgId=121277&listName=nbusers and a message that arrived on nbusers within the last couple of hours (not yet indexed on netbeans.org): ---------------- I am trying to configure the Import Management Tool and I am having some problems. The help says the following: a.. From the main window, choose Tools > Options, expand the Editing node and the Java Sources node, then select Import Management Tool Settings. The problem I have is that the Java Sources node cannot be expanded. Please help! P.S. I am running NB 3.3.1 (Build 200202011224) on Windows 2000 with Sun's 1.4.0 JVM. ------------------------------------- I don't know, but I'm guessing the probably the user can't expand the Java Sources node *because* the modal dialog is open.
Set target milestone to TBD
If we're not removing the import management tool for 3.6, could we at least do something about this issue? There is a patch attached which will solve the problem.
Import Management Tool was replaced by Fix Imports action in promoD. It is simplier action and doesn't confuse users with wizard or FQN.
Reorganization of java component