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.
We need support for searching Java classes with GoToType-like dialog. Instead of opening the file, it would return FQN (or ElementHandle). Same functionality was provided in old Java infrastructure and it makes sense to reuse the existing code. It would be nice to have also possibility to define classpath and possibility to defined supertype of searched classes (e.g. only those who extend java.lang.Exception)
AFAIK exactly this functionality is provided by the ClassIndex class. Providing GUI as an API is not our plan.
We don't need the GUI as an API. We rather need something like: UiUtils.browseType(ClasspathInfo cp, ElementAcceptor acceptor); The return type is not clear, it should probably be a pair of (FileObject, ElementHandle).
Huh. And what's so wrong about the ClassIndex? Sorry but I don't get it. As mentioned above it does exactly what you are asking for.
Nothing is wrong about ClassIndex, but it's not what we want. We want to allow the user to browse a type, so we want (almost[1]) exactly the same dialog that the Go To Type action displays. We don't want to write (or copy it from java/source) and maintain that dialog. [1] we will probably need to customize the title, and if you intend to introduce an "Open" button we would probably need to customize that as well.
You said "We don't need the GUI as an API.". But from your last post I don't feel thi is true. "we will probably need to customize the title, and if you intend to introduce an "Open" button we would probably need to customize that as well." Sure, then you will need to switch of location field. Tehn you will want to switch of project only classes checkbox and then ... BTW the current dialog is not what you want. It does not show only classes in one project. This is exactly what I want to avoid here. I don't see what is so hard to clicking in one form in Matisse. Once again, providing GUI as an API is evil and we do not intend to do so.
Re. GUI as an API: when I said that I thought you were afraid that we were requesting an API method returning a JPanel or something which would allow us to directly customize the UI; I wanted to assure you that was not what we wanted. But you are right: yes, in a way we are requesting GUI as an API. However, you are not giving any good reason why it is "evil". You are just pointing out that the API may need to evolve in the future and declare that need for evolution bad. Any API needs to evolve -- why not a GUI API? There is no request to show only the project classes. The request is to allow passing a ClassPath or a ClasspathInfo. The classes to be displayed would be taken from there. It's not difficult to design that form in Matisse. What's difficult is maintaining it and ensuring it is consistent with the java/source's Go To Type dialog. If we consider that a pack (e.g. VWP) might require the same functionality and they will have to copy the form too, then the same code (with the unavoidable minor differences that won't really help NetBeans look consistent) will be in NetBeans three times. Now that's evil. The "just copy it" answer when people ask for APIs is a plague that will need to be addressed at some point. We can't expect people to write NetBeans modules and at the same time tell them "well, just click it in Matisse". Those people have a problem to solve. Instead of letting them focus on that problem, we force them to waste time reinventing the whell and to accept the burden of maintaining that wheel. It can be our choice. But then we should not be astonished when they choose to write their modules for another platform than ours. A platform that has the wheel readily available: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/ui/JavaUI.html See the createTypeDialog() methods.
Created attachment 36706 [details] a terrible, terrible hack
I just attached a hacked-up version of GoToSourceAction and its associated classes. I do NOT recommend this for inclusion in NB. This is just some code that people can use in their apps. It requires an impl dependency on java/source. After talking with Hrebejk, I've come to the conclusion that NB should provide something to help users browse for classes, but not necessarily the whole GUI. ClassIndex by itself, though, is not enough. If java/source provided a way to generate a filterable ListModel from the RepositoryUpdater, that would go a long way. A separate issue would be to have the GoToPanel (without the model) available as a generic bean in some non-java/source related module. Or, maybe there's something in SwingX already, and GoToPanel should be replaced with it. Who knows?
> after talking with Hrebejk Is that discussion publicly available? The ListModel is nice, but in order to get what is in the Go To Type dialog we might also want a ListCellRenderer. So perhaps there could be a method like UiUtils.connectBrowseTypes(JListBox) // or a better name which will do whatever is needed to make the passed list box look and behave the same way the one in the Go To Type dialog does (set a model, set a renderer, etc.). Note that providing solely such a method, i.e. not providing an equivalent of what I required in desc3, would mean creating an API without listening to feedback from the clients -- an API which doesn't meet the clients' needs.
Whoops. That wasn't me speaking, that was my .NET past. Should be "JList", not "JListBox", of course.
Well, the discussion is not publicly available. However I'll try to summarize here what we've been talking about. But before that: Ad arguing for your solution with Eclipse) Looking at: http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IAdaptable.html you will find that the API you mentioned is not the only mistake in Eclipse originating in NetBeans :-). And now to GUI as API: Ad UI as API) I really dislike doing it. We did it several times and it we always had problems. The main source of the problems is that the maintainer of the API has to solve problems he can't see into. Say we Have and API A and two modules M1 and M2 using A. Now M1 has requirement to add a new check box. It is added into A. But M2 dislikes the check box and does not want to have it. OK we'll add a way into A to disable the checkbox. (Notice that I'm not mentioning backward compatibility at all). Now assume that we are talking about "n" checkboxes (or whatever GUI elements) and "m" modules. You have to admit that the maintainer of A does not deserve that hell. Please notice that the reasons for all those complicated additions/removals and changes are in someone's else competence. The API maintainer does usually not know all the gory details about what's needed and why. He just makes his best to maintain some hashtable of strange properties and prays everyday for not breaking someone else's code. Ad solution) Unlike SWT, the Swing is written that way that you can publish models. Model is something what is easily testable. It is also possible to wrap it into other model. (In our case of ListModel you can use it not only in ListBoxes but also in Combos and Tables - with little work) Ad CellRenderers/CellEditors) Yes, publishing some default renderers should be OK as well. On the other hand it is not hard to write your own. Sometimes it is even desirable that you write your own. In many cases you even need it. (Also notice that in this case there are methods available for doing so) Ad your last notice) "Note that providing solely such a method, i.e. not providing an equivalent of what I required in desc3, would mean creating an API without listening to feedback from the clients -- an API which doesn't meet the clients' needs. ". I don't get it. If you don't get exactly what you ask for we don't listen to users? Well, to some extent yes, but we do so deliberately in order to keep the cost down :-) OK, this is my opinion on GUI as API. I've been talking about that with few people already and we usually agreed on this solution. However, I agree with you that using it is little more complicated than plainly publishing the GUI component. And also the initial design of the API usually requires more work than going to add something like: UiUtils.browseType(ClasspathInfo cp, ElementAcceptor acceptor);
Re. your argument concerning A, M1 and M2: so instead of at least serving M2 and forcing M1 to copy/paste (if you refuse to introduce the check box) you prefer to force them both to copy/paste. Note that you document the method as "creating a dialog for browsing a type", not as "a method with a text field and a list box and two buttons". You'll be relatively free to e.g. add a Location field or perhaps even a combo box. IMO most users of that method won't care about the new field and will be happy that they don't have to write code and that their module's behavior is consistent to the rest of NetBeans. But obviously your experience says otherwise, so could you please share some details about it, such as concrete information about the "several times"? Then you are talking about "n" widgets: a dialog like Go To Type is one of the most used dialogs in NB, and it has to be simple. It's quite unlikely that many widgets will be added to it. How many UI changes have been made to this dialog since 4.0 (not including the JMI/Retouche switch, since that was a huge incompatible change anyway)? "Model is something what is easily testable": is one of the reasons for not providing the dialog the fact that GUI is not easy to test, or perhaps the fact that NetBeans developers are not used to testing UI (not talking about jemmy/jelly here)? Re. your argument about Eclipse and IAdaptable: please read http://en.wikipedia.org/wiki/Hasty_generalization. The ListModel *and* the renderers are the real minimum and I hope you'll be able to provide at least that.
Ad hasty genralization) OK I've read that but I don't see where I commited a hasty generalization. Maybe you did. "It's in Eclipse then is's OK". Please do not tell me that I meant something like if they did one mistake all their APIs are bad. I did not. And it wound not be even funny. My comment was also acompanied with a smile. Ad other) Well, OK I have an opinion, you have an opinion. You think it is cool to give GUI components as API. I don't. Create some (maybe java.source.uiapi?) and enjoy its maintenance. I don't care. But I do care about my modules therefore I will not do so. I have enough. You are saying the same things again and again. If you read my prvious post I bet you will find all the answers to your new "arguments". (With exception of the testing paragraph. I don't get what you mean here.)
*** This issue has been marked as a duplicate of 114611 ***