Community
Participate
Working Groups
There are several more actions on the outline toolbar than what used to be there. Besides looking cluttered, it causes the toolbar to wrap and occupy an extra row more frequently. Maybe uesr could customize, or perhaps just move some actions into the view's drop-down menu. "Link with editor" comes to mind. This is more of a preference that is set once.
Given the fact that most of these buttons are filters, solving bug 3809 will fix the problem described in this bug. *** This bug has been marked as a duplicate of 3809 ***
I don't agree that this is strictly an issue of filters. The action "Link with Editor" is not a filter. IMO, this toggle is more of a user preference (most users don't change it) and should be placed on the view's MenubarManager perhaps, not the toolbarmanager. Also, I think that some of these actions *are* frequently used (like "Hide fields"), and they should stay on the toolbar even if a dialog is implemented in the future.
Randy, given the fact that 4 out of seven are filters, would very much solve the problem described in the bug report. "Link With Editor" is consistently in the tool bar (*). Please file a bug report against Platform UI to change this and Jdt will adopt. (*) Note: There's one exception in Jdt land which are the browsing views which are intended to be used with linking always on and that's why we put it into the view's menu. *** This bug has been marked as a duplicate of 3809 ***
So the solution is to take the 4 toggle buttons which people most often use, and hide them in a popup dialog, while leaving the 3 less-commonly used actions on the toolbar? The solution sounds worse than the problem :-)
Note that the most recently used filters are in the view menu i.e. you don't have to go through the filter dialog. But of course, I agree that access via buttons is faster.
Having slept over it and thought about it a bit longer here's how I would like the final solution: - enhance the filter group to not only show LRU in view menu but also be placed as buttons into the view (not sure whether LRU is good here as well - probably better if configurable by user) - move filters where they belong i.e. into the filter group/dialog (bug 3809) - move less frequently used buttons to view menu (e.g. Go Into Top Level Type, Link with Editor)
"Link with Editor" and "Go into top level type" are now in the (new) view menu which reduces the tool bar by one item. We will not be able to enhance the custom filter support for 3.0 in a way that the user can choose which filters go to the tool bar. Currently the Member Filters in the tool bar are in their own group.
Thanks for the update. Sounds much better. I'm not sure what you meant by filters being in a group. If that means they are in a drop down, then the user can no longer see the status of which filters are enabled, no? Hopefully the UI team will one day allow customization of the view toolbar to allow each user to determine what is frequently used. I attached a mockup to the new L&F bugzilla with an idea I basically borrowed from the Windows Taskbar Systray. Basically a toggle on the toolbar which gives the user "more" and "less", where less is customizable.
Well the 5 LRUs are in the menu with their state - exactly the same behavior as the Package Explorer filters. I'm not sure what the UI team is going to do after 3.0. I plan to change the JDT filtering support to allow icons and to allow the user to configure which items appear in the view (or Quick Outline) tool bar.
Doesn't moving the Link with Editor button into the menu make it inconsistent with the Navigator and Package Explorer views?
Well, yes but before it was inconsistent with all Java Browsing views ;-)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
