Community
Participate
Working Groups
Build 200401290841 The feature: Floating view toolbars The problem: Many people will prefer to permanently dock their view toolbars The reasons: - floating toolbars obscure things in neighbouring views, and often even in the focus view itself - because they obscure things, the user is sometimes forced to do 2 mouse clicks (one extra one to focus the view) where one would suffice - when the eclipse window is maximized, toolbars that float on the right hand side of the screen even obscure the focus view's vertical scrollbar, and sometimes part of the horizontal scrollbar as well - floating toolbars have odd painting behavior - sometimes they show up before the view does, and sometimes they - or a portion of them - remain behind when the view is closed - floating toolbars cause an extra icon to appear in each view toolbar Personal preference: - please forgive my personal preference here, but if I am being totally honest, I would have to say that I think we should do away with the feature entirely. I don't find that it buys any noticable space improvement, and the annoyance factor is high. I immediately dock them (again and again, because they are not persisted).
Noticed a similar (but not identical) bug report: 50869 I like the idea of a system preference. If the preference is set, then all views (not just newly-opened ones) should have docked toolbars. In addition, if the preference is set, remove the "Lock in View" tool from all view toolbars. The user is, in effect, saying "I don't want any floating toolbars". So once the feature is turned off, there should not be any vestiges of it in evidence.
I think I need to give an example of how a typical developer works in eclipse, in order to show why and where the 'floating toolbars' feature breaks down. An excellent task to discuss is debugging. Every developer will eventually need to debug, and for this they use the debug perspective. Take a look at the debug perspective. There are typically 5 visible views: Debug, Variables, Editors, Outline, and Console. Various other useful views are tyically on tabs, which is fine because they are used less often. The vm, thread, and frame for the program that you are currently debugging are shown in the Debug view. The 'debugger control' tools are in the Debug view's toolbar, and they must be "one-click" accessible at all times - no matter which view has focus. This is critical to the use of the product by a developer, and must not change. Therefore this toolbar cannot ever float, because when the developer is working in another view (or editor) they will need to be able to access the 'debugger control' tools immediately. The next view is the Variables view. The developer often goes to this view, to scroll, to expand/collapse the variable values tree, etc. When the debug view's toolbar floats, not only are the control tools unavailable, the toolbar obscures the variables tree's navigation icons (+/-). This is yet another reason why the debug view toolbar cannot float. Next are the editors. Developers doing debugging (in fact, doing anything) work in the editors all the time. While debugging, this can be to make a change to the code, to scroll to see what came before and what comes next, or to look at another file that is important in the current context. While in an editor, a developer may want to click on something in the Outline view, to see the definition of another method, say, or to scroll in the outline to see whether a method is defined in the current class, or maybe to see what the public API for the current class is. When clicking on the Outline view, the floating toolbar immediately obscures the scrollbar (my eclipse window is always maximized). This renders the Outline view almost completely useless. Next is the Console. When debugging using the Console, a common operation is to clear it. This is available as a tool in the Console view's toolbar. When the Console toolbar is floating, this tool is not available as a one-click operation. This is unsatisfactory, at best. In summary, developers using eclipse use all views in parallel to accomplish the current task. The fact that there is a 'focus view' is an artifact, an anomaly, a strange and somewhat interesting departure from the normal application paradigm, which is both an asset and a liability to eclipse. We need to be very careful not to accentuate the 'focus view' feature of eclipse in ways that detract from the ultimate goal that it is percieved as an extremely useful application, because if we lose that, we have lost everything.
Big +1 to the above. You got that dead on Carolyn.
Well said. IMHO, we should remove the floating toolbars entirely (no preference is even necessary). Chris made some excellent suggestions for reclaiming screen real-estate: 1. Remove unnecessary toolbars (such as the one on the problems view, which contains rarely-used functions that are also available elsewhere) 2. Many views include a view menu (on the problems view, it contains Sorting... and Filters...). This can be merged with the context menu. At this point, many toolbars can be removed entirely.
thanks for your efforts everyone, I will revisit this as soon as I can
i agree completely here. i have also entered the following (large and tedious) comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=37997#c81 (this details what i had mentioned to stefan..)
Gee. That's sounds a lot like what I said 2 months ago. http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg01463.html
I gave you credit over in bug 46236 ;)
Created attachment 7914 [details] Partial fix This is a patch for ViewPane. It doesn't disable floating toolbars or persist the locked state, but it makes them much less annoying by changing the default to "locked" rather than "floating". It also includes the following changes: - Removes the additional "close" button, which appears to have been re-added in the recent merge with head. - Notifies the tab folder of the focus event after updating the viewpane's state (rather than before). This currently has no effect, but may avoid future headaches if the tab folder needs to make use of the viewpane's state within it's focus handler.
Note to whoever is currently maintaining the floating toolbars: the docked/undocked state should be persisted in the view, rather than the viewpane -- once you dock or undock the toolbar in the view, you'd expect it to be docked or undocked in all perspectives rather than only the current perspective. I've held off on persisting the state, since it will create new API and we should REALLY be sure we want floating toolbars before we bother with this.
Created attachment 7918 [details] Another alternative to consider (disabled floaters) For consideration, this patch does the following: - Floating toolbars are removed entirely - The redundant close button is removed - If the toolbar is empty, it disappears entirely (can be observed in the outline view when the welcome editor is open). If we combine this patch with something that combines the view menu with the system menu, then many toolbars disappear entirely. This will save almost as much screen space as floating toolbars, but will be much less contraversial.
removed floating toolbars moving to invalid
