| [SearchUi] Dependencies & customization of search UI [message #625648] |
Wed, 22 September 2010 09:40  |
 Christophe Fondacci
Messages: 95
Registered: July 2009
Location: Paris |
Member |
|
|
Hello all,
I am using the org.eclipse.search plugin to implement custom search in my RCP application (providing custom search pages).
There are some problems with this :
1) The search plugin has dependencies on :
** org.eclipse.ltk.ui.refactoring which brings many other unwanted dependencies like team.core and team.ui thus causing unwanted contributions (team synchronization views and perspectives, mainly)
2) The search plugin provides a default "file search" page (which, by the way, implies other dependencies to resources, filebuffers). I understand that this is for convenience but the problem is that all RCP apps are not file-based applications.
Typically, I would like (at least) to "hide" this File search everywhere it is shown (menus and search dialog). I saw that the dialog is "customizable" by the user allowing him to select the pages (tabs) he wants to see in the search dialog. But I cannot find a way to "preset" these settings in my RCP app, as these settings seems to be stored as specific XML settings in the workspace metadata. I could only preset preferences...
Is there a way to do this ?
More generally now, is there something planned to make the search features more "modular" so that RCP developers will be able to only take what they need. For example, we could imagine a org.eclipse.search.core with raw features, an org.eclipse.search.ui layer on top of it that implements menu contributions, views & dialogs and then an additional org.eclipse.search.file which would provide implementation for file-based searches (and which may depend on refactoring aspects).
From what I have seen, the search architecture itself seems pretty modular and could handle this split easily (except maybe refactoring features...). The only problem is that everything is bundled together... From a RCP development point of view, this is a bit weird to me to add dependencies and at the same time tweak the contributions to remove some...in the magic world of OSGI.
Thanks a lot to everyone who could give me ideas on how to remove unwanted contributions (for now), and how we could solve the long-term dependency problem. I think I can help with the development if you like...
Christophe.
http://www.nextep-softwares.com
|
|
|
| Re: [SearchUi] Dependencies & customization of search UI [message #625915 is a reply to message #625648] |
Wed, 22 September 2010 10:38  |
Dani Megert
Messages: 3802
Registered: July 2009 |
Senior Member |
|
|
Christophe Fondacci wrote:
> Hello all,
>
> I am using the org.eclipse.search plugin to implement custom search in
> my RCP application (providing custom search pages).
>
> There are some problems with this :
>
> 1) The search plugin has dependencies on :
> ** org.eclipse.ltk.ui.refactoring which brings many other unwanted
> dependencies like team.core and team.ui thus causing unwanted
> contributions (team synchronization views and perspectives, mainly)
>
> 2) The search plugin provides a default "file search" page (which, by
> the way, implies other dependencies to resources, filebuffers). I
> understand that this is for convenience but the problem is that all
> RCP apps are not file-based applications. Typically, I would like (at
> least) to "hide" this File search everywhere it is shown (menus and
> search dialog). I saw that the dialog is "customizable" by the user
> allowing him to select the pages (tabs) he wants to see in the search
> dialog. But I cannot find a way to "preset" these settings in my RCP
> app, as these settings seems to be stored as specific XML settings in
> the workspace metadata. I could only preset preferences...
> Is there a way to do this ?
You could try to remove some of this via activities extension point.
>
>
> More generally now, is there something planned to make the search
> features more "modular" so that RCP developers will be able to only
> take what they need. For example, we could imagine a
> org.eclipse.search.core with raw features, an org.eclipse.search.ui
> layer on top of it that implements menu contributions, views & dialogs
> and then an additional org.eclipse.search.file which would provide
> implementation for file-based searches (and which may depend on
> refactoring aspects).
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=77424
Dani
>
> From what I have seen, the search architecture itself seems pretty
> modular and could handle this split easily (except maybe refactoring
> features...). The only problem is that everything is bundled
> together... From a RCP development point of view, this is a bit weird
> to me to add dependencies and at the same time tweak the contributions
> to remove some...in the magic world of OSGI.
>
> Thanks a lot to everyone who could give me ideas on how to remove
> unwanted contributions (for now), and how we could solve the long-term
> dependency problem. I think I can help with the development if you
> like...
>
> Christophe.
> http://www.nextep-softwares.com
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.02252 seconds
] 
Search
Help
Register
Login
Home
