Community
Participate
Working Groups
From bug 362420: For having it in the trim or not this is indeed simple and just requires what we move some (all) of the model elements we currently add by code into the LegacyIDE model itself. This would allow RCP developers that don't want it in the trim to simply remove it form the model. We should contribute the SearchField through a fragment or an MTrimContribution/MToolbarContribution, something that can be wired off by RCP applications that don't want it. PW
One problem with this is that at least some folks don't want to lose the functionality, just the trim (i.e. they want it to work like in did before we introduced the trim widget). I'm certainly +1 that the starting LegacyIDE.xmi should contain *all* non-contributed elements and code like 'populateTopTrim'...should be removed.
If we move it to a model fragment in a separate plug-in, RCP application could decide if they want to have that feature included. This would solve the complains of 3.X RCP application that they get the search box after switching to Eclipse 4.
Agree with Lars Vogel
I've tried to move the code of the quick-access to a separate bundle, but it seams that this implementation uses a lot of internal classes from the workbench, e.g.: org.eclipse.ui.internal.keys.BindingService org.eclipse.ui.internal.menus.CommandMessages org.eclipse.ui.internal.misc.StatusUtil org.eclipse.ui.internal.IWorkbenchGraphicConstants org.eclipse.ui.internal.WorkbenchImages org.eclipse.ui.internal.WorkbenchWindow org.eclipse.ui.internal.Workbench org.eclipse.ui.internal.WorkbenchMessages org.eclipse.ui.internal.WorkbenchPlugin org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog org.eclipse.ui.internal.dialogs.PropertyPageContributorManager org.eclipse.ui.internal.dialogs.PropertyPageManager org.eclipse.ui.internal.e4.compatibility.CompatibilityPart ... So I think a simple extract and organize of the imports isn't a solution, because it would require x-Friends. It is also not possible to extend the list of providers because they are hard-coded. Maybe it's better to: * create a new extension point to provide QuickAccessProviders * register the current hard-coded providers via the new extension point and remove their hard-wiring * re-implement the SearchField and it's functionality into a new plug-in which uses the new extension point to provide the data to the user This would make the SearchField optional and extensible for other plugins.
(In reply to comment #4) > This would make the SearchField optional and extensible for other plugins. I like the sound of that. Many times I've wanted to type a potential class name into that search field just to see if something resembling it turns up. There's the search dialog, but this could be so much simpler and smarter.
There are other bugs about QuickAccess extensibility. That's not this one. René, thanks for taking a crack that this. But all of QuickAccess doesn't need to be factored out to satisfy the constraints for this bug. Option 1: Contribute QuickAccess through a fragment in org.eclipse.ui.ide.application that adds it in the correct location. The IDE will get it, and RCP apps won't. Any RCP apps that want it can add it themselves. Option 2: Tie the contribution of the SearchField to a tag on the MTrimmedWindow somehow. PW
(In reply to Paul Webster from comment #6) > There are other bugs about QuickAccess extensibility. That's not this one. Sorry I didn't realized that there is already a bug for this. > > René, thanks for taking a crack that this. But all of QuickAccess doesn't > need to be factored out to satisfy the constraints for this bug. > > Option 1: Contribute QuickAccess through a fragment in > org.eclipse.ui.ide.application that adds it in the correct location. The > IDE will get it, and RCP apps won't. Any RCP apps that want it can add it > themselves. > > Option 2: Tie the contribution of the SearchField to a tag on the > MTrimmedWindow somehow. > > PW So finally I found a solution for this, which allows you to contribute the QuickAccess to your Workbench via an application model fragment. It wasn't that easy as I thought, because nearly all of the model contribution stuff in the "org.eclipse.ui.workbench" is done via code and not via the LegacyIDE.e4xmi. This means after all the e4 application model processing (fragment, processor, ...) is done the workbench starts to contribute its elements via code and so all my contributions weren't in the model ;-( But I finally found a way, which can put the QuickAccess into any of the four sidebars. So have a look at: https://git.eclipse.org/r/19454
(In reply to René Brandstetter from comment #7) > But I finally found a way, which can put the QuickAccess into any of the > four sidebars. > > So have a look at: https://git.eclipse.org/r/19454 Does it work if you open a second workbench window from Window>New Window? Is it easy for an RCP app to not pick up the search bar? PW
(In reply to Paul Webster from comment #8) > (In reply to René Brandstetter from comment #7) > > But I finally found a way, which can put the QuickAccess into any of the > > four sidebars. > > > > So have a look at: https://git.eclipse.org/r/19454 > > Does it work if you open a second workbench window from Window>New Window? Yes, the new version on Gerrit does provide the QuickAccess in the second workbench window. I had to put the QuickAccess elements into a TrimContribution inside of the application fragment e4xmi. Thanks for the hint. > Is it easy for an RCP app to not pick up the search bar? If a RCP app doesn't provide the QuickAccess element in its model, than it will not be visible. So the default is no QuickAcces, easy enough? :) I've took your suggestion and put the contribution only into the "org.eclipse.ui.ide.application". This bundle provides a new application model fragment named "LegacyIDE_fragment.e4xmi" which contains a TrimContribution for the main toolbar. The TrimContribution puts the ToolControls of the QuickAccess into the main tool bar and the WorkbenchWindow#positionQuickAccess() method moves them to the correct location. This move-step is required because the default "position in list" of the TrimContribution doesn't work, due the fact that the reference element (=after:PerspectiveSpacer) is added via code long time after the "position in list" has been called. > > PW
Released fix as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=839ee2d7fec814e08fdd1d5461d1779684e44aea and modified copyright with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c61f1fb3ef7f4df6e23b73f1499a8235e430ae12 Thanks René PW
This functionality is useful for non-IDE RCP apps though.
They can contribute it through their own fragment. The difference now is it's not for free PW
Verified in I20140120-2000.
I think this fix is the cause for bug 426224
Instead of using a fragment you could use a processor!
Yes but with the processor it's harder to position the elements to a specific place and as I wrote already in https://bugs.eclipse.org/bugs/show_bug.cgi?id=426224#c5 there is a clean-up of the legacy elements. I will check if there is a problem with it.
(In reply to René Brandstetter from comment #16) > Yes but with the processor it's harder to position the elements to a > specific place and as I wrote already in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=426224#c5 there is a clean-up > of the legacy elements. I will check if there is a problem with it. No, it's OK, I'll explain in the other bug PW
