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 ***