Bugzilla – Full Text Bug Listing
| Summary: | [QuickAccess] Make "Quick access" optional | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Andrey Loskutov <loskutov> |
| Component: | UI | Assignee: | Lars Vogel <Lars.Vogel> |
| Status: | CLOSED FIXED | QA Contact: | Daniel Rolka <daniel.rolka> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | akurtako, andreas.kohn, apeeters, bcclo, benno.baumgartner, bsd, carsten.pfeiffer, christine, christophe.moine, daniel.rolka, daniellwu, daniel_megert, david.winslow, david_dresser, dirk.fauth, dpwegener, eclipse.dserodio, eclipse, eclipse, egalvez, elias, elvisd79, emoffatt, eostroukhov, flavio.donze, fmcato, fredrik.attebrant, gaguilar, ggrec, glenn.burkhardt, grcoldren, gregory.amerson, ibm, joasu, john.arthorne, Lars.Vogel, malcolm, manderse, marcolopespt, mchr3k, mentallurg, michael.warner, mirec.z, nico290382, nobody, normanx.schoene, orgler, peter, platerx, pwebster, remy.suen, Rene.Brandstetter, robert.munteanu, s.muecke, sakatoch, sebastien.arod, sergey, spamdefence+eclipse_bugs, stefanorth, strider80, sudol.wojciech, tanmatra, tsznuk, wolfgang.glas, wshuman3, zqian |
| Version: | 4.2 | ||
| Target Milestone: | 4.4 M7 | ||
| Hardware: | PC | ||
| OS: | All | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537131 https://bugs.eclipse.org/bugs/show_bug.cgi?id=500618 |
||
| Whiteboard: | |||
| Bug Depends on: | 431707 | ||
| Bug Blocks: | 433778, 453573 | ||
| Attachments: | |||
|
Description
Andrey Loskutov
I'd consider allowing it to be closed. But it will remain in the toolbar by default. PW (In reply to comment #1) > I'd consider allowing it to be closed. But it will remain in the toolbar by > default. Why??? Anybody considered that there are other options for it? Status line? Floating panel opening automatically below the toolbar/above the status line? A decent toggle button instead of large text field? What was the reason to change the 3.x appearance? (In reply to comment #2) > What was the reason to change the 3.x appearance? There are a lot of messages in the mailing lists and other bugs about this (dating back more than a couple of years) but the last discussion on this was bug 304440. PW Based on the other bug discussion, there was supposed to be a preference similar to heap status so that it could be removed and even not shown in general using plugin_customization.ini PW (In reply to comment #4) > Based on the other bug discussion, there was supposed to be a preference > similar to heap status so that it could be removed and even not shown in > general using plugin_customization.ini So let re-phrase the original request: 1) We need to add a new preference under Preferences->General->... about show/hide the quick assist on the global toolbar. In case the user chooses to hide the search box, one could get back the "old" appearance / behavior of Ctrl+3 (eventually enriched by the additional search engines plugged into, as planned by bug 304440 and bug 320529, but this is not the point here). 2) Additionally one should be able to specify the initial value of this option by modifying the plugin_customization.ini of the product. (In reply to comment #5) > 1) We need to add a new preference under Preferences->General->... about > show/hide the quick assist on the global toolbar. Yes, we'll provide the preference to hide the search bar. But I'm not planning on providing an alternate implementation as part of that, just make it go away. > > 2) Additionally one should be able to specify the initial value of this option > by modifying the plugin_customization.ini of the product. Yes. PW (In reply to comment #6) > (In reply to comment #5) > > 1) We need to add a new preference under Preferences->General->... about > > show/hide the quick assist on the global toolbar. > > Yes, we'll provide the preference to hide the search bar. But I'm not planning > on providing an alternate implementation as part of that, just make it go away. This would mean, in 4.2 you have to choose between polluted toolbar or no "quick access" at all??? I mean, what should then happen if user disables this edit box and then hits "Ctrl+3"? As a user I would expect that "quick access" would just appear centered on the screen as in 3.7. I personally use "Ctrl+3" hundred times a day... This would be a major regression... (In reply to comment #7) This would mean, in 4.2 you have to choose between polluted toolbar or no > "quick access" at all??? > That's not the way I would put it, but yes, those are your choices. You will have a preference to make it disappear, or you will be able to drag it to the bottom toolbar. PW *** Bug 319991 has been marked as a duplicate of this bug. *** I've searched, but I cannot seem to find a preference option to remove the quick action search field. Is there another way to get rid of this feature? Thanks. The preference is not implemented yet. The other way only applies if you write a plugin, where the MToolControl can be removed before it is rendered. The SearchField is added in org.eclipse.ui.internal.WorkbenchWindow.populateTopTrimContributions() PW Thanks for your quick action. It's unfortunate that this aspect is not yet configurable, but it's certainly not the most pressing problem. Maybe with the next iteration. I tried to run one of my Eclipse 3.7 based applications with Eclipse 4.2 without doing any adjustments. The application starts without any problems. But what is really annoying is the fact that now there is the Quick Access box visible. This breaks some renderings, doesn't make sense for my application and wasn't there before. So how to get rid of it? Or do I have to use 3.7 until the whole application is rewritten to match e4? It's certainly not the case that an RCP app wants the Quick Access bar. My RCP doesn't want it. Whilst this remains non-removable my app remains based on Eclipse 3.x. +1. There must be a way to suppress the Quick Access bar stuff asap. plugin_customization seems the right place to do this. I double this request, I want to be able to fully configure my toolbar. TIA for fixing this issue, Wolfgang The Quick Access box is really annoying. It eats up way to much screen space. It is a complete waste of space for an experience user. I run Eclipse on a netbook. The box forces a second tool bar line which takes a large portion of my available screen space. I need to be able to get rid of this box. All those on the CC-list of this bug should not forget to *vote* for the bug, so it will get attention by the PMC within a reasonable timespan. Regards, Wolfgang (In reply to comment #8) > (In reply to comment #7) > This would mean, in 4.2 you have to choose between polluted toolbar or no > > "quick access" at all??? > > > > That's not the way I would put it, but yes, those are your choices. You will > have a preference to make it disappear, or you will be able to drag it to the > bottom toolbar. > > PW As the bug reporter I would like to emphasize that this answer would make no sense for anyone commented on this bug: people wanted to have this *text box* disappear, NOT the "Ctrl+3" "quick access" functionality. Nobody doubts that "quick access" is useful and I guess nobody wants this functionality "disabled via preference". Unfortunately according to the Paul latest comments all what we will get after fixing this bug is the option to disable "quick access" completely - both text box AND "Ctrl+3". So let see / vote for proposals have: 1) Have an always visible, fixed on toolbar "quick access text field" AND "Ctrl+3" search list fixed to the text field (today) 2) Have an *optionally* visible, *not* fixed on toolbar "quick access text field" AND "Ctrl+3" search list *not* fixed to the text field (intent of this bug report) 3) Have an *optionally* visible, fixed on *top or bottom* toolbar "quick access text field" AND "Ctrl+3" search list bound to the text field (no "Ctrl+3" search list if text field is not visible) (current proposal from comment 6) Proposal 3 would mean: if always visible "quick access text field" is not a choice for you application, you can decide to disable it BUT you have to live without ANY "quick access" at all. Honestly, if this is should be the outcome of this bug I can save the time for all of us and close the bug as "won't fix". The proposed fix will turn this bug report ad absurdum. It is like saying "you have cold - use guillotine". Please consider to restore the "3.x style" of "quick access" via preference, and everyone will be happy. There used to be a time (oh happy 3.x days) when one could write an RCP app where you could reasonably jettison all of the Eclipse junk (mentions of "workbench", "ide", etc)...but now that the e4 project came along we are doomed to have our RCP apps filled with such unwanted detritus as the "Quick Launch" bar and other rubbish. As Andrey points out there are two discreet parts to this: 1) Should Ctrl-3 do anything 2) Should there be a special (optional) affordance for it in the trim We're looking at this but from a slightly different (e4-ish) angle. The crux of the problem is that we're currently adding too much to the window through hard coded mechanisms. It may well be that we should be coding up 'Search' as an 'Addon' (like DnD and Min/Max) so that we have finer grained control over it. In any case we want a general solution, not just one that works for this particular piece of the puzzle... Eric, I pray something be considered here for 4.2 SR1, and not just try and look for the magic "general solution". The problem here that has many infuriated is the hard-coded quick access in the toolbar. Ctrl-3's presence has simple solutions in RCP land for those that apply the plug-in that carries it. We all (should) know how to suppress bindings, add our own to override, etc. It's the VISUAL contribution here that is unacceptable, w/out a way out. I argue this must get addressed asap to allow RCP developers to pick up 4.2 and, as they have always been able to, control what their interface displays. (In reply to comment #22) > Eric, I pray something be considered here for 4.2 SR1, and not just try and > look for the magic "general solution". The problem here that has many > infuriated is the hard-coded quick access in the toolbar. Ctrl-3's presence has > simple solutions in RCP land for those that apply the plug-in that carries it. Fixing quick access and considering any of the solutions as in comment #19 will have to be done in 4.3. But I could add a quick fix for 4.2.1 and disable the additions if org.eclipse.ui.application.IWorkbenchWindowConfigurer.getShowCoolBar() returns false in an RCP app. PW PW, just speaking for our companies intended use of 4.2 (to update a 3.7/3.8 based RCP app, that is aside from our Eclipse IDE integrated product where we welcome the new quick access feature), we indeed do not use the coolbar (setShowCoolBar(false)) and so what you said would do it for us. To be precise, in our current rcp app we leave ctrl-3 alone to use for power users, so it is just the visual quick-access UI that we don't want. I'd be sad if you meant to remove not only the visual contribution but also ctrl-3's handler itself... I'm attaching a screenshot of our bar right now in 4.2 compared to our bar in 3.7... AFAIK using CTRL+3 even with showCoolBar false will make it re-appear. I can't fix that until 4.3. PW Created attachment 219053 [details]
screenshot comparing 3.7 and 4.2
(In reply to comment #26) > Created attachment 219053 [details] > screenshot comparing 3.7 and 4.2 This looks like an unrelated bug. I think maybe you are getting the default theme which is used if no theme is defined. You can open a separate bug for this but there might be something you need to do in your application to configure a theme (for example "Classic" if you want the 3.7 look and feel). (In reply to comment #27) > (In reply to comment #26) > > Created attachment 219053 [details] > > screenshot comparing 3.7 and 4.2 > > This looks like an unrelated bug. I think maybe you are getting the default > theme which is used if no theme is defined. You can open a separate bug for > this but there might be something you need to do in your application to > configure a theme (for example "Classic" if you want the 3.7 look and feel). sorry the key in the screenshot directly is about how quick access was "in the way" (nevermind some corner-changes). I'll take a look at whether the theme alteration does more than just L&F. May I hijack this bug for one last time, where you can give me a link on how to alter the theme in an rcp app (programmatic or via a property/plugin_customization?) On topic: did you mention that ctrl-3 would make the quick access bar re-appear? (so ctrl-3 w/ a popup dialog is gone?) (In reply to comment #28) > > I'll take a look at whether the theme alteration does more than just L&F. May I > hijack this bug for one last time, where you can give me a link on how to alter > the theme in an rcp app (programmatic or via a property/plugin_customization?) In an RCP app defaults can be configured in the plugin.xml that defines the product, like: <property name="cssTheme" value="org.eclipse.e4.ui.css.theme.e4_default"> </property> <property name="applicationCSSResources" value="platform:/plugin/org.eclipse.platform/images/"> </property> See http://git.eclipse.org/c/platform/eclipse.platform.git/tree/platform/org.eclipse.platform/plugin.xml for an example of providing themes and configuring a product with a default. To allow plugin_customizations.ini I think that's still open, bug 385676 > > > On topic: did you mention that ctrl-3 would make the quick access bar > re-appear? (so ctrl-3 w/ a popup dialog is gone?) Until we address this bug fully in 4.3, yes the dialog is gone and ctrl+3 will make the search field re-appear (AFAIK). PW I vastly preferred the old Eclipse 3.x style quick access which was a floating window. The new search bar is good for new users but should really be an optional extra and when disabled the old behaviour should still be available. Having to wait another 12 months for the next major Eclipse release is really frustrating. The new search bar also interacts badly with text editors. If I press "Ctrl+3" while a text editor is open I can't use Home and End to move the cursor in the search bar. Instead Home and End are handled by the open editor by moving the hidden editor cursor. This can be seen by performing a "Shift+Home" or "Shift+End" which is ignored by the search bar and instead highlights text in the editor. (In reply to comment #30) > I vastly preferred the old Eclipse 3.x style quick access which was a > floating window. The new search bar is good for new users but should really > be an optional extra and when disabled the old behaviour should still be > available. Having to wait another 12 months for the next major Eclipse > release is really frustrating. > > The new search bar also interacts badly with text editors. If I press > "Ctrl+3" while a text editor is open I can't use Home and End to move the > cursor in the search bar. Instead Home and End are handled by the open > editor by moving the hidden editor cursor. This can be seen by performing a > "Shift+Home" or "Shift+End" which is ignored by the search bar and instead > highlights text in the editor. I have raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=386803 to cover the Home/End issue. The Workaround I've found is to do this:
MWindow mWindow = ((WorkbenchWindow) PlatformUI.getWorkbench().getActiveWorkbenchWindow()).getModel();
EModelService modelService = mWindow.getContext().get(EModelService.class);
MToolControl searchField = (MToolControl) modelService.find("SearchField", mWindow); //$NON-NLS-1$
MTrimBar trimBar = modelService.getTrim((MTrimmedWindow) mWindow, SideValue.TOP);
trimBar.getChildren().remove(searchField);
Control control = (Control)searchField.getWidget();
Composite parent = control.getParent();
control.dispose();
I use the v3.x compatibility layer, then I put that piece of code in the WorkbenchWindowAdvisor.openIntro ovveridden method.
I hope that will give help people that were stuck like me for the e4 migration.
I have a simple question that determines whether I port my RCP 3.8 app to 4.2: Is it possible to create an RCP application using Eclipse 4.2 that does not have a "Quick Access" bar? If not, will it be possible using Eclipse 4.3? (In reply to comment #33) > > Is it possible to create an RCP application using Eclipse 4.2 that does not > have a "Quick Access" bar? If not, will it be possible using Eclipse 4.3? It's possible to remove it in extra steps, but not create one without it ATM. But yes, in 4.3 your RCP app will have to opt-in to get the search bar. PW (In reply to comment #34) > (In reply to comment #33) > > > > Is it possible to create an RCP application using Eclipse 4.2 that does not > > have a "Quick Access" bar? If not, will it be possible using Eclipse 4.3? > > It's possible to remove it in extra steps, but not create one without it ATM. > > But yes, in 4.3 your RCP app will have to opt-in to get the search bar. > > PW Thanks for the clear reply. I shall therefore target Eclipse 4.3. Is this opt-in available in 4.3 M2? (In reply to comment #35) > > Thanks for the clear reply. I shall therefore target Eclipse 4.3. Is this > opt-in available in 4.3 M2? No, work on the 4.3 only options probably won't start until early next year. PW I realized earlier today that it's trivial to hide the Quick Access using CSS:
#SearchField { visibility: hidden; }
And it doesn't re-appear on Ctrl-3.
I can leave without QuickAccess feature. I even don't know what is it. Maybe if someone points me to the usefulness of the feature I can change my mind, but until this happens I vote for option 3. 3. Can disable quick access and lose QuickAccess features. It's the only thing that makes my toolbar extend two times normal height. I've no idea what quick access is for and I only bother with one perspective and I ended up here after searching for how to remove the quick access and/or perspective tool-bar buttons so that there would be only one tool-bar line. I was expecting to see something in the Window.Customize Perspective window that would allow me to remove these widgets. I suppose you can't put "switch perspective" in as a toggle option in the "customize perspective" window. I vote for whatever option allows me to remove "quick access" and perspective buttons and it doesn't matter to me if the "quick access" feature is disabled, because I haven't bothered to use it. Please correct me if I'm wrong, but it seems that Eclipse RCP developers have been forgotten. It might be OK to add things like the Quick Access bar to the Eclipse IDE, but clearly undesirable for an RCP application that really does not want to expose shortcut keys, and that is trying to hide the "IDE" aspect of the RCP application. (In reply to comment #40) > Please correct me if I'm wrong, but it seems that Eclipse RCP developers > have been forgotten. They have not been forgotten ... they can remove it by providing their own CSS, and including #SearchField { visibility: hidden; }, and the quick access field will respect org.eclipse.ui.application.IWorkbenchWindowConfigurer.getShowCoolBar() == false. There are other things we can do for RCP apps as well, for 4.3 time permitting. PW (In reply to comment #41) > (In reply to comment #40) > > Please correct me if I'm wrong, but it seems that Eclipse RCP developers > > have been forgotten. > > They have not been forgotten ... they can remove it by providing their own > CSS, and including #SearchField { visibility: hidden; }, and the quick > access field will respect > org.eclipse.ui.application.IWorkbenchWindowConfigurer.getShowCoolBar() == > false. > > There are other things we can do for RCP apps as well, for 4.3 time > permitting. > > PW Then I stand (happily) corrected. Thank-you. (In reply to comment #37) > I realized earlier today that it's trivial to hide the Quick Access using > CSS: > > #SearchField { visibility: hidden; } > > And it doesn't re-appear on Ctrl-3. This doesn't work. The field becomes invisible. But is still takes the same place in the toolbar. It is just colored as the toolbar background. You don't get more free space in the toolbar as you might have expected. This problem exists on Windows 7. If Eclipse CSS works the same as Web CSS you should try:
display: none;
This should hide the SearchField and stop it taking up any space.
Thanks. This doesn't work. Neither positioning nor clipping/overlay etc. which normally works for DIVs in browsers. Moreover, a string of pixels remains. Its width is 1px, so I haven't noticed it at first. It's seems to be a bug in CSS implementation. But it is not yet officially released, so may be it is just not yet fully implemented. Even if CSS worked, it just would be a trick to work the problem around. The GOOD solution should be a possibility to disable this component via perspective settings, same way as it works for all other buttons in the toolbar. It's bad that such irritating problem exists longer than one year. Is it just a bug? Or is it a design flaw in the implementation of "Quick access"? As a workaround, I hide some Tool Bars in Customize Perspective so the tool bar area won't get wrapped. Please rollback this "Quick Access" toolbar feature. If the question is of "quicker" access, then please consider which of these options is actually quicker: 1. Dragging your mouse over to this new toolbar "Quick Access", and then clicking on it. 2. or Simply pressing ctrl-3 Sandeep, once this bug is solved you can hide it. Also Ctrl+3 still works with the quick access box. Lars, I understand that ctrl-3 is also there. I am debating that this feature should not have been there in the first place. Further on, I can turn off other controls in toolbar using Customize perspective but not this one. As others have said better in 4.2.2 rather than 4.3. (In reply to comment #50) > Lars, I understand that ctrl-3 is also there. I am debating that this > feature should not have been there in the first place. > If I read your comment right you were debating which version is quicker. And that question does not make sense since they are both available. (In reply to comment #50) > Lars, I understand that ctrl-3 is also there. I am debating that this > feature should not have been there in the first place. > > Further on, I can turn off other controls in toolbar using Customize > perspective but not this one. > > As others have said better in 4.2.2 rather than 4.3. As for what should have been and what should not have been there has already been a discussion on that as pointed by Paul in the first comments. I don't think any one alone has the right to claim what is the right and wrong for everyone. It has to be a decision made after a discussion. The bug in comment 3 was public and various committers made a decision. That bug was open for anyone to have a say. You can not make a world-wide poll for every change you make. For every change there are people who like it and people who don't. What I agree is that people should have the possibility not to have the box while retaining the functionality. I don't agree that it should be hidden by default. It has a lot of value as a shortcut and the more visible it is the better. (In reply to comment #52) > What I agree is that people should have the possibility not to have the box > while retaining the functionality. I don't agree that it should be hidden by > default. It has a lot of value as a shortcut and the more visible it is the > better. Regarding the Eclipse IDE you are completely right. The main issue this bug is connected to is that on creating an Eclipse application that uses the compatibility layer (not IDE) you get the Quick access box showed by default. And for my Eclipse based application I don't want to add that support. It even crashes my layout. At least this was true when I came across this one (comment 13) (In reply to comment #53) > (In reply to comment #52) > > What I agree is that people should have the possibility not to have the box > > while retaining the functionality. I don't agree that it should be hidden by > > default. It has a lot of value as a shortcut and the more visible it is the > > better. > > Regarding the Eclipse IDE you are completely right. The main issue this bug > is connected to is that on creating an Eclipse application that uses the > compatibility layer (not IDE) you get the Quick access box showed by > default. And for my Eclipse based application I don't want to add that > support. It even crashes my layout. > > At least this was true when I came across this one (comment 13) Sure I agree that you need to have a really trivial way to set the default behavior (on for IDE, off for RCP). But I think this is where this bug's direction is pointed to. (In reply to comment #53) > Regarding the Eclipse IDE you are completely right. The main issue this bug > is connected to is that on creating an Eclipse application that uses the > compatibility layer (not IDE) you get the Quick access box showed by > default. And for my Eclipse based application I don't want to add that > support. It even crashes my layout. > > At least this was true when I came across this one (comment 13) +1. My RCP application is tied to Eclipse 3.8 because of this and other issues in the compatibility layer. There's no way it can be ported to Eclipse 4.x. Where does that leave me going forward? (In reply to comment #20) > There used to be a time (oh happy 3.x days) when one could write an RCP app > where you could reasonably jettison all of the Eclipse junk (mentions of > "workbench", "ide", etc)...but now that the e4 project came along we are > doomed to have our RCP apps filled with such unwanted detritus as the "Quick > Launch" bar and other rubbish. I agree completely... Tried every release since 4 came out, and NONE made me happy. I was expecting more flexibility, not less! I'm tired of "hacking" into eclipse 3.x to get the desired effect, and with 4.x there are a number of new problems. You have to remember that many of us won't use / like many of the RCP features. RCP should be totally configurable. I agree - I don't like the Quick Access Edit box. It takes a lot of room. And sometimes, especially when you are debugging the perspective buttons get pushed down a line - that's very annoying 61 votes for this bug and allegedly targeted to be fixed for version 4.3. And 4.3 will be released soon and it's not fixed... (In reply to comment #58) > 61 votes for this bug and allegedly targeted to be fixed for version 4.3. > And 4.3 will be released soon and it's not fixed... It's not targeted for 4.3 (no target milestone). It was a candidate to be pulled forward if we worked through what was on our plate (and we didn't get to it). PW I'll put this back on the plate for Luna. I agree with the general sentiment(s) I see here; RCP apps shouldn't have to jump through hoops to not have it appear in the trim and some folks don't want it at all... Note that one of the initial design criteria for e4 was that things like this should be easy. 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. More complex is arranging to have the functionality available when the SearchField isn't available. This shouldn't be a killer though since the new behavior was a port of the old 3.7 code. It's more a matter of having the ability for the logic to have the Text control it's supposed to be listening to derived from whether or not the trim field is there; if so use it, if not then 'grow' an edit control in the same composite that's showing the results and use that one. (In reply to comment #60) > > Note that one of the initial design criteria for e4 was that things like > this should be easy. 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. > If that part is simple, then can it be done in the first Kepler service pack? Why wait for Luna? (In reply to comment #61) > > If that part is simple, then can it be done in the first Kepler service > pack? Why wait for Luna? This isn't necessarily simple (we have no implementation for it). I've opened Bug 411821 for a fix to wire off the SearchField. If someone can provide a fix for it we can backport it to Kepler. PW You can hide the "Quick access" field using CSS. To do it find the proper CSS file for your Eclipse instance in the following plugins directory: <ECLIPSE_HOME>/plugins/org.eclipse.platform_<VERSION>/css and put there the following entry:
#SearchField {
visibility:hidden;
}
After the change you have to restart Eclipse,
Daniel
Hi Daniel, I gave that workaround a try. Unfortunately this removes the search-box only from my host-eclipse but not from my child-RCP-app. This rcp-app doesn't even include that org.eclipse.platform-plugin. Any other ideas? Or is there a way to get that workaround proposed in Bug 411821 for at least 4.2.1? Or ist there some really ugly hack to checkout the source of one of the plugins, comment out some lines and use that modified plugin for our RCP app? Since I'd really like to upgrade to the e4-train it would be really great to have some workaround here, especially since there is no 3.9 kepler, isn't there? Regards, Johannes (In reply to comment #64) I tried the CSS trick, and it does hide the search field. You need to have a CSS file in your RCP project and add the lines there, not in the CSS file that the IDE uses. Unfortunately, this is not a good solution for the RCP application because it just hides the field, but still reserves a bunch of space on the toolbar. I'm seeing my toolbar contributions appear to be right justified on the bar because the hidden search field is still inserted before mine, and pushes mine all the way over to the right. I have to confess I don't know how to fix that. I decided to bite the bullet and start learning the new e4 way of doing things, and when I started following a tutorial I found that my first test application did not show this search field on the toolbar. Is this bug only associated with the compatibility layer? If so, then I guess the only real solution available is to go ahead and rewrite my existing apps as bona fide e4 RCP apps. (In reply to comment #64) > Or is there a way to get that workaround proposed in Bug 411821 for at least > 4.2.1? That bug doesn't yet contain a fix, and when it does it can be targetted for 4.3.x (not 4.2.x, which isn't built anymore). > Since I'd really like to upgrade to the e4-train it would be really great to > have some workaround here, especially since there is no 3.9 kepler, isn't > there? There's no 3.9. The best workaround for Juno would be one similar to what's suggested in comment #32. Here's some updated code: IWorkbenchWindow window = ...; if (window instanceof WorkbenchWindow) { MWindow model = ((WorkbenchWindow) window).getModel(); EModelService modelService = model.getContext().get( EModelService.class); MToolControl searchField = (MToolControl) modelService.find( "SearchField", model); if (searchField != null) { searchField.setToBeRendered(false); MTrimBar trimBar = modelService.getTrim((MTrimmedWindow) model, SideValue.TOP); trimBar.getChildren().remove(searchField); } } You need to depend on these 3 additional bundles: org.eclipse.e4.ui.model.workbench org.eclipse.e4.ui.workbench org.eclipse.e4.core.contexts PW (In reply to comment #65) > I decided to bite the bullet and start learning the new e4 way of doing > things, and when I started following a tutorial I found that my first test > application did not show this search field on the toolbar. Is this bug only > associated with the compatibility layer? If so, then I guess the only real > solution available is to go ahead and rewrite my existing apps as bona fide > e4 RCP apps. Yes, this is a compatibility layer problem: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.ui.workbench/Eclipse%20UI/org/eclipse/ui/internal/WorkbenchWindow.java?h=R4_2_maintenance#n714 The workaround for Juno (now in comment #66) is code in your RCP app, The original suggestion in comment #32 is in WorkbenchWindowAdvisor.openIntro(*). It might also be effective in org.eclipse.ui.application.WorkbenchWindowAdvisor.preWindowOpen() or org.eclipse.ui.application.WorkbenchWindowAdvisor.postWindowOpen() PW (In reply to comment #67) > The workaround for Juno (now in comment #66) is code in your RCP app, The > original suggestion in comment #32 is in > WorkbenchWindowAdvisor.openIntro(*). It might also be effective in > org.eclipse.ui.application.WorkbenchWindowAdvisor.preWindowOpen() or > org.eclipse.ui.application.WorkbenchWindowAdvisor.postWindowOpen() > > PW I tried putting this code in preWindowOpen() and it didn't have any effect. However, when I put it in postWindowOpen() or in openInto() then it did remove the search field. The behavior was the same as when I tried the CSS solution, however, in that something invisible was pushing all of my own toolbar contributions all the way over to the right edge of the toolbar. When I looked at the trimBar's list of children in the debugger I could see that there were 4 other items listed in addition to the search field. Their elementId strings are: PerspectiveSpacer Spacer Glue Search-PS Glue PerspectiveSwitcher These items map to things I can see when I run the IDE, but I don't want any of them in my RCP application, so I changed one line of your code snippet in comment 66 from trimBar.getChildren().remove(searchField); to trimBar.getChildren().clear(); This apparently did the trick. Now the only items on the toolbar are ones that I put there with my own plugins. Thanks for your help on this, Paul. I do appreciate it. (In reply to comment #68) > These items map to things I can see when I run the IDE, but I don't want any > of them in my RCP application, so I changed one line of your code snippet in > comment 66 from > > trimBar.getChildren().remove(searchField); > > to > > trimBar.getChildren().clear(); > > This apparently did the trick. Now the only items on the toolbar are ones > that I put there with my own plugins. When I experimented with clearing the cache by checking the clear checkbox in my run configuration I started to have problems with my solution above. It seems that removing all of them wasn't a good idea. I found that I needed to leave the "Search-PS Glue" item in the list to avoid crashing after clearing the cache. I'm removing all the others but leaving that one alone, and now it's working (so far). BTW, the weird right-justification I was seeing seems to be caused by the "PerspectiveSpacer" item. Created attachment 233545 [details]
Screenshot showing how much space "Quick Access" wastes. I sure is quick to find though!
(In reply to comment #70) > Created attachment 233545 [details] > Screenshot showing how much space "Quick Access" wastes. I sure is quick to > find though! That's a bit disingenuous because you have moved it to the very end and then added enough tool bars to make just that item overflow to a new line. You could easily remove some toolbar items or change perspective switcher to show only icons to avoid that overflow. As a heavy keyboard user I could argue all those toolbar buttons are wasting space because Quick Access is the only thing on that line I ever use (all toolbar commands and perspective switching can be invoked via quick access). I still agree with the main focus of this bug though - it should be possible to hide it, and RCP apps in particular should be able to turn it off (or even make it off by default for RCP apps). (In reply to comment #69) > (In reply to comment #68) > > These items map to things I can see when I run the IDE, but I don't want any > > of them in my RCP application, so I changed one line of your code snippet in > > comment 66 from > > > > trimBar.getChildren().remove(searchField); > > > > to > > > > trimBar.getChildren().clear(); > > > > This apparently did the trick. Now the only items on the toolbar are ones > > that I put there with my own plugins. > > When I experimented with clearing the cache by checking the clear checkbox > in my run configuration I started to have problems with my solution above. > It seems that removing all of them wasn't a good idea. I found that I > needed to leave the "Search-PS Glue" item in the list to avoid crashing > after clearing the cache. I'm removing all the others but leaving that one > alone, and now it's working (so far). > > BTW, the weird right-justification I was seeing seems to be caused by the > "PerspectiveSpacer" item. I had this problem as well. Why do we have to remove this at all? I managed to get everything working for me using the following code: @Override public void openIntro() { IWorkbenchWindow window = PlatformUI.getWorkbench() .getActiveWorkbenchWindow(); MWindow model = ((WorkbenchWindow) window).getModel(); EModelService modelService = model.getContext() .get(EModelService.class); MTrimBar trimBar = modelService.getTrim((MTrimmedWindow) model, SideValue.TOP); Iterator<MTrimElement> it = trimBar.getChildren().iterator(); while (it.hasNext()) { MTrimElement next = it.next(); if (next instanceof MToolControl) next.setToBeRendered(false); } super.openIntro(); } So I'm not removing it (and so avoid the ugly NPE also mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=388516 while removing all the e4 stuff without removing my "own" toolbar-entries. JM Could we make this a P1 bug for Luna ? Having cmd+3 not be possible to hide and forcefully enable the toolbar as described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=383914 is really unfortunate. Yes, displays are getting bigger and bigger but why force having to spend 10-15% of my screen real estate on toolbars when they are not being used. Really need quicksearch to not require having its quicksearch field shown to use it. (In reply to comment #73) > Could we make this a P1 bug for Luna ? > > Yes, displays are getting bigger and bigger but why force having to spend > 10-15% of my screen real estate on toolbars when they are not being used. To give some concrete numbers: On my fairly low resolution 1280x1024 display, Quick Access is 100x21 pixels, which is actually 0.16% of my screen real estate. The entire toolbar is 1196x36 or roughly 3%. Take your eclipse - have it be half the screen so you can have you browser opened at the same time. The toolbar will now be at least 2 rows, if not 3 rows high taking up significant portion of the screen. See this http://screencast.com/t/SSIgJ5Zb9Q compared to http://screencast.com/t/aeJBpURWAg The first is alot of mouse-required UI (toolbar) to insist on showing for a quickaccess feature which otherwise require no mouse. Don't you think ? Note: i'm personally fine with the quickaccess feature being in the toolbar - it is the requirement that to use quickaccess eclipse forces the toolbar to be shown. Created attachment 235062 [details]
Example of screen real estate taken up by quick access toolbar
@John Arthorne - I think your number are misleading. The reason why Quick Access takes up so much space in my experience is that it can cause the toolbar to wrap due to too many icons being present. See my attachment (eclipe_quickaccess_tall_toolbar.png) for an example of the effect on a 1024x768 resolution screen. This means the space which I would attribute to Quick Access is equal to an entire empty toolbar rather than just the Quick Access area itself.
One solution for this issue would be to reduce the number of icons shown by default. Another would be to make it easier to access toolbar customization. It is bad that right clicking on empty toolbar space doesn't give an option to customize the toolbar contents. As far as I can tell a user has to use Window -> Customize Perspective -> Tool Bar Visibility to control the visibility of controls within the tool bar.
Lots of plugins add buttons to the toolbar so the mandatory addition of the Quick Access bar causes toolbar wrapping even more often.
This plugin works: https://github.com/atlanto/eclipse-4.x-filler#hide-quick-access-plug-in at least for the IDE. I'll try it in my application tomorrow. Created attachment 237348 [details]
Side-by-side comparison of used space with a browser
Picking on Quick Access seems to be missing the point a bit. In fact it's possible to have both Quick Access and tabs be featured prominently in the UI and still use 61 pixels *less* vertical space compared to current situation. What's more, you don't even have to violate platform UI guidelines to do this either! Please see this attachment for a demonstration of how this is possible.
Quick Access isn't the real problem at all.
Quick Access field and changes it causes to toolbars is really annoying here and it would be definitely very nice to have an option to remove it completely from workspace For me this is one of two antifeatures that prevent me from switching to newer Eclipse for over two years now. I've never used Quick access, and I don't want to. I still disagree with it being disabled by default (who would find about it then) but having it forced upon users is against what I thought to be one of Eclipse's principles: configurability. (In reply to Wacław Schiller from comment #80) > For me this is one of two antifeatures that prevent me from switching to > newer Eclipse for over two years now. I've never used Quick access, and I > don't want to. I still disagree with it being disabled by default (who would > find about it then) but having it forced upon users is against what I > thought to be one of Eclipse's principles: configurability. RCP developers have been forgotten. Why does an RCP application want a Quick Access bar? It doesn't. That's why I'm still using 3.8 for my (1000 downloads a month) RCP app. Maybe next year? (In reply to Phillipus B from comment #81) > RCP developers have been forgotten. Why does an RCP application want a Quick > Access bar? It doesn't. That's why I'm still using 3.8 for my (1000 > downloads a month) RCP app. Maybe next year? For RCP and the quick access bar see Bug 411821. (In reply to Lars Vogel from comment #82) > (In reply to Phillipus B from comment #81) > > RCP developers have been forgotten. Why does an RCP application want a Quick > > Access bar? It doesn't. That's why I'm still using 3.8 for my (1000 > > downloads a month) RCP app. Maybe next year? > > For RCP and the quick access bar see Bug 411821. I'm sorry, but I can't see how an RCP app that uses the compatibility layer to run in e4 can use this. (In reply to Phillipus B from comment #83) > I'm sorry, but I can't see how an RCP app that uses the compatibility layer > to run in e4 can use this. It makes the Quick Access bar opt-in. In the IDE, it'll be provided by the o.e.ui.ide.application plugin. If you don't include that, then you won't have it. PW (In reply to Paul Webster from comment #84) > (In reply to Phillipus B from comment #83) > > I'm sorry, but I can't see how an RCP app that uses the compatibility layer > > to run in e4 can use this. > > It makes the Quick Access bar opt-in. In the IDE, it'll be provided by the > o.e.ui.ide.application plugin. If you don't include that, then you won't > have it. > > PW And indeed that is the case! Tested on N20140112-2000. Thank-you. I can shut up now. :-) This is especially wrong for RCP applications. The quick launch contains many advanced options that are not needed for users of an RCP application and can only cause confusion. Many of the options shown aren't reachable through the UI of an RCP application. This means that users can even use it to hide the main toolbar with no possibility to get it back! This is even true for the example RCP application you can create when creating a new Eclipse plugin. Fortunately I see it is indeed fixed for Eclipse RCP in 4.4 M5. Even Ctrl+3 may not be recommended for RCP apps. Normal users can accidentally mess up things like customizing the perspective and removing the file menu. Normal users will have no clue on how to get it back! Additionally, the technical Eclipse terms shown make no sense in the domain of the specific RCP application and can be confusing to normal users. I DO love quick access in the Eclipse IDE :) I made the quick access box hidden by changing the e4 css file, setting the field to "hidden". This hides the quick access box, but I still have an extra, now empty, row in the toolbar. Oh, never mind, I didn't read all comments. sorry about that. Additional annoyance that quick access (which I never use) causes is that it appears to accept random text typed while Eclipse has focus in some cases; e.g. sometimes when tabbing on Mac OS X and typing, few characters end up in Quick Access and giant useless always-on-top popup starts loading, blocking even other windows, with no good way to get rid of it. Especially annoying when machine is slow e.g. during build. The easiest way I found it the following stuff (based on Johannes Michler solution):
@Override
public void openIntro() {
IWorkbenchWindow window = PlatformUI.getWorkbench()
.getActiveWorkbenchWindow();
MWindow model = ((WorkbenchWindow) window).getModel();
EModelService modelService = model.getContext()
.get(EModelService.class);
modelService.find("SearchField", model).setToBeRendered(false);
super.openIntro();
}
I'd like to see this implemented too. I have an RCP application based on Eclipse IDE application workbench. I'd like too have an option to remove Quick Access from the toolbar via plugin_customization.ini. Created attachment 241485 [details] Plug-in to remove SearchField from Eclipse IDE As already mentioned with the fix of Bug 411821 the QuickAccess bar is only visible if the o.e.ui.ide.application plug-in is included. If you relay on the Eclipse IDE application and explicitly don't want to have the QuickAccess bar you can remove it with a simple application model processor which runs after the fragments (see my attached plug-in). Whenever Bug 431707 is fixed the old QuickAccess dialog will be opened if you hit CTRL+3 if and the attached plug-in is active. If you also don't want to have this behavior you can extend the attached plug-in and remove the Key-Binding for the QuickAccessHandler. @Sergey Shelukhin: Are you using a Mac-Book and have the "tap-to-click" active which executes a click whenever you simply touch the Touchpad instead of pressing it hard at the bottom? - If so it happens that you click by accident during typing, because you rest your hands on the touchpad (That's what happened to me all the time and after turning-off this behavior everything works fine.) https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=557835799a4f2038a9a5a91d8cde7822384842ea from Rene uses a dialog if the toolbar or the search field is hidden. We are still investigating what the best way is to allow the user to hide the search field. Currently I think a popup menu on the field with the option to hide it, would be the best. (In reply to Lars Vogel from comment #94) > toolbar or the search field is hidden. We are still investigating what the > best way is to allow the user to hide the search field. Currently I think a > popup menu on the field with the option to hide it, would be the best. That should be in its own bug. I'd also make it a command so it's accessible from quick access. If you want to then offer it as a context menu, have the right-click offer that command (might be harder to do than you think) or have it open quick access with the command pre-searched. PW (In reply to Paul Webster from comment #95) > (In reply to Lars Vogel from comment #94) > > toolbar or the search field is hidden. We are still investigating what the > > best way is to allow the user to hide the search field. Currently I think a > > popup menu on the field with the option to hide it, would be the best. > > That should be in its own bug. Oooops, this is the correct bug. PW It's now optional for RCP apps. Lars and Sopot will allow it to be hidden, and if hidden it will fall back to using a popup. PW (In reply to Paul Webster from comment #1) > I'd consider allowing it to be closed. But it will remain in the toolbar by > default. As Paul said, we want to allow it to be closed by the user but will keep it enabled by default. I adjust the title of the bug report accordingly. The final commit which fixes this is https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=032f14076a4bc91d903adcd8008f8056eb1155a8 It adds a context menu to the Quick Access control which allows the user to hide it. The user can use the context menu on other items to reset the trimbar entries, also reset Perspective will reset the visibility to the default. Thanks to Rene and Sopot for their help with this feature. But there will be no way to modify the default behaviour via plugin_customization.ini? (In reply to Sebastian Westemeyer from comment #100) > But there will be no way to modify the default behaviour via > plugin_customization.ini? This is not planned. I think it is safer to close this a dup of Bug 431868. *** This bug has been marked as a duplicate of bug 431868 *** This was such a highly sought after change that it is worth marking it directly as FIXED. Thanks Sopot and Lars for completing this! Quindi? Non trovo le parole per dirvi quanto siete pellai (In reply to Claudio Bottai from comment #104) > Quindi? Non trovo le parole per dirvi quanto siete pellai I guess it means a big thanks for your hard work :) Daniel The "Hide" option only appears when you right click in the area of several pixels AROUND the quick access field. Right clicking on the field itself does not provide the Hide action. This is not very user friendly. Is this the expected behavior? (In reply to Sebastien Arod from comment #106) > > This is not very user friendly. Is this the expected behavior? Yes, this is expected behaviour (it's just part of the hide toolbar functionality for all toolbars on the top trim). You could open a new bug to provide a Hide Quick Access command, that could be used from CTRL+3 itself. Contributions are welcome. PW |