Community
Participate
Working Groups
I20040219 I can choose where the fast view icons are but there's no option to specify the location of the perspective toolbar / icons.
*** Bug 51191 has been marked as a duplicate of this bug. ***
*** Bug 52029 has been marked as a duplicate of this bug. ***
I marked bug 51191 and bug 52029 as duplicates of this bug, because this bug captures the current thinking after discussion with Julian. The feature of allowing the user to move the perspectives tools to any of the 4 sides of the eclipse window is considered to be the most useable solution (similar to the Windows "task bar"). Unfortunately, it was felt that this was too much work to get done in the 3.0 time frame, so, sadly, it is being deferred to a later time. It would be nice if that decision was revisited (particularly as there is still work to be done to fix the toolbar's resizing bugs in the current, sub-optimal, hard-coded, position in the upper right corner). Points that were made during the conversation are: - they want to keep the "Nike swoosh" in some form, for "product branding" - new users need to have the text, not just the icon, so "show text" needs to be on by default - when they thought about putting the perspectives toolbar in the top left, which was where bug 51191 suggested that it go, they decided that when new perspectives were added, the regular toolbar (coolbar) would 'jump' to the right, which users would find disconcerting (conversely, if a perspective was deleted, it would jump left). Further, the fact that some perspectives have multi-line toolbars would make this jumping more obvious, as the perspective toolbar is supposed to wrap when there are multiple lines available. It was agreed that adding and deleting perspectives was very rare once a user reached a steady state. But apparantly there are about 30 (!) perspectives in WSAD, so it might be a while before a new WSAD user reached a steady state. - the idea of having the perspectives toolbar in the lower left "status line" area (a la Windows "task bar") was interesting - of course, the "status line" popup would have to cooperate by not obscuring it - it was felt that the "perspectives toolbar" and the "fast views bar" were distinct ideas that need to be kept separate. As such, each one should really be able to be moved independently of the other, but they often might have to share the same "bar" space. (There was some discussion of whether fast views were worth keeping, but Julian said there are users out there who would be extremely irate if the feature was removed <g>). - perhaps there should be 5 possible locations for the perspectives bar: bottom, left, right, top-left, and top-right. Please read duplicate bug 51191 and bug 52029 and some of the dups of these dups <g> for more info on why the perspectives toolbar should not be in the upper right corner. Please see SN any time for a demonstration of why the upper right corner is sub-optimal. ;) Consider all of these arguments to be votes for allowing the perspectives toolbar to be moveable, so that all of these people can move it out of the top right corner asap.
Hell will freeze over before this is changed back to being useful. Looks are more important than functionality.
Could this get a higher prio?
added preference to dock the perspective switcher under the main toolbar. Have not added anything (i.e. drag drop or menu option) directly on the perspective bar as the preference is workbhench wide
From comment 6 I would guess I can only have it below the main tool bar which is not exactly what this feature talks about: this feature request is about docking it where I want (or at least where it was before ;-).
This bug is considered stop ship for M8.
*** Bug 58151 has been marked as a duplicate of this bug. ***
If I'm going to get a hard-coded choice of two locations for the perspective bar, I would prefer those to be: a) On the tool bar (the default location in M8) b) Where it was in 2.x Reasoning: Vertical space is more precious than horizontal space. If I'm not going to use leftover space at the right side of the tool bar, then at least I shouldn't have to give up one line of code in my editor. I'd much rather give up two columns in my editor than give up one line.
Regarding comment 3: In my opinion, any "Eclipse Branding" needs to fit in with standard O/S user interface idioms. For example, the view title bar gradients in 1.x and 2.x fit in with other applications (mostly Microsoft Office) that use that ideom and it does not clash with the way things are drawn across various platforms and UI themes. However, the "swoosh" line *does* clash with themes that are boxy by default--namely Windows 2000 and a lot of Linux themes. Moreover, the main applications that use curvy lines are (a) media players, and (b) games. I think it would be a mistake for us to brand Eclipse in a way that visually associates it with entertainment software. Even on Windows XP, MacOS X, and Linux where window borders are rounded in some of the default themes, "serious" business applications retain the spare, conservative, "boxy" look. While I'm not opposed to branding in the abstract, this particular instance of it grates on my aesthetic sensibilities rather seriously.
Upon further consideration, I might consider having a "task bar" area in the status area a reasonable choice. - It's a UI ideom that people are familiar with, - It might help communicate the purpose of perspectives--having task-specific view arrangements--better than anything we've done to date. - RCP applications will likely use perspectives as the means for defining an entire "application UI", so perspectives are likely to morph sematically closer to applications as time progresses anyway.
Further thoughts related to comment 12 and the end of comment 3: - Eclipse is changing from being an IDE into being a generic RCP application container. - Anything we can do in the UI to communicate this shift is A Very Good Thing, in my opinion. - The status area of Eclipse is currently one of the most uncrowded parts of the Eclipse UI. There is definitely space for a task bar area down there. - Therefore, I'm voting for morphing the perspective switcher into a "task bar" in the status area of Eclipse.
Please log a separate bug for the task bar suggestion. I believe it is not necessarily in line with what this bug is asking for.
Agree with comments 11 and 12. My 'first impressions' were listed in bug 51191: "I personally don't mind it in the old vertical sidebar, and I also think it would be interesting to see it in a horizontal bar on the bottom left, analagous with the OS's task bar." Actually, come to think of it, my very first impressions were in email: " a) Most operating systems today put context-switching buttons across the bottom, so "on the bottom" leverages a world community of pre-existing knowledge. b) "Left-justified" places it under (or over) the (default & best location for the) Package Explorer, Navigator, etc., i.e. the top-level view showing the contents of the perspective. c) Not sure if the perspective toolbar can share horizontal space with the status line, but this should be investigated." I guess what we are all arguing about here is that not only do we want to choose from several locations for the perspectives bar, but we also care which of those locations is the default. :)
Sorry - I didn't see comment 14 until after I posted comment 15. I think that one of the possible locations for the perspectives bar should be down in the status line (i.e. as a "task bar") and I think that this bug report is exactly the correct place to be discussing this. Further, I would argue that after we try it, we just might like it, and that it may even be possible that it could be the next default location. :)
Regarding comment 14: In Gnome and KDE, the task bar is implemented as a "cool item" that is put in any desktop tool bar. In KDE and Gnome, these took bars can be positioned on any screen border. One way to implement what this bug is asking for is to make the task bar into a cool bar that is positioned at the bottom of the window. Then put the perspective switcher into a "cool item". Presto, you can then drag it wherever you want: top, bottom, wherever. I'm just contending that the default position should be the bottom and that the buttons should resize themselves like task bar buttons do. Viewed this way, would you agree with me that this is not a separate bug, but rather a proposed way to implement a solution to this current bug? News Flash: =========== There was a midair collision between this comment and comment 16. Fortunately, there were no casualties and both comments made it into Bugzilla... ;-) I agree with what Carolyn is suggesting here.
comment #17 seems interesting, unless someone would you care to submit a patch demonstrating this solution we don't really have the cycles to go further then we have for 3.0. If there is a patch I am willing to look at it.
In case someone wants to take a look at this: - Where's the task bar code? - Where's the perspective switcher code? - How is this all hooked together? Extension points? Java code?
Regarding comment 14, I came here because bug 58151--which is specifically about the *location* of the perspective switcher and not about its *configurability*--was marked resolved/duplicate with this one. If you want to have two separate bugs for perspective bar location and configurability, that's fine. I'll go reopen bug 58151 and copy my comments there. Which would you prefer it to be?
the class WorkbenchWindow has the code that creates the perspective switcher toolbar docked below the coolbar. See method WorkbenchWindow.createPerspectiveBar() a separate bug about the configurability seems better
>>a separate bug about the configurability seems better<< In that case, I request that bug 58151 be reopened. I'd do it but I can't since I'm not the bug owner. >>the class WorkbenchWindow has the code that creates the perspective switcher toolbar docked below the coolbar.<< What about the code that creates the perspective switcher as a part of the main toolbar?
The code that creates the perspective switcher in both locations stems from the WorkbenchWindow method I mention. ToolbarManager is actually creating the toolbar etc... but this can be located using the wonderful code navigation features of Eclipse<grin>
Support for the perspective switcher on the left is planned as part of the R2.1 presentation work in bug 59956. Adding this support in 3.0 will not be done as it introduces a number of issues regarding support for preferences such as allowing text on the perspective bar, as well as having a more robust solution on how to would use the vertical space in the case of fast views and perspective switchers being docked on separate sides of the window, should they snap together etc... lowering priority bug increasing severity, will revisit after 3.0
fixed by Andrew by M9
*** Bug 67775 has been marked as a duplicate of this bug. ***
