Bug 226286

Created attachment 131540 [details]
Proposed Patch

Please review the following changes in module api.search.
Thank you.

(Taken from apichanges.xml:)

Controls for specifying search scope options can now be split into two panels - one for scope options, and one for file name options.

Class ComponentUtils has new method adjustPanelsForOptions(JPanel, JPanel, boolean, FileNameController), that takes the two panels. It can be used instead of adjustPanelForOptions(JPanel, boolean, FileNameController), that puts all controls into a single panel.

Class ScopeOptionsController has new method getFileNameComponent() to get the panel with controls related to file name. (The panel related to search scope can
be get using getComponent()).

Jaroslav, 

if you have found a reason for this split, don't you think that someday you may find another reason to have 3 panels instead of two? And if it is a possible thing to happen, don't you want to have a list of panels or to have some SPI like searchPropertiesPanelsProvider that will be used to get all possible panels and use their registration 'position' as a way for arranging them in the final search dialog? 

=Andrew

(In reply to comment #3)
> ...don't you want to have a list of panels or to have some SPI
> like searchPropertiesPanelsProvider that will be used to get all possible
> panels and use their registration 'position' as a way for arranging them
> in the final search dialog?
I was considering more generic solution, but at the end I chose
the simpler API. The reasons were:

1) The purpose of the adjustPanel(s)ForOptions is to help create panel that
   looks  the same as the panel in the default search provider and that lets
   you set all options supported by SearchScopeOptions (so authors of custom 
   search providers can have UI consistent with default provider).

2) If some search provider needs custom layout (or subset) of controls for
   search scope options, it can compose custom panels, without
   ComponentUtils. (This can be more straightforward and not much more
   difficult than using panel providers.)

3) If we someday decide to have 3 panels, we would probably add new variant of
   adjustPanelsForOptions that takes 3 panels. The advantage is that
   clients that use only two panels will not be affected at all (which is
   mandatory requirement, I think). So, yes, another API change will be
   needed, but I hope it isn't a big problem.

I've also considered creating the UI change without API change (item 2, which is still viable solution), but that would partially break the purpose of the ComponentUtils API (item 1).

What do you think?
Thank you for you comments.

Jaroslav,

I see your point. Actually I'm pretty much sure that two panels should be enough and it is unlikely that 3rd parameter will be needed at some point... That's why I don't really insist on either solution. If you still OK with what you propose (after answering the question) then I'm OK with that as well ;)

(In reply to comment #5)
> I see your point. Actually I'm pretty much sure that two panels should be
> enough and it is unlikely that 3rd parameter will be needed at some point...
> That's why I don't really insist on either solution. If you still OK with what
> you propose (after answering the question) then I'm OK with that as well ;)
Thank you very much, Andrew. I'm still quite OK with the proposed solution.

So, if there are no objections, I'll integrate the patch tomorrow evening.
Thanks.

Integrated as http://hg.netbeans.org/core-main/rev/6b55bbd6cc2f
Thank you for reviewing.

Integrated into 'main-golden', will be available in build *201302282300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/6b55bbd6cc2f
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #226286: Find in Projects dialog: Split scope settings panel