Bugzilla – Full Text Bug Listing
| Summary: | [Plan Item] Evolve the Eclipse user experience *CONTINUED* | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mike Mallett <mike_mallett> |
| Component: | UI | Assignee: | Michael Van Meekeren <michaelvanmeekeren> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | a.broekhuis, aiproulx, alvin, analogue, andre_weinand, as, avijayr, belldj, birsan, bogofilter+eclipse.org, boris, brian, bugs, burner, chambery, chris.may, chris, clayberg, cmlenz, codex69, csmclaren, daniel_megert, danrubel, dcorbin, dev, djspiewak, dmeister, eclipse, eclipse, ed.burnette, email, erich_gamma, fjania, gunnar, horst.naujoks, hudsonr, jasc, jcagle, jcompagner, Jeff.Duska, jinli, jpshack, jwillans, kehn, Kevin_Haaland, Konstantin.Scheglov, kpeter, levik, lucas.bigeardel, m.a.r.k, Matthew_Hatem, mbeltzner, mcc, meyer, mfaraj, mik.kersten, morten, n.a.edgar, nikolaymetchev, patmc, pkor, rfaust, rjlorimer, rodrigo, scott, sdavids, slavescu, thatnitind, Tod_Creasey, turnham, wakao |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Mike Mallett
Just released a fix so views that are not the active one no longer have the close box on them, so this should prevent all those accidental closing of views when just trying to birng them to front. except now you must bring a window to the front to close it. time consuming and annoying. since it now requires at least two clicks to close an inactive window anyway, why not just get rid of the space-hogging close box and use a context menu, like several people (myself included) suggested? I don't see a difference between having a context menu and having the close button only on the active tab. In both cases you have to do both clicks. Both case are not prefered usability and to be honest, having the close button only on active tabs is bettern than using the context menu because you an use the same mouse button for both clicks. However, we shoud not move the close button from the tab. Is should just not be that large and clearer visible. In the old source the close button of inactive tabs changed its look when it was hovered. This way anybody could realize that his click will close the tab because is mouse cursor hovers the close button. I agree with the last poster. It is intuitive to hover over the right-hand area of an Editor's tab. Instant hover feedback shows an "X" close button which is pressed. All in all this adds up to one intuitive move of the mouse and one click. Bingo! I think the 2 close buttons (tab & toolbar) are redundant. I would prefer the one in the toolbar, but I think it should be a preference. The user should be allowed to turn off the close button in the tabs completely -- probably just for views, since editors only have the one close button. Personally, I think that a close button placed so close to where the user selects the tab is problematic. MVM, This change is problematic. It requires plug-in startup simply to close a view. I understand that people found themselves accidentally clicking on a rollover X button. So, why not display the X button ALL THE TIME. Make it faint, but still visible. This will allow closing a view without startup of plug-ins, and should reduce the error frequency. I find the presentation of the X button frustrating. It doesn't feel like a button. It doesn't have a rollover border, and it doesn't depress (immediately) when I hold the mouse button down. I have been working on lightweight crap in the GEF palette for years. The problem you are seeing with the MouseDown event not coming quick enough is due to the fact that you have a DragSource on the CTabFolder. There is a 400 millisecond histeresis in windows which delays the mouse down event. The result is that the close button just doesn't feel good. Another side-effect of this lightweight approach is I can start dragging a View by pressing down on the X. This doesn't make any sense. For these two reasons, you should go back to using heavyweight controls for the close buttons. See bug 10420 for delayed MouseDown Randy (and anyone who comments here), please log bug reports for things you feel are bugs as we can not mark fixed anything in this one as there is too much here. I still like the first attachment. In 0217, even non-stacked views have their label and toolbars on separate rows. This is a huge waste of space. I'd like to see the toolbar squished in beside the Tab[s] whenever there is enough space. And when there is just 1 view, the tab is distracting and not as clean as 2.1. More comments for 0225 integration build: -There are too many gradients displayed. Every single CTabItem and the CTabFolder itself are all displaying gradients. -In 2.1, we had "maximize view" by double-clicking on the view. So why is there now a button just for doing this? *and* a button for rolling up the view. This takes away from the space which should be used to display the view's toolbar. In addition, instead of one 'X' per stack of views, there is now space reserved for n X's. -The 3 pixel border just inside every PartPane is a gratuitous waste of space, and it disturbs the continuity for clients who have designed their part's L&F with the expectation that a dark border is immediately outside of their part's Control. For example, -Some views can be rolled up even though there is no view above or below to reclaim the space. Rollup should be removed for these cases. - the single editor tab is centered instead of left-aligned. - all of the little mini buttons are white with faint gray outlines. Why not just use simple black shapes like before? Just got the 20040226 Integration build to try out the new L&F for a couple of hours. I'm sorry, but as it stands right now it is absolutely horrible and severely cripples my workflow. * Real Estate reduced * Perspective buttons should return to where they were in M7 and earlier. When I'm navigating and jumping perspectives, my mouse is always in the left- hand window area. Now I have to jump over to top-left and then back again. * With Multiple tabs set on, I can't see at a glance how many tabs I have open. * When closing Editors, tab focus jumps all from tab to tab in a seemingly arbritrary way * The little white maximise/restore/minimise buttons look disabled. * X buttons on tabs when they used to be on windows - aarggghh! Can we all just roll back to M7 and pretend this was a bad dream? It was a bad dream, wasn't it? PB I think this will always be very heavy PRO and CONS question so here my view.. (using build 200402250800) i really like the new view of the latest builds. it is much cleaner er smoother. I also showed it to a real designer gui, and he also immediantly said wow much better looking. What i didn't like was the very noticiable blue border around the active view. So i changed that color to a little bit darker gray then not selected tab color. Now i really love it. What still bothers me. Why are there still so many pixels wasted at the right side?? Please make it as small as the leftside. And only grow it when i drop a fastview on it. It doesn't have to be that big to let me know there is a fastview area!. Because if i drag a view to that area, i do see a small border from top to bottom. So i would say remove the pixels between the rightside of that border! What i also don't like or can't get used to is the popup list if i (double) click on the active tab. Can't you make it so that popup the list on single click and maximize the screen on double click? Thats something i was so used to.. Please leave the perspective bar where it is now. people complaining about mouse movements just should use CTRL-F8 ... And why is it that youre mouse is so much on the left side? Scrollbars are always on the right... And i have my outline view also on the right so i don't see a problem.. My last post had errors. Corrections: * Perspective buttons should return to where they were in M7 and earlier. When I'm navigating and jumping perspectives, my mouse is always in the left- hand window area. Now I have to jump over to top-right and then back again. * With Multiple tabs on in the editor view, I can't see at a glance how many files I have open because I only ever see three or four tabs. I don't like that it is impossible now to maximize/restore view/editor using double click on folder tab. Often I switch to view, see that there is something interesting and want to maximize it, or I just know that I want to maximize it. Now I have to move mouse cursor to free space of folder and make double click there. Or, even worse, use Ctrl+M. Please return double click handler. I.e. single click will as currently show list of views/editors, but double - will hide list and maximise/restore. Every one of Randy's comments in #10 (except the roll-up comment) had previously occurred to me as well. Excellent post. With 0226, you are definitely getting closer. A few more comments: - The new drag and drop for views is a great improvement. - I miss the pretty win2k style view title bars. - See note #28 in bug 52175 - It would be nice if the fast view area could also be positioned below the cool bars, but this is a low priority item. I think the voting so far tells the story: for (52685 & 37997): 2 against 52780: 46 (add pref) 52875: 26 (revert) Based on these numbers so far, I think there's a big case for making the new look optional *and* have the old look be the default. Please respect the votes and don't force the new look on us! Created attachment 8206 [details]
end of the view tab area
I'd like to be able to drag and drop a tab group by holding on to the end of
the view tab area.
+1 to making the new look optional In I20040226: - Being able to dock fast views in different places and orientations is nice. - I still can't get used to not seeing all the tabs for the views or editors in a stack. Is there a way to quickly cycle through just the views or editors in the current stack besides ctrl-F7? - The little minimize and maximize icons on the view/editor stacks take up too much room and are too Windows-centric (i.e., they look the same on every platform but will only be understood by a Windows user and not, say, a MacOS X user). Also you can't minimize editors. My suggestion is to do away with the maximize button since you can do that by double-clicking. I'm not sure what would be the best way to handle minimize. - Close buttons on the view tabs don't work intuitively. For example, because of the close button and the view icon, clicking on a tab changes its size and position which isn't the way I'm used to tabs working. Have you considered not having the close button on the tab, but putting them on the far right of the view toolbar instead? Almost all views have toolbars, and with the new look much of the toolbar space is empty. You could put a 'make into fast view' button there too. - Putting the perspective bar up in the toolbar area is not having the desired effect of saving real estate. Often it causes the coolbar to split into two lines, making it very tall with a lot of empty space. I suggest either treating the perspective bar exactly like the fastview bar, or treating it exactly like a toolbar (without the wasted vertical space). Created attachment 8216 [details]
Wasted space in perspective bar
As toolbars stack up, more space is wasted in the new perspective bar
(I20040226).
Comment #20, thanks ED thats a bug we are working on feel free to log it. comment #19 "not seeing all the tabs" - working on this, log a bug if you like "is there a way to cycle through views or editors" - there is a pull down on the tab of the active view or editor to switch to others "little minimize and maximize icons" - these are not final "Have you considered not having the close button on the tab, but putting them on the far right of the view toolbar instead?" - yes, although then it would appear to apply to all views Re comment #19: Placing the close button on the view _toolbar_ would not suggest that it closes all views in my opinion. Certainly, it would appear so if the button was placed next to the minimize/ maximize buttons, but the view toolbar is completely view specific, so adding the close button to it seems like the right thing to do (if it's going to be moved out of the tab, which I would also prefer). "yes, although then it would appear to apply to all views". Maybe so, but users have gotten used to this in the previous *three* releases of Eclipse. The benefits (less horizontal space, accidental closure, clutter) outweight this concern. Microsoft products continue to use a single X button. For example, FrontPage 2003. It is a convention in MDI, even if its a bad one. hm... there are also cases when a view has no toolbar + and no view menu, in which case the title bar is hidden logged a bug for comment #17 (John) https://bugs.eclipse.org/bugs/show_bug.cgi?id=53305 You all have been providing a lot of valuable input on the look and feel effort (and its impact to the rich client platform). Your comments have influenced our work so far, but we know there is more to do. We are going to spend the next week consolidating the feedback and adjusting our plan accordingly. We will have the updated plan by next Friday (Mar 5). Thanks for your patience and your investment in helping us make Eclipse as good as it possibly can be. I know we will end up in the right place. There has been a lot of discussion about this in many bug reports so I am pasting these comments several places. Sorry for the duplication, but I wanted to ensure maximum visibility. I am new to Eclipse, but I have worked with a few other IDEs. It seems to me most comments here are made by long time Eclipse users. Their suggestions are very important and good. Please respect their options. As a newbee, my option may give you something about how a outsider view the Look & Feel of Eclipe. NOTE: I am talking about the LOOK & FEEL, not Eclipse functions. OK. First: Amound JBuild, Netbean, IntelliJ, Eclipse (Build 0226) already has the BEST L&F. NOTE: It is called LOOK & FEEL. So it means: the LOOK is good & it makes me FEEL well. Great Job, UI Team!!!! Second: The M7 new L&F is bad, because it is too strange. Build 0226 is much better. There is still one thing not good - the tab position of the Editor. (Windows>Preference>Editor>show multiple tabs) should be the default option. I can live with the tab group up idea, but I can not accept the default editor tab position (as a newbee). Why the curent default position is not good for me? Because it is strange. Most other applications (not just IDEs) always have tabs 1)at the far left end, 2)at the far right end. If you do not agree with me that the position is strange, could you please tell me an other application that has its tab position at the MIDDLE? One of the reasons to put the tab in the middle was to give the user a visual indicator for single vs multiple tab mode. > The M7 new L&F is bad, because it is too strange I agree with comment 27. The original look and feel is as bad as the new. That's why I started a L&F effort back at R2.0, by posting patched/hacked JARs to the newsgroup which improved the appearance of tabs among other things. Some people seemed to appreciate it and would even maintain it when a new milesone came out. Screenshot to follow. Created attachment 8243 [details]
2.x tabfolder hacks in 3.0 M7
This is running in M7.
The "Randy Patch" is great for those who want to apply it. To be honest I haven't tried it, but I know lots of folks like it. That said, it's an option, not the default. I'm definitely in favor of options in an environment like this. That's what makes Eclipse so great. You can plugin or override anything you want. However, when it comes to the default options, if most folks are happy with something, don't change it. (The default block comment key binding change comes to mind as well...) Add new options (like the ability to use comment toggling or an alternate L&F), but unless the current capability is unusable or severely gets in the way of a truly necessary new feature, leave the defaults "as is"! And regarding "wasted screen space", how about trying a higher-res monitor and/or smaller fonts? I'm at 1600x1200 and there's plenty of room. Some folks I know use two monitors. The only time room becomes an issue is when I'm teaching using Eclipse on a 1024x768 projector with a 20-point font, but even then it hasn't really been that big of a deal. We've got control-o for the popup outline, so I usually close the outline view in the Java perspective anyway. (Note: my preference, so I don't mind closing the view and saving my own perspective...) (Personally I like the perspective toolbar on the left) I might just have to DL that Randy patch now ;) It does make the tabs stand out better (without looking foreign). But I think I heard it also changes the position of the perspective bar, right? Created attachment 8244 [details]
Another 3.0 mockup
Here is another mockup I have made. What's interesting:
1) More traditional tab shapes. Milder use of gradients.
2) Active Tab indicated by: bold font, "raised" 1-pixel, different FG and BG
colors.
3) "widget" to hide and reveal rarely used items on view toolbar. This would
require that the user or programmer decide what is rarely used.
4) View title(s) and toolbar should and do appear on same row when possible.
What missing:
- 3-pixel border inside tabfolders
- Tabs which move around when you click on them.
I was considering the idea of another "toolbar" row below the application's
coolbar. This row would host any fastviews, open perspectives, and the set of
open editors. So instead of editor tabs appearing in the editor pane, they
would appear at the top of the application. Or maybe an address bar like
web-browsers could be an alternative. But anyway, that's not the point of the
mockup.
Randy, great work! Is the source available somewhere as patch? Although I think it would make sence at this time because HEAD is going to change ;) Gunnar, mockup == PhotoShop (actually Painter). Sorry :-(. JavaDude, http://dev.eclipse.org/viewcvs/index.cgi/gef-home/team/?cvsroot=Tools_Project (beware of URL-wrapping) I finally have a 3.0 M7 patch if you want to try it out. Previously I mixed in my JAR in the plugin.xml file, but for SWT this has changed to the manifest.mf file. If you only want the tabs, only take the "swt" portion of the ZIP. The JDT portion adds: - JavaDoc wrap-as-you-type - Insertion of SPACE character when you forget (lazy), for example typing: for(int i=0;i++;i<10) becomes: for (int i = 0; i++; i < 10) Picking up Randy's toolbar idea in comment #33... In bug 52217 I suggested that the perspectives area should appear on a coolbar. Now that Randy has thrown fastviews into the mix, why don't we just do what most MS Office users would expect: implement both the perspectives area and fastviews as coolbars and allow coolbars to be oriented vertically as well as horizontally and docked on all four sides of the screen? I have hesitated to suggest this only because it sounds like it might be a big job--but if we are going to go through all the pain of a new look and feel anyway, perhaps now is the time to tackle this. Thanks, John Wiegand (comment #26), for chiming in. I am sure that a number of the posters on this thread breathed a sigh of relief when they read your comment. perspective bar: personally, i am a strong advocate for the perspective bar being a regular toolbar in the application's coolbar area. the usability team, however, feels that it is important to significantly distinguish the perspective bar from other toolbars, esp. for new users. my suggestion, then, might be to make the perspective bar act like a regular toolbar but distinguish it by either: a) showing text on the buttons by default, making this toolbar different and more pronounced than the others by default (like the 'links' bar in IE), and/or b) changing the look of the toolbar itself (like the 'outlook bar' in outlook, i think its named..) i prefer choice a), because advanced users only have to turn off the text in the preferences to make the perspective bar like any other toolbar. either choice however, would give the user full flexibility to move the perspective bar within the coolbar areas. my default position for the perspective bar would be bottom most row of the top coolbar region, taking the entire row (again, like the 'links' bar in IE) I think, Chris, one item you are getting at is that you would like the perspective switcher to be a regular toolbar mostly because in general toolbars are customizable. You can move them, disable them, show text, icons, both, etc. My personal belief of one of the problems with the existing perspective switcher mechanism is its inability to be customized (in the old AND new UIs). Granted, now the text can be enabled/disabled, but it is still not possible to reposition or resize the perspective switcher. This would seem to be even more important to RCP application developers (over Eclipse users) because having customizability there from a framework perspective would allow for more application diversity. I wonder, how difficult would it be to a.) Provide the ability to hide the perspective switcher and b.) provide a toolbar contribution that had buttons for each open perspective (a toolbar implementation of the perspective switcher)? It seems that would satiate a lot of the current concerns. Created attachment 8304 [details] StatusBar at top of workbench In 0303 build you can dock the fastviews to the status bar area. This is great! It really saves space. But, I don't think fast views at the bottom will ever be "fast" enough. Now if I could dock the perspective bar there too, and move the entire status bar to the top just below the coolbar, then we'll have more or less what I was thinking in comment 33. See attachment Any comment from developers on whether this new L&F will be the default in 3.0? Again, I say "look at the votes against"... I love Eclipse and want to keep using it, but this new L&F is unusable to me. Scott, those types of comments aren't very helpful. What are your specific complaints? Is it the tabs? Color choices? Placement of view toolbars/perspective bar? For example, I'm sure you think that giving the user the freedom to dock the fastview bar to the right or bottom is a good thing. That's not the point.
My point is
****is anyone listening to the votes*****
It still sounds like full-steam ahead, even though the current voting is:
37997/52685: 2 votes (new L&F)
52875: 31 votes (revert to old L&F)
52780: 51 votes (offer choice of old/new L&F)
That's 82-2 *against* forcing the new L&F.
I'm not looking for y'all to fix the things I don't like. I'm looking for
y'all to respect the votes and **keep** the old L&F. It looks great (with a
few minor tweaks to help make selected tabs more obvious)
(Note: I still feel the above voting says "make it optional, but have the old
L&F be the default. Most folks won't know they can change it, and if the new
L&F is the default, it'll turn off *lots* of folks right away)
To answer your question, though, a few of the things I don't like:
* overall: it just doesn't look professional (like the native O/S)
(My biggest complaint -- Eclipse's professional look was an
immediate hit with most of the folks I've demo'd eclipse
to - then, showing the function thrilled them.)
* the look of the tabs
* view-border highlights
* you can't double-click a tab to maximize the view
* single-tab editor is the default
* perspective bar not on the left side
* if view tabs are set to the bottom, there is no indication at the top what
the view is (the old L&F always had the view name at the top with the action
bar)
I like Randy's idea and mockup in comment #39 (let the perspective bar be dockable in the status line too) except the part about moving the entire status bar. Status bars go at the bottom - don't mess with my mind Randy :). Having an option to turn off the status bar would be ok though. Regarding docking of views (and bars) in general - I was playing around with this last night and it just amazes me how well it works. The cursor changes, the rectangle drop zone feedback, etc., it's just beautiful. Kudos to Michael and the rest of the the UI team! I like the view roll-up option, but I think one subtle shift would make it more natural to use. I use this option not when I want a view to shrink, but when I want to see more in another view. This being the case, it would make more sense to give each view the ability to expand rather than the colapse function. As a follow up for comment #26 from John, we have posted a document on the Platform UI team Proposals page containing a summary of comments and responses concerning the changes in the UI post M7. Please visit the proposals page: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/docs.html and select the first item (titled "New Look ... "), or open it directly: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_0- Look/UIResponse.html thanks to all who have been actively contributing here Sorry, note the cut off URL in the previous post. John, that's a good point in comment 44, how would you see this expansion working when views are/are not aligned in the same column? > how would you see this expansion working when views are/are not aligned in
the same column
It sounds like what he is suggesting is that you click on the view you want
bigger, not the one your want smaller. The layout behavior would be identical
to the current, just the interaction changes.
There is a slight problem in the way PartSashContainer is done as a binary
tree. I may have 3 views stacked along the left side of the workspace window
like this:
+Container
+Container
View A
View B
View C
If I collapse View A, *ONLY* View B gets bigger. So the extra space is not
distributed equally. You see similar behavior when resizing the workbench
window. For example, in the Java pespective, when resizing width, the Package
explorer grows twice as fast as the Outline View.
I just read the summary, and would like to make the following comments:
1) I don't see how a show/hide toolbar for the view is useful. I would never
use this feature, and it will just clutter all of my view menus. I think people
are only asking for this feature because of the poor layout algorithm employed
by the new L&F. Often there is enough space on the screen to position the
toolbar without reducing the space available to the view[s] (see attachments).
Assuming Eclipse eventually gets it right, it would be silly to have a "Hide
Toolbar" Action which does not benefit the user.
Assuming this feature is implemented, there are a few issues:
How does the workbench know if the toolbar items are critical to the view's
function or display of status? Also, how would you handle this for a View like
the Outline View, which is really just a shell for pages provided by editors?
As a user, I would expect that if I hide the Compilation Unit's Outline
toolbar, this would not affect the PDE's plugin.xml toolbar.
2) If you allow pluggable looks, I would be one of the first people playing
with this feature. To me, the most important aspect would be things like:
A) placement of the View's toolbar, "close view", "rollup", and "maximize"
buttons. Also, other *layout* issues such as the insets for a view pane, the
width (and potentially appearance) of Sashes in SashPartContainer.
B) The ability to paint stuff like tabs and shadows, of course.
C) Very low priority would be placing perspective and shortcut bars (it sounds
like the user will end up with enough control here). IMO, this could be
deferred.
Again, I mention the voting and say "old L&F should be the default with an option for the new L&F": The votes are now: * 51 - provide option * 32 - revert to classic look * 3 - new look and feel only The response posted at the UI page indicates that the new look will be the default with an option to get "old tabs". Based on the votes above, it sounds like the reasonable solution is to have the old L&F as the DEFAULT, and provide an OPTION for the new L&F. The other bugs I mention don't just say "give us the old tabs" -- they say "give us the old L&F" -- the whole thing. LOTS of people have spoken out against the new look. Please respect this and MAKE THE OLD L&F THE DEFAULT. The only really valid complaints I've heard against the old L&F are that it's hard to tell which tabs are selected and it takes up a bit more room than some folks would like (I'm perfectly happy with the sizes). Everything else seems like I have no problem with an "eye candy" option. But it sounds to me like the "everything must be skinned" crowd is making decisions based on what they like, and not based on the majority of those who took the time to vote on this issue. (BTW: One thing I forgot to mention was the view borders -- I really liked the old 3d view borders -- they looked rather classy.) I see Randy's point re: PartSashContainer in comment 48. If the user is indicating which view should be expanded, rather than which should be collapsed, the behavior of PartSashContainer becomes even more confusing, especially considering that the user has no visual queue indicating how the controls are nested. Expand could have one of two behaviors: (1) expand to fill the column (e.g. all other views in the column collapse) or (2) expand to fill the PartSashContainer (the other view in the sash is collapsed. Replace collapse with expand might reduce the overall configurability of your view area, depending on how it was implemented. I wonder if having both options is overkill… I think this idea needs more thought, but I'll make a few rambling observations and then perhaps others can chime in: Expand and collapse are used for temporary adjustment of the perspective, not its general layout. I may start my work by moving views around to get an optimal work area, but it is after I've begun my work that I'll want to quickly get a better look at a particular view, hide an irrelevant one temporarily, etc. We have two maximize and two minimize options for views. To maximize we can either use the maximize function so that the view expands to the entire workbench window or we can collapse other views so that a view occupies and in entire column. To minimize we can either dock a window in the fast view area, or collapse it so that just the tab appears. All the user needs from these features is either the ability to quickly indicate ‘I need to get a better look at you just now’ or ‘take off, you are in the way’ and quickly revert to the previous state. While I often want to maximize editors, I am more likely to want to a view to expand to fill a column rather than the whole screen—unless of course there is no column to fill, in which case I really do want to maximize it. The collapse function and the fast views solve opposite (but related) problems. The collapse function is helpful when the user wants to use a view most of the time, though it is occasionally gets in the way. Fast views are better when one wants to see a view (particularly a large view) only occasionally. Regarding the New look detailed response... Could we discuss removing the option to have view tabs on the bottom before you nix it? This may seem trivial to you, but I believe that there are some good ergonomic reasons for keeping them. I am not an expert on ergonomics, but it has been my experience that right- handed mouse users tends to be most comfortable working from the bottom right of the screen since it is more natural for the hand to swivel in (up and left) than the reverse. This being the case, movements into top or left halves of the screen involves more movement (and more strain). Placing both view and editor tabs on the bottom instantly makes them significantly more accessible. Even with two views in a column, moving tabs to the bottom will place both tabs in the bottom half of the screen. Tabs at the top guarantees not only more trips to the top half of the screen--but trips to the very upper edge, and even worse, the upper left edge. For people who live in Eclipse and struggle with repetitive motion disorders this change could be a big deal. 1) regarding comment #48, I think it would be possible to invert the behaviour to cause a view to grow as much as it could in the column it belongs in. I also agree with Randy where it depends on the layout for the perspective. I have sent a note to mailing lists of Perspective layout owners asking them to consider changing their layout where possible to make collapsing more useful (whether it works the way it does not or the inverse as john suggests). One issue is we have two kinds of view growth (maximize and this column grow option). Another thought would be a snap behaviour on any inner side of a view where it snaps all the way to the opposite side of the workbench temporarily. Hide/Show toolbar is intended for advanced users who know that they will or will not be using that particular toolbar. I agree the current layout support is not working and needs to be fixed as well. 2) re: comment 49, I kind of liked the borders myself, there are however others who are stating in other bugs that we should look more like the modern OS styles, which tend to be more flat and simple. I think fastvies however do need to maintain a bolder border so they stand out. Any thoughts, are you a windows XP user or other ? 3) re: comment #50, I do not disagree that there are cases that just don't work. If collapsing is confusing perhaps it should be removed for now. Since we can not guarantee how this layout has made use of PartSashContainers. comments? Perhaps the snap behaviour is more what you are talking about. There are many ways to manipulate a view, I agree that having all options is going to be daunting for new users especially (drag, resize, collapse, maximize, fastviews, detached views.. and now.. more!) What about adding support to assign a keybinding to a view then whatever state the view was in (i.e. fastview etc..) that key combination opens the view and hitting it again would close it if it were a fast view for example. 4) comment #51, more then willing to discuss tabs on top + bottom etc... I am right handed and am not sure I can relate to all your points, so I will throw out some thoughts. Would key bindings help for views getting focus in this case? I can try and draw out some cases that don't look too hot. Such as the outline view, when it is empty and the tabs are on the bottom it will not have anything separating it's top border from what is above, this is not normally what you expect, titles are now part of the tab so not having the title at the top as in a shell is not expected either. Hmmmm.. .it's difficult, the purpose of removing the title bar was to save space, so tabs have to take on some of the features previously supported in the title-bar. Don't you need to be at the top edge of the screen to use menus + toolbars etc..? I've read the document and concur with previous comments that the resolutions don't go far enough. You say that supporting the old and new look is difficult, and I can see why this might be the case - the strategy you have taken is to make concessions on the new look towards the old look. I must say that I think the alternative of starting with the old look as the base line, identifying problems and making small justified changes (which may or may not draw upon the new look proposal) is far less work to get right (and to keep everyone happy). I must admit that I'm in rather an awkward situation, the upshot of the 3.0 UI (even with the proposed changes) is that Eclipse based applications will inherit an "Eclipse-style". This is something we had simply not anticipated, indeed the one of the key reason we chose Eclipse as a platform for our tools was its application-neutral interface. This neutrality has been reinforced by the RCP-effort to remove "Eclipse" specific detail (the project menu, for example). In our view the new L&F is going against the grain of this effort. Re Comment 51 I missed this in the response -- I like having the tabs at the bottom (for everything except the editor) because it allows me keeps the more important info at the top. Looking at the screen top-down, you don't need to skip over info that you don't care about. This is another reason that I like having the title bars on the views -- the tabs at the bottom let you change the view (when you need to), while the title bar still gives you the name of the view. Of course the solution is simple: KEEP THE OLD L&F. If y'all are so hell bent on ruining the eclipse L&F, it sounds like it might be a good time for a branch. As much as I'd hate to see two competing versions of eclipse, this is what you're driving us toward. If the new L&F is the only choice (with a few tab changes as an option), I guarantee there will be a set of patches (effectively an eclipse branch) to revert to the old L&F. This will likely cause some major difficulty in keeping plugins working consistently. Instead of folks creating their own branch to revert back, how about the new L&F be created as a branch as a *separate* download. I almost said "count the downloads and see what is more popular", but likely lots of folks would download the new L&F to try it and drop it in the trash bin, so download counts won't say much. comment #54 The goal for RCP apps is to not impose any particular look, nor require them to adopt all of the concepts such as views, editors and perspectives unless you as the application designer want it. RCP apps do not inherit the Eclipse IDE look by default. In addition there are various options to pick and choose things you want to expose. Although in recent milestones and integration builds there were bugs and incompatibilities while the two code streams were being merged together. This is work-in-progress and has improved daily since M7. Scott and John, you both mention tabs on the bottom, I have created a new bug report could you please have a look? bug 54130 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=54130) for those of you with an interest in replacing the UI for views and editors altogether: you might wish to have a look at bug 53673, detailing some very recent work in this area. for randy, comment #48: "I don't see how a show/hide toolbar for the view is useful. I would never use this feature, and it will just clutter all of my view menus. I think people are only asking for this feature because of the poor layout algorithm employed by the new L&F." I am one person who wants this feature. I find it useful. There are other of us. Beware.... :) re: comment #52 (1) I do think that the expand / collapse function of views is useful and I did not mean to suggest that we should remove it. It does appear to me that the feature will evolve (perhaps even beyond 3.0) as we have more experience tinkering with it. I do like your idea re: key binding for zoom & disappear. (2) Keybindings for swtiching views would help, though I am not sure they'd be a good subtitute for keeping the 'tabs on the bottom' option. See bug 54130. As to menus and tool bars--I don't have the privilege of looking over your sholder as you work with Eclipse, but I find that I accomplish most of that I need to do by manipulating views, using context menus, view toolbars, keybindings, etc. I'd guess that many Eclipse users spend a surprisingly small percentage of their motions traveling to the menus and coolbars. I typically use these only as a last resort and I'd be willing to bet that you'll see similar behavior in the other developers around the office. It would be an interesting experiment to watch Eclipse users at work and count the number of context menu uses, view tool bar uses, keybinding calls, etc. in contrast to the number of pull downs and coolbar clicks. (Heck, we might be able to write a little code to capture these usage statistics, no? ;) ) regarding capturing the statistics, there is an instrumentation plugin that does exactly this and is pluggable (it's quite extensive actually). It is still a little sensative to internal code changes but that is improving.. have a look at the following on the Platform UI developers page (note the wrapping hoses the URL): http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/instrumentation/index.html Thanks for making this available. This looks to be a powerful tool which can help us with our UI design internally. Has this plugin generated statistics that have been useful to you in your new UI work? Are you actively collecting and analysing these statistics for your work? Should we be using this and sending you stats? Now I can know for sure whether or not I am an outlier as re: my usage patterns. :) Thanks! "I am one person who wants this feature." This feature adds complexity to both the UI and implementation for minimal improvement. I don't understand why you would want to hide the toolbar **IF** displaying the toolbar didn't take up additional space in your perspective. This is the bigger problem, and should be solved first. But you've provided insight into how work is prioritized. i concede its a small point, but toolbar buttons visually distract me. i don't like all the colors and pictures. i'm really a very boring person. it has nothing to do with their location, really. eventually i'll add customizable menus and toolbars to eclipse so i can get rid of all my view toolbars and at the same time ensure the equivalent functionality is still on menus or have keybindings. ps. trust me randy, if i had say in how work is prioritized, this entire pr wouldn't exist. MVM,
I read you mailing list message about rearranging:
+Vertical
+Horizontal
+Horizontal
to:
+Horizontal
+Vertical
+Vertical
this increases the cases where rolling-up a view does something. But it doesn't
address *what* it does. In order distribute the space equally, I propose
adding:
LayoutPart{
//Returns the maximum number of non-collapsed parts
//arranged left-to-right nested in this part
int getHorizontalWeight();
//Returns the maximum number of non-collapsed parts
//arranged top-to-bottom nested in this part
int getVerticalWeight();
}
So in comment 48, when a view is collapsed, that tree in the layout would have
a vertical weight of 1 instead of 2. Ratios would now be weighted. So the
ratio of the outer-most container would be 0.50 in both the expanded and
collapsed case. But when the weights are unequal, such as 2-to-1, a weight of
0.5 would result in the container with 2 views receiving 67% of the available
height. Here's why:
1st container(with 2 parts, weight of 2):
0.50 * weight(2) / totalweight(3) = 0.33333
2nd part (just 1 part)
(1.0 - 0.50) * weight(1) / totalweight(3) = 0.16666
So the top container *weighted* ratio is twice as much as the bottom. Note
that weighted ratios no longer add up to 1, so they have to be normalized after
they are weighted.
In the collapsed case, both end up with 0.1666, meaning they would have the
same height.
Another added benefit of weighted layout parts is when rearraging pespectives.
Currently, When you dock a view inside a column of 2 existing vertical views
(split 50-50), the behavior is not very good. You end up with 25-25-50,
instead of 33-33-33. Using weights, you would end up with 33-33-33.
I'd like to state that I started to like the new look... I refer to I200403100800 on Windows XP. I checked the multiple editor tabs option and also removed the roundings to get smaller (IMHO more elegant) tabs. The close, minimize and maximize buttons are much better now. I like the subtle gradient on the tab. It looks like there's also a - different - gradient on view tabs. I think I could get used to the blue (in my case) highlighting border around the editor and the active view. Minimizing views is really neat, I'm now using a screen layout similar to +--+------+--+ 1=Package/Hierachy |1 | 2 |3 | 2=Editor | | | | 3=Outline +==+=========+ 4=JUnit (minimized) +4-+5--------+ 5=Problems/Console/Search (minimized) Actually, I'd love to also minimize the Outline view to the right, not to the top. I never used fast views and still do not find them useful. I tried to make the JUnit view a horizontal aligned fastview but that didn't work for me. I do not like that if I want to close a non-active tab via context menu (now as they don't have close button anymore) that the tab gets active and pops up. I'd prefer Mozilla's behavior here. I really like the new "there are more tabs" context menu button. Much better than the old right-aligned triangle button. And I'm really glad that the vertical aligned side button bars are gone... The latest mockup (https://bugs.eclipse.org/bugs/attachment.cgi?id=8244&action=view) looks much better. Thanks and gratulations. What I would like to see (and what I do on Eclipse 2.x) is tabbing the Outline view under the Package view. This allows me to choose which one to view at maximum size without wasting space. I never need Package and Outline view at the same time. The horizontal perspectives bar takes way too much screen space imho. It should either be added to the other toolbar or moved back to the left side of the screen (choosable, depending on your screen size). I'm using the 0310 build and i like it so far. But there is one thing that I find annoying, the fastview bar can only be on one site at the time. It would be nice to have an option to place a fastview bar on more places then one. And instead of the fastview option i'd like to see something where it is possible to dock an item in the bar so that i can minimize it in that bar. Right now there is only fastview. I know about the minimize option, but it is to minimal, eg. the package explorer minimizes to the top. While it should minimize to the left. I think this can be solved by placing a lock button on the views when they are in the fastview bar. If this is used it should also be possible to make a view "floatable (over the other views)" but also so that the view above it is made smaller(like the minimize does when a view is placed on the bottom). Perhaps there should also be a hover option so that a view is undocked completely. If I missed some option I'd like to here it. Alexander Andre, that mockup was made by someone who has no direct control over what is being done: ME! Apparently this mockup has not stirred up much discussion. Oh well! i'm using the 0310 build and once you tweak the options/layout, it certainly is a big improvement over the previous versions. i think that multiple tabs and square tabs should be the default. the improved funtionality (being able to move stuff around) is welcome, but those tabs are still very out-of-place. i also don't see the need for the colored borders; they take up space and as mentioned before this is the domain of the OS skin. is there any way you can provide an option for native tab panes? i'd rather have the native tabs, even if it means losing the close button. from a usability perspective, close buttons on tabs detracts more than it adds, as discussed previously. i think once the tabs are less of an eyesore people will be much more likely to accept the new look. forgot to mention that resizing fast views is *exremely* slow on linux; it lags far behind mouse movements. that needs to be fixed. Created attachment 8513 [details]
Comparison of XP native tabs and Eclipse traditional tabs
I captured this screenshot using I20040310 with the XP manifest and traditional
tabs turned on (Window > Preferences > Workbench > Appearance > Show
traditional style tabs). All other settings were defaulted. Questions:
1. Is there an option currently there or planned to let the Eclipse tab folders
on the right (used in the Workbench) exactly emulate the look and feel and
behavior of the native tab folders on the left (used in the Preferences dialog
and other places)? With the same colors, mouse-over behavior, orange line at
the top, subtly beveled and shadowed borders, the whole thing.
2. Is there an option currently there or planned to make that look and feel and
behavior intercept and adjust to the user's choice in Windows Themes and Window
Blinds?
3. Ditto for Longhorn. I haven't installed the beta but I'm sure they'll change
it somehow. Is there a way to make it look and feel like Longhorn when you run
it on Longhorn and like XP when you run it on XP and so on?
re comment #71 First, the assumption here is that the questions are interms of the IDE and not necessarily an RCP app. Question (shortened text): 1. Is there an option currently there or planned to .... emulate the look and feel and behavior of the native tab folders Answer: SWT already gives us access to that control (as seen in your picture), this is not an emulated version of the native control. Is this that what you're asking? Question: 2. Is there an option currently there or planned to make that look and feel and behavior intercept and adjust to the user's choice in Windows Themes and Window Blinds? Answer: The IDE does currently support the native theme and window blinds settings (you may need to restart for theme changes to apply in eclipse). The IDE colours are taken from current OS theme, changing the theme will change the colours you see in eclipse. Also note on WinXP if you add the manifest the SWT controls will also pick up this style. 3. Ditto for Longhorn. I haven't installed the beta but I'm sure they'll change it somehow. Is there a way to make it look and feel like Longhorn when you run it on Longhorn and like XP when you run it on XP and so on? Answer: In the eclipse IDE the majority of the widgets are native and to the extent that Microsoft still supports them and/or changes them we will pick this up. I think you've misunderstood what I'm trying to say so I'll reword it. 1. Will there be an option to let the Workbench viewer/editor tab folders (the ones shown on the right side of the picture) exactly emulate the look and feel and behavior of the native tab folders? The left side of the picture shows that native tab folders are currently used in the Eclipse Preferences dialog and other places. By look/feel/behavior I mean the same colors, mouse-over behavior, orange line at the top, subtly beveled and shadowed borders, the whole ball of wax. 2. If so then will there be an option to make the look/feel/behavior of those same Workbench viewer/editor tab folders intercept and adjust to the user's choice in Windows Themes and Window Blinds? 3. Ditto for Longhorn. In other words, will the main workbench window view and editor tab folders be able to look/feel/behave like Longhorn native apps when you run it on Longhorn and like XP when you run it on XP and so on? I'm talking about both options in the IDE and API's for RCP apps (that the IDE uses of course). I like the new look. I miss the "double click on tab to maximize" though. The collapse/maximize buttons are unnecessary because I tend to either have several views/editors open or have one view/editor prominent. So double clicking on the editor/view tab is enough for me. I like the >> at the right side with the pop-up editor list; I liked the editor list incarnation in the last development cycle and missed it since. I can see the concerns of the "does not look native crowd". Personally, I like the current design better than the "native look" stems from using Win 98 at the moment ,) @@@@ On the "votes" topic, I think the results speak for themselves. One has to remember one thing about voting though: People happy with a state are far less likely to vote/speak up than people not happy with a state. I've been playing around with a patch that brings back some of the nice
features of the old style:
- tab compression instead of making them invisible (mostly useful for editing
>6 files at a time)
- left/right scrolling of tabs instead of the chevron/dropdown when they can't
be compressed any further
- plain old square looking tabs with subdued colors
- nice behavior on click, double click, right click
- no option for single editor tab
- thin borders and shadows around views
but keeps some of the features of the new style:
- fastviews dockable anywhere
- floating view windows
However I haven't figured out how to:
- bring back the view title bars and
- get rid of the view tabs if there is only one view on a particular stack.
Anybody know what classes control (or used to control) that?
Also I'm not sure if this is the best way to go or if it would be better to
try and make CTabFolder use the native tabs. This is somewhat appealing
because it would be an evolution and improvement over 2.1, however CTabFolder
has an ever growing list of methods that would have to be reimplemented (To
make the patch manageable, it would be nice if a CTabFolder variant were
binary compatible so its consumers wouldn't have to change). Also there's the
question of how or if to implement the the close button. Any opinions and help
on this would be appreciated.
The editor list drop-down is annoying. Here is a scenario: 1) Click on a field in the outline. 2) You want to do incremental search (CTRL+K) to find uses of the field throught your file. 3) So, you need to get keyboard focus to the editpart, without changing StyledText's selection range. The way this is done is clicking the mouse on the editor's tab. But this annoying dropdown list pops up and you have to dismiss it somehow without changing selection in the editor. The tab's function is overloaded. randy (and others..), specific bugs should be logged as such. (please?) Randy Hudson rightly pointed out that instead of a patch the work being done for bug 53673 will break out the presentation (look and feel) of the workbench into a separate package, maybe even a seperate plug-in, allowing anyone to swap in a new one. For example there's a sample presentation that includes a native look and feel. I recommend everybody on this bug read the new one especially bug 53673 comment #3. It looks like Chris, Stefan, and Nick have been going great guns on that new API over the last 4 or 5 days so that's definitely the way to go. Ed, to clarify what we're doing in the presentations enhancement described in bug 53673, our priority is on enabling RCP applications to provide their own tailored look and feel to how views and editors are presented in the UI, if they need to. There will be an appropriate default presentation, so this extra flexibility will not come at the cost of an increased barrier to entry or learning curve for app developers. Our primary goal is to address the concerns voiced in bug 52892 (L&F for non-IDE apps). While opening this up to allow different presentations in the IDE is an interesting possibility, this is not a priority for us for 3.0. This would require more work, and we are already crunched for our feature freeze at M8. Nick, That may have been the intent but look at the screenshot taken with your Native presentation (bug 53673 comment #41). There are some bugs with it (swoosh at the top is still there, can't drag views, editors don't show the filename on the tab) but you guys did such a great job with it that it already looks better in my opinion than either the old or new looks. Maybe someone with Linux or MacOS can build a version and take a screenshot to see what it looks like there. In light of this I would argue that the Native presentation should be fleshed out and made the default presentation for *both* the IDE and RCP, and that an extension point interface be provided to allow someone to swap out the presentation for both the IDE and RCP. Ideally there would be three presentations provided in the SDK, in order of decreasing priority (again, in my opinion): - Native presentation - Classic emulated presentation (2.1 squared look with view title bars, shadows) - Newlook emulated presentation (curvy look with swoosh at the top, chevrons, no view title bars) Nice job! Ed, Flattery would normally get you everywhere, but not this late in the cycle <g>. While your suggestions are sound, it will involve a non-trivial amount of engineering to make this real (see my comments in bug 53673 comment #45), and, unfortunately, we don't have the time to do it for 3.0. Bug 54857 was opened to track issues with the experimental native presentation. A few things I'd like to comment on. First: the new look in the latest integration stream release is a vast improvement over the 3.0. M7 release look. Great job! However, I don't like the close buttons as much as in the M7 look. In M7, if you remember, there was a yellow shaded outline over the close 'X' everytime you moused over it. In the latest release, it simply fills in the 'X' with brownish red yuck. I'd like it if you went back to the old 'X' overlay on mouse over. My second comment is a much bigger change: In my humble opinion, if we're going to emulate, let's emulate a little more. Specifically, the toolbars. I'm sure you've all seen Office 2k3, right? Microsoft went to a completely emulated look which, in my opinion, bears a striking resemblence to the new eclipse look. But that asside, I think it's a really cool look mainly because of the emulated toolbars. As it is, the toolbars in eclipse remain native. Nothing wrong with that, mind you, I still think that native is the best way to go. However, they look kind of dorky when contrasted with the slick emulated look of the rounded editor tabs. In other words, you're on the right track, but you've got to go a little further. Can't wait to see what you do next. Sorry for my english... I´m brazilian :) Just one question... Will you change the look and feel of the dialog windows? Or it would remain like that? In my opinion they shoul like the others window xp dialogs... native and whith theme support... :) I think that you should do something like VisualStudio.NET AutoHide Feature for views. It is like fast views but you don;t have to do the extra click and also the auto hide views pop up automatically when there is important information to show. I agree with pkor. And i would still like to be possible to add these bars to more then one site. It is allready an improvement that it can be placed at left,right and bottom. Now an option to have a bar on the left right and the bottom would be cool :) re: comment #85 , you are probably not running with the manifest file. see other comments. see also Bug 4789 re comment #85, bug 53859 "Eclipse on Windows XP should use the latest native control set." tracks all issues related to getting XP dialogs to look right without requiring the user to add their own manifest to the JRE. Created attachment 8905 [details]
tabs in dark blue
I find that dark colors make the tabs look better in the absense of
anti-aliasing.
The foreground color also alters the outline around the inside of the close X
which creates a funny effect when the foreground is white.
marking as fixed as 37997 is also |