Community
Participate
Working Groups
Evolve the Eclipse user experience. Eclipse 3.0 should have a new look that makes more effective use of the capabilities of current desktop computers. This includes allowing the user to customize the workbench by creating floating toolbars and views, and supporting tear-off views and dockable toolbars where supported by the underlying window system. [Platform UI, JDT UI, SWT] [Theme: User experience]
See bug 8886 for comments.
Here are my comments from platform-ui-dev. They are regarding improved view management/functionality: GEF would like to start displaying the palette as a workbench view instead of as a control inside the editor. In the past, we could not do this because most GEF clients have the following requirements: 1) P1 - The Palette "view" must always be visible, or the editor is severely limited in function. (the View cannot be closed or hidden). 2) P1 - Many editors don't make use of the palette, so it must not waste space when not in use. (the View disappears when not in use). 3) P2 - The palette should be tall and skinny 4) P3 - The palette should be near the editor Maybe improvements to view management can meet these requirements. Or, maybe a new type of ActionBar can be introduced that is a vertical toolbar down the left or right side of the editor (similar to "cheat sheets"). Maybe cheatsheets could be implemented as a contribution to such an actionbar. In MS Office, there is a side bar down the right that has multiple modes, such as cheat sheet, style templates, clip art, and I'm sure palette would fit in.
I have some feedback for the new look in 3.0: - The shortcut bar is still using lots of space for what it does. Many users don't use fastviews at all, so its just the empty gray bar. - white toolbars? The rollover highlights on the buttons are invisible because its white-on-white. So you just end up with the shadows. GEF clients were asking us to make our tools palette white background and we got feedback from UCD that we couldn't use white buttons. - Why are inactive views a slight blue color? At first glance, I expected the white view to be inactive, and the blue view to be active. The way that TITLEBAR_BACKGROUND was used in 2.1 to indicate active seems more familiar. - There is a lot of padding around views which is reserved for showing a drop shadow. This makes the sashes harder to grab. We've gone from showing lots of shadows, to just one. why not none :-)?
A minor evolution that I'd like to see. Often I have way too many views open in one stack for the width I've allotted to it. This causes the "tabbar" to have the < > buttons for scrolling the tabs. I'd like to see a button somewhere (ideally, left of the tabs, and not 'scrollable'). Clicking on this button would give you a popup menu with all the views available. This would allow you to have two click access to any view, and you wouldn't have to know "is it to the right, or to the left".
NOTE: in order to use try out the current prototype, you need to replace some of the existing jars with new version of them. You might also want to back them up in case you want to switch back. 1) replace \eclipse\plugins\org.eclipse.jface_3.0.0\jface.jar with: \eclipse\plugins\org.eclipse.jface_3.0.0\jface-new.jar 2) replace \eclipse\plugins\org.eclipse.ui.workbench_3.0.0\workbench.jar with: \eclipse\plugins\org.eclipse.ui.workbench_3.0.0\workbench-new.jar 3) replace \eclipse\plugins\org.eclipse.ui.workbench.texteditor_3.0.0\texteditor.jar with: \eclipse\plugins\org.eclipse.ui.workbench_3.0.0\texteditor-new.jar
Why no auto hide feature like Intellij or VS.NET? The fast view is useless IMHO.
I like the new interface. The perspective bar on the left side was taking space away, without gaving anything usefull. However I do have some comments about this new UI. 1. Openning new editors, only the last one is show in the tab, when there is enourmous space is there empty. 2. I like the dropdown to show all editors, when the tab is clicked. But the menu on the right hand side (click the >), is useless, the list of the editors is outside of the Eclipse window. 3. Openning the a new file from the package explorer cause a very visible flash. It took me a while to figure it out, but I think the old color scheme was better for the eye. The current one has to much contrast (Selected is yellow, unselected is blue). The old one (Selected was a progression/gradient between blue and gray, unselected is gray) was more soothing to the eye. Selecting the view is slower then in the old mode. 4. The buttons for the perspective bar are oversized. I think the original size should be fine.
Using the prototype, I've found one problem, you cannot drag an editor to create a "split screen" - at least on OS X. I also have a suggestion for the selection of the current editor when multiple are available. When you click on the editor tab, a file selection appears. This is nice until you double click the editor tab to make the editor maximized and the file selection briefly draws and then disappears. It might be nice if a pull-down icon were avaiilable in the editor tab to activate the file list to avoid this "flashing" problem.
Looking at the new interface preview in M6 I have a few preliminary comments. 1. The rounded tabs look nice and it's also nice not to duplicate the view name at the top of the window (in the title) and at the bottom of the window (in the tab stack). However, it's not very Windows-like, at least not like the apps I'm used to. For RCP we need to make applications that are indistinguishable from C++/C# programs. It reminds me of Photoshop, but not much else. 2. Some of the icons are not easily readable on the blue background of an inactive view. 3. Some view toolbars are taller than others, for example the Hierarchy view toolbar is taller than the Package Explorer view toolbar. This makes it more jarring when switching between them. 4. I don't like the close (X) being way over to the right. Maybe I'll get used to it, but it seems more natural to put it next to the tab title or perhaps on the toolbar. For tear-off stacks, it doesn't close the whole stack, just the top view, which is wierd given its current location. 5. There needs to be a tab for each open file, not one little tab in the middle for just the active file. 6. When you click on the editor tab for the active file it pops up a menu. That was really unexpected. I was trying to double-click it to maximize it but that didn't work. 7. There are some extra pixels all the way around views and editors that change color to indicate activeness, plus a shadow that comes and goes. This is taking too much space. 8. Tear off views - very nice! However you can't move a view again to arbitrary places on the screen once it's torn off (you get the X cursor unless you move your cursor over an Eclipse window). 9. The new perspective buttons take up way too much room. May I suggest just putting them into a coolbar like everything else? It would be nice to be able to dock toolbars horizontally or vertically too so if I wanted I could put the perspectives down the side like before.
The big advantage (IMHO) of the Eclipse platform was that it looked like a platform application, that is a Windows application in my case. The new look destroys this. The rounded tabs don't fit the otherwise square W2K look. Therefore the look Eclipse looks alien (and ugly IMHO). The perspective buttons have a text which makes them taller than all other toolbar buttons. This makes the toolbar taller and wastes screen real estate. Especially the "Open a Perspective" button looks lost - a tiny button on a large toolbar, left alone by all other toolbar buttons... I dislike that the new editor hasn't multiple tabs anymore. It also seems that I cannot D&D the last remaining tab anymore, creating a split screen for example. The button to display an editor list is a good improvement but why doesn't it have the same icon that the other toolbar-menu buttons, that is an arrow pointing down. Now, the arrow pointing right looks like a scroll button. The new workbench feels much slower on my computer - it might be because any time I click a different view, the dark (and ugly) view shadow border is removed from the old view and redrawn on the new view. I dislike that active views are drawn white (in active ones are drawn dark gray as are inactive title window bars in my windows look) instead of using the active title window bar color. Especially white toolbars not only look ugly IMHO but its also much more difficult to tell if a button is raised or pressed and because toggle buttons still have a gray background, they look alien. The red glow of the white close button (which doesn't look like a button) is a nice effect but completely non-Windows. I'd prefer if that button would look like a Windows close button has to look (replace Windows with your favorite platform) If I open all available perspectives the toolbar starts to display multiple lines of toolbars - well... however, if I resize the workbench window, I can make all buttons invisible, pushing them out of the window. The perspective toolbar should perhaps also wrap and shouldn't waste screen real estate but staying in one line. Additionally, I dislike that buttons have different sizes based on the title text. "Java" is smaller than "Java...sing" I miss the border lines in the workbench's status line. Because an active view has a black shadow border, it's a bit larger than an inactive view and the workbench looks as if the views are misaligned.
Using the GTK2 version of Eclipse 3.0M6: After you tear off the view, the "Close" button on the window manager no longer works. If you want to close the view you have to use the 'X' button on the view itself. I believe that most users would expect both the view's 'X' button and the window manager's 'X' button to close the view. I'm also not sure about only ever having one tab in the editor view. I can see the advantage to focusing on one file at a time, but I miss the quick tabbed access to multiple files. Perhaps some sort of compromise can the reached. The 3 or 4 most recently used files could always be kept as tabs in the editor pane, allowing developers to switch from one to another quickly. Pressing the '>' button would allow users to access the same drop down menu as now. I don't know if this is connected, but once I move a view, I can never move it back to a full length setting again. For example: In the Java perspective, the Package explorer tab stretches the entire height of the left of the eclipse screen. If I move the package explorer, to the right and then try and redock at the left using the same configuration, it seems impossible. Either it will only be as tall as the editor pane or as tall as the problems pane.
My initial reaction on seeing it in the new features list? A sinking feeling... I gave it a try anyway. It took me no longer than 5 minutes to revert. Please remember that Eclipse is a _tool_ platform. It is used to work as efficiently as possible, not to look at eye-candy. What is appropriate for a CD player, is not so for and IDE. I want the maximum use of screen real estate. As it is Eclipse has a multitude of views that have to be juggled so as to allow a reasonable ammount of the source code to remain visible while still providing access to often used tool views. This new look takes space away from that. And for what? "Better" looking toolbars, etc. If the Eclipse LAF really must go in this direction, please at least preserve and maintain the current LAF as an option! But to not be completely negative, I do like being able to click on the editor title bar to get the open editors pop-up. What I would prefer is this feature combined with the current policy of showing multiple editor title bars but with this change: show the LRU editors such that the full name of each file is always visible in its title bar (show as many as can fit with this restriction). The tear off windows? They don't bother me, but I would never use them. Since Eclipse always needs to run maximized (see second paragraph) where would I put them? If I were to use multiple monitors, perhaps...
I agree with the other comments: space should not be wasted. - The tabs on top of views are nice, because the title does not "waste" any space of the toolbarbuttons. - The editor menu needs some work (it falls outside the screen (on windows XP) and hides below the windows taskbar (I have it on the right side of the screen)) - The perspective icons take way too much space. I have 10 perspectives open and if I use it at low resolution (e.g. laptop with 800x600) I get 5(!) toolbar rows on top of each other taking a lot of space. - The space on the left for the fast views is wasted if there are no fast views. - On XP with the default colors, using blue for inactive and yellow for active is totally counter intuitive (for me). At least on windows, blue indicates focus (I think). I think it is probably very difficult to get a nice custom design that looks "cool" on all platforms. The solution would probably be a kind of "skins" for each GUI. Things that look really cool on XP look strange on Win2K or the Mac. It is hard (if not impossible) to be consistently "cool" in a platform independent way. From an aesthetic point of view, I simply don't like the current preview (at least not on win XP/2000).... A nice example for a cool look is "Adobe® Photoshop® Album" http://www.adobe.com/products/photoshopalbum/overview.html http://www.chip.de/ii/17356126_1038ae9e67.jpg It also wastes some space but it has a nice consistent look. The look is obvoiusly "optimized" for windows XP, but I like its aesthetics (they use subtile aliased color grades and curves in a nice way). In the new eclipse look, the curved line between the toolbars it not anti-aliased and looks very ugly and unprofessionel. (I understand that this is a preview and It was probably not worth to fix this)
More comments... I too tried it for about five minutes before reverting. Initial impact: Very positive. However, I'm using it on MacOS X, and the implementation on this platform is a long way from visually pleasing; too many areas where 'OS X' look is bleeding through into 'Eclipse look', most often around widget backgrounds and coloring - no doubt trivial to fix, but jarring nonetheless. There are elements I find useful: The removal of the left-hand nav into a separately-provisioned section on the nav bar is a good thing. Sticking the 'add perspective' icon on the wrong side of that division didn't strike me as a great thing, OTOH. And at least on the Mac, I wasn't fond of the toolbar taking up that much room - I'd like to see all of the icons on that bar kept at minimal size (no doubt another MacOS/X specific bug- I can't believe that's the intended results). I'm less happy about seeing some of the other things go non-platform-happy. - I like tabbed editor panes. If you want the ability to alt-click on the title and select a different file for that tab, and enforce a 'tab limit' on the number of tabs, that would be a good thing. But please bring back multiples, if only because it doesn't make an awful lot of sense to have that tab bar look like a single tab. - *ALTERNATELY*, if you're dumping the tabbed interface, stop having it look like a tab at all, and offer row/column/status information in a top-row title area that spans the entire width, and not a tab sitting in the middle of the window area (no doubt another mac-specific UI bug.) I would be more willing to live without tabbed interfaces *if* you stopped making it look like it's a tabbed interface, and put that area to some use. - While I'm happy to see the ability to use more screen real-estate (I cajoled all my developers long ago into multiple screens) I'm disappointed to see that you still haven't fixed the critical UI bugs around actually *USING* multiple screens under the current implementation... What's the point of supporting the extra real estate if panels still pop up spanning two screens by default? :) (Bugs already filed) My point being: Either make the fundamental changes needed to get multi-screen usage working as a priority, and *start using it yourselves*, or focus more on single-screen use and clear up some of the wasted real estate in the new UI. - Please consider what's going to happen, now that you're officially adding support for SWT+Swing UI, once the Swing look and feel shows up inside SWT. Either consider the possibility of providing an 'SWT' look and feel, or stick, as much as is humanly possible, to platform native UI. While I'm less concerned about this at the toolbar/coolbar UI leve, I'm more concerned about it elsewhere.
Can a batch file or some action be provided to quickly switch to this new UI instead of having to manually replace the files?
After looking through it for a few minutes, I reverted back as well. There is just too much space wasted on the screen, the left area is totally unallocated, something has to go there. Though the perspectives on the upper right is a nice change, the fact that it takes up two tool bar rows especially when I only need one is a bit much. If it spilled through the menu it may be better. I think I still prefer that the UI uses the ones provided by the OS instead of creating new widgets and colour schemes. I didn't like the fact that when a view set loses focus it changes colors on the currently focused one, I'd rather it look inactive like the rest of the windows). Also the text editor only has one tab at a time which may be a bug.
Looks like a can of worms has been opened. Anyway, I think most of these comments are too detailed. At this point, you should probably limit your comments to high-level issues like the use of rounded edges, placement of elements on the screen, use of color, and changes in function (like no longer being able to see multiple editor tabs). We should all assume: 1) Anything that was possible in 2.1 will still be possible (side-by-side editors for example) 2) Bugs will get fixed. (popup placement, etc.) 3) fine tuning has not even begun. I think it's great to see a lively discussion, but let's leep in tune with the current stage of developement. It's starting to look like there's no pleasing everyone. What about making WorkbenchWindow's layout mechanism, EditorPane, ViewPane, CTabFolder2, and some other L&F code swappable using an extension point?
Created attachment 7266 [details] UI mockup
I would say that making the perspective icons this big is a mistake, since they definitely take up more space than is warranted. The increase in size is caused by the addition of text labels, yet it doesn't succeed very well: On Randy's attachment the label on the "Team...zing" perspective is clearly too big to fit on the icon. Moreover, most developers who use Eclipse have long since come to remember the various perspective icons visually (at least the ones used on a regular basis), and do not need the additional que provided by the label. For those who are not yet familiar with the perspective icons, a tool tip popup is a sufficient mechanism to get acquainted with them without need to take up valuable screen space. I would suggest that perspective icons are stripped of their labels, and placed on the right side of the workbench application menu bar (the one with "File, Edit, etc...") with the "open new perspective" button fixed to the right-most edge of the screen, and new perspective icons appearing to the left of it. This move should allow the main toolbar to fit reasonably well into a single row, thus saving screen real estate for more frequently used tasks. Multiple tabs *need* to come back, they're great if you're working with a relatively small set of files, since in the case where all activa tabs fit on one screen with no scrolling, this provides one-click access to any of the documents being worked on. This is especially a good idea since the space that would otherwise be used by these tabs is currently left unoccupied on the mockup.
Adding my two bits to the comments that others have already put forward: Overall, I think the new UI looks great. There's a lot of cleanup compared to the current UI, and I think it's going to be a nice improvement on an already great environment. I very much like the idea of moving the perspectives to the top of the screen. I frequently find that getting enough horizontal space available for my editors to be difficult on my small laptop screen; getting that extra couple of columns from getting rid of the perspective bar on the left is terrific. However, I'd like the *option* of having the perspective buttons be smaller. On the plus side, one of the complaints that I've heard from some users of Eclipse R1 and R2 is that the perspective buttons are too small, and too hard to distinguish for something that has such an impact on the environment. So making them bigger, and labelling them with text really helps with that issue. But on the other hand, in my endless quest for screen real-estate, I can move toolbars around so that all the toolbar buttons are on one row - but the perspectives still takes two rows, and I'm stuck with a big blank chunk of space between the toolbar and the views. I'd like to be able to turn off the text on the perspectives and get back that space. As someone else mentioned: I do *not* like the single editor tab change. I tend to have a lot of editors open, and it's nice to be able to see them without having to do a UI gesture. And as it stands, it also wastes a huge amount of screen space. In the old UI, the whole tab area of the editor was used to show tabs for open editors - now most of it is just blank. The drop-menu list of editors is great when you have a lot of open editors - but a lot of the time, using it is more effort that it should be - I can't switch editors nearly as quickly or as easily using the new UI as I could by clicking a tab on the old one. I also very much miss the ability to drag an editor tab in order to create a split screen edit. In fact, I consider this so important that I'm continuing to use the old UI, because I simply can't live without it. *Please*, *Please*, re-introduce split screen editing! (If this is a bug and not a feature, please let me know, and I'll file a bug report on it.)
sorry for the duplicate comment, but plz get rid of the rounded tabs. A great strength of SWT is it's consistency with L&F of the underlaying OS. This design is disturbing this experience. If SWT has teached us anything it is that L&F is the concern of the underlaying platform, not on the widget toolkit level, and certainly not on workbench level.
<rant> This must be stopped: vast swaths of wasted space! Big menu bars, big icons and acres of grey grey grey with nothing in it! When I switched from InteliJ I immediately noticed how much wasted space Eclipse had, and now I see more. I'll even do the math. Let's take the screen shot at http://download2.eclipse.org/downloads/drops/S-3.0M6-200312182000/eclipse-news- part1-M6.html. I've measured the usable white-space vs. the unusable grey- space (including the *ample* space taken by icons). My rough measurements follow: Navigator view's usable white space: 4x5cm = 20cm^2 Editor: 6x6.5cm = 39cm^2 Total usable space for lists/editing: 59cm^2. Entire window: 9x12cm = 108cm^2 Usability index: 54.6%, or 45.4% of the space wasted on large icons and dead grey space. I know I'm not using a completely scientific process here, and that a larger window would have a higher usability index, but consider the following from the Navigator window, again from the screenshot: Note that the scroll bar has about 2cm worth of "scrolling" to do to view the unseen items. Now notice that from the top of the "New Look" icon to the bottom of the "Edit" menu item is about 2.5cm. If the Navigator were capable of utilizing the space taken up by it's large Tab, and the dead area where the Save, Print, etc. icons live, we would not need to scroll that Navigator window much, if at all. Seriously, step back an look at the amount of blank grey space, especially the icon line containing Save, Print, ..., and extending to the Perspectives: those icons are swimming in a sea of unused space. In the area available between the top of the Navigator Tab and the bottom of the Edit menu item you could easily stack 3.5 Save icons vs. the 1 that is there now. Chop that extra space out and give it to the Navigator tab so I don't have to scroll so much! Recommendation: Please implement a "power-user" efficient, space-saving mode, similar to how IE and other web browsers allow small-icon-only views. </rant>
Created attachment 7274 [details] picture showing toolbar heights Mark C, Comment 20, are you actually referring to the new look? > getting rid of the perspective bar on the left is terrific There bar is still there. In case I confused some, the attachment I made was my *OWN* mockup and does not reflect the current code or the direction being taken by the workbench team. If you enable XP look and feel, the height of a toolbar depends on whether a toolbaritem with the DOWN triangle exists. Drop down buttons like the Run... action require 8 pixels more vertically. But I would guess that most eclipse users either don't have the required manifest file, or have reverted to the classic windows L&F.
If the Eclipse LAF really must go in this direction, please at least preserve and maintain the current LAF as an option! ( Please !!!!!!!) I repeat this .....
One feature of the new design I do like is the dropdown on the editor tab which allows me to easily select from a list of editors or even use a type ahead feature to find the editor I'd like work with. While I do miss the editor tabs as others have mentioned, being able quickly identify and select from a list all editors is IMHO an important feature. I confess to using the steps in bug 31564 to add the old drop down everytime I download a milestone release and will be grateful to be rid of this extra step.
The new GUI looks like it was lifted straight out of Mozilla/Netscape 7. While this curvy look is fine for a browser, it's distracting in an IDE. The user's focus should be drawn to what is inside the frames and editor windows, since that is where the work is done. These stylized widgets draw too much attention to themselves, hindering a user's attempt to concentrate on his or her code, package trees, etc. There is nothing wrong with the look of the SWT widget set in Eclipse 2.1. I hate to sound like a cliche, but if it ain't broke, don't fix it. At the very least, we should have the option to switch back to the current look and feel if that is our preference.
I don't favor the use of yellow in the view tabs. The existing tabs clearly indicate which view is selected without drawing the eye away from the content of the view. BTW, I always have my view tabs display on the bottom of the view--not the top. I'd like to be able to tear off editors as well as views. I like to keep the editor maximized on my primary display whereas workbench window provides nice features for laying out the various views and could help me organize them on a second display. See also: bug 20095 [Editor Mgmt] Open editor in new window bug 46565 [EditorMgmt] Move an editor pane to another Window bug 49440 a perspective should be able to prevent editors from opening bug 49439 [editor mgmt] need a show/hide editor button near pin editor
I'm going to sound like a broken record of a lot of the other comments but here goes. First off I'm all for UI/usability improvements but most of the visual changes here are not improvements to me. One of my first impressions of Eclipse was rejoice at finally seeing a Java based IDE that looked and felt like a native application (Windows 2K in my case) instead of another godawful ugly non-platform standard Swing application. As others have noted this preview breaks the native paradigm in all sorts of ways. While there may be strong motivations for the non-standard elements (new tab shapes, weird split toolbar, non-standard window controls on the tab bar) the first thing I judge an app's UI by is whether it's professional and consistent with all the other apps I use. The current Eclipse UI passes that test, the new one doesn't, not even remotely. Within the constraint of consistency I'm happy to see cool features and creativity but overall I still want it to look and feel like a native application. Miscellaneous: positive - moving the perspectives to the tool bar area negative - the loss of visual definition to the toolbars and the size of the toolbars negative - the loss of visual definition to the status bar, I prefer the current status bar with it's recessed trays for different pieces of information negative - placement of the close tab control. As others have noted if it closes the current tab it should be visually associated with the current tab. My visual expectation with the current placement is that it closes the entire set of views at that location on the screen. negative - the right arrow for the menu, as noted earlier it looks like a scroll control of some sort instead of a menu button negative - the dead space for fast views, I agree with some of the other posts, if I'm not using fast views (which I don't) I don't want the empty space strongly negative - the single editor tab I find Randy's mock-up MUCH more visually appealing, though I still think the tab controls look misplaced, don't like the look of the toolbars (too big, no visual definition to separate them from the rest of the screen) and I also miss the lines separating out the status bar (looks just like text randomly placed on the body of the window) In closing add my name to the plea that if Eclipse is no longer going to look like a native application, please, please at least leave me the option to use the current UI.
Yes some widgets are fake, but some of the complaints about tall toolbars are a result of using *native* widgets. By placing a .manifest file in your eclipse directory, XP skins will be used. With the default skin, The use of DROP_DOWN toolitems (for example, "New", "Debug", etc.) will result in the preferred height being *8* pixels taller than a normal toolbar. This is what is making the coolbars in Eclipse (whether 2.1 or 3.0) huge.
Is there a possibility to vote _against_ a Bug report? :-) Anyways - just adding myself to the list of those being dissapointed by that new direction - if the look really needs to be changed, please at least: * do not waste space * make it look native Randy's proposal looks by far better than the prototype in M6. BTW: rounded edges without anti-aliasing _really_ look ugly.
I just looked at the picture in New In M6 and reverted. ;-} 1. Eclipse should look like other applications on the same platform. The world doesn't need another Motif. 2. Nested tabs should be discouraged. The analogy breaks down pretty quickly for more than one level of tab. A realistic perspective in this format would have four levels! No. 3. Wasted space, etc. etc. If you want to improve the GUI: 1. As Randy Hudson has been saying for ages, get rid of those perspective icons on the left side. Randy's picture looks better, except the icons don't need to be so damn big. The truly naive user is going to work in one perspective only and won't need to see them at all. Others will be able to find them if they are standard-size icons in the toolbar. Give them pride of place on the right, if you must. 2. Pour honey in the engines of all those who would switch perspectives automatically (vs. user request) like Team in M6. If perspectives aren't going to be under user control, I say get rid of them altogether.
I'll throw in my 2 cents as well. This issue fixes -THE- most annoying feature not in eclipse. I'm used to (on my 2 monitor dev box) to float the package explorers in the left monitor and have the editor take up the whole right one. This is now possible as I can float views (as you can in IntelliJ for example). This was a must have for me and I'm glad someone took the time to implement it! On Linux (gtk) I'm not too concerned about the space waste, but it might just be less than on windows. The curves are rough though when there is no anti-aliasing, but I like the shadow effect added to frames/windows. The rounded tabs are nice and again I don't see too much space wasting.
Notice in comment 18, the attachment shows how a view's toolbar might be placed using the same horizontal row as the stacked view tabs. This addresses the extra row which is always introduced when stacking 2 or more views. For views with few actions, I think this would reclaim a lot of space.
I didn't notice that the first time. That kind of design would let editors have toolbars too (something that always bothered me about editors). Now if your mockup had the following features I'd like it a lot: - smaller perspective buttons (just another coolbar) - multiple tabs for multiple editors - move the view and editor close buttons to their tabs instead of on the right - change the icon for the view/editor close buttons to be more native looking (IE uses solid black for that). - remove the "iconify" looking view/editor buttons (the "-" next to "x") - make an editor toolbar area on the far right that houses the button for the editor list dropdown - coolbar style for the top menu like internet explorer - optional toolbar titles like IE and Xp's docking window. For example they could have titles like "Perspectives", "Search", etc..
Created attachment 7334 [details] a screenshot of Macromedia's DreamWeaver DreamWeaver has a nice UI with elements similar to views and editors, but with some interesting twists. Developers unfamiliar with the product might find that playing with a trial would be a helpful diversion. To my way of thinking, evolving the user experience is secondarily about the eye candy and primarily about new UI features. I'd rather not see the Eclipse team invest energy in changes to the UI unless those changes significantly alter how I interact with Eclipse.
Rounded edges look ugly *with* or *without* anti-aliasing. Eclipse is not a toy. Maximum conformance with the native look and feel was (and still is!) a very good idea. I think the sash should be thinner with at least two pixels. Yes, getting rid of the perspective icons would be nice (a simple submenu "Windows/Active perspectives" would be OK for switching).
Just my two cents: Some time ago a lot of effort was made to force SWT to use native widgets where possible (e.g. on GTK). Now it seems that effort is made to create custom widgets (e.g. rounded tabs) It is absolutly ok to have support for window systems which allow customized widgets using themes and styles. Eclipse should support this to allow a smoth integration into the OS environment (native look and feel). But Eclipse must honor the current setting and native defaults. No custom widgets should be introduced (e.g. rounded tabs). Instead themed widgets should be used if enabled by the underlying window system. According to the initial comment, "User experience" should be interpreted as support for advanced concepts like "floating toolbars and views" and support for "tear-off views and dockable toolbar". I fully support this and I fully support usability enhancements but I don't support violations of the SWT nature (native look and feel) introduced due to eye candy gimmicks. BTW, icon text in toolbars on my OS (Windows 2000) painted right to the icon and not below. This may be another violation of native look and feel rules.
Just noticed in Internet Explorer that it is possible to hide or show icon text below or right of the icon. So I have to revise my last comment a little bit. I'd also like to see support for new widgets and elements in SWT and JFace like introduced in modern applications like Office XP or 2003 (e.g. dialogs are replaced by embedder window elements with forms like (flat) style).
I just switched to the new look on Mac OS X. Here is a list of first problems, impressions, and issues. What I like: - the new close icon for view and editor parts Problems: - vertical perspective bar initially not visible. I had to temporarily "pin" a fastview to make it visible. This happens whenever I start Eclipse. - curved lines are not really curved (see attachment 4 [details]) - background colors are not coordinated (see attachment 5 [details]); - the editor drop down changes focus, which deactivates the editor window and empties the menubar. All this together results in severe flashing and makes editor switching a heavy operation (a PR already exists). - lines don't have consistent width and color because some are drawn between pixel coordinates which results in two-pixel wide grey lines under anti-aliasing. Impressions/Issues: - inconsistency w.r.t. visual borders: for status line items a gradient fill is used to make the field stand up against its background. This is a good way to remove visual line clutter and it makes efficient use of space because no additional borders space is required. In other areas lines are used. Some with a 3d-effect (active views and editors), some without (view and editor parts). So the overall impression is still dominated by lines. Wouldn't it be possible to rely just on fill colors and shadows and eliminate most lines? - too much wasted space: on MacOS X the default font is rather large. As a consequence, old-look Eclipse on MacOS X doesn't make good use of available space. The new look does not improve on that. Lots of (vertical) space doesn't seem to be used optimally. One example is the space below the toolbar. On Mac OS X the native look of toolbar items is very similar to the perspective icons on the right hand side of the toolbar (icon vertically stacked on top of label). The toolbar items on the left hand side don't even try to use that space to become consistent with the icons on the right hand side. However, to avoid the wasted space it would make more sense to remove the labels below the perspective icons so that left and right side of the toolbar would have the same vertically size. - one argument for SWT was always that it makes use of the native platform look & feel so that an application feels "native" (and not ported from another platform). On Mac OS X we've never achieved this completely because Eclipse was already using too many custom widgets that didn't adapt to the platform, but just had a hardwired look mostly tuned towards Windows (e.g. editors tabs, ViewForms, CoolBars). As long as their look was low-profile (e.g. like the editor tabs), this was acceptable under Aqua. But with the new look some custom widgets have become much more prominent and "collide" with the native look: the curvy line in the toolbar or the new tabs don't harmonize with Aqua elements.
Created attachment 7458 [details] Curved lines
Created attachment 7459 [details] Background color problems
I haven't read all the comments in this PR so the might be some duplication: - using the new look under Windows XP with default blue theme causes irritation regarding which view part has focus. The one having focus is rendered with a light yellow tool bar and all the other with a blue one. - having the close box at the bottom if the tabs are rendered at the bottom is strange as well. I have never seen a tool showing a close box at the lower right corner. - rendering a border around the view part in focus gives the impression of size changes on focus changes. Additionally you get the impression that the sash between to view parts is jumping. Cause irretation as well. Chaning focus should only cause a noticable but minor change in the UI. - having the perspecitive icons "integrated" into the toolbar wastes vertical space. Additionally the toolbar looks strange. - I would prefer having flat lines between the main working area (the one containing the editor and views) and the status line and fast biew bar. Attached a screen shot showing the Eclipse under Windows XP Blue theme.
Created attachment 7475 [details] Screen shot of Eclipse under Windows XP Blue Theme
I am using the classic theme on windows XP and get very distracted by this new look since it looks like an "enemy" besides all other applications.
NOTE: as an update to comment #5, there is a fourth jar to rename NOTE: in order to use try out the current prototype, you need to replace some of the existing jars with new version of them. You might also want to back them up in case you want to switch back. 1) replace \eclipse\plugins\org.eclipse.jface_3.0.0\jface.jar with: \eclipse\plugins\org.eclipse.jface_3.0.0\jface-new.jar 2) replace \eclipse\plugins\org.eclipse.ui.workbench_3.0.0\workbench.jar with: \eclipse\plugins\org.eclipse.ui.workbench_3.0.0\workbench-new.jar 3) replace \eclipse\plugins\org.eclipse.ui.workbench.texteditor_3.0.0\texteditor.jar with: \eclipse\plugins\org.eclipse.ui.workbench_3.0.0\texteditor-new.jar 4) replace \eclipse\plugins\org.eclipse.ui.ide_3.0.0\ide.jar with: \eclipse\plugins\org.eclipse.ui.ide_3.0.0\ide-new.jar
Where do we find ide-new.jar? It didn't come in my M6 download.
this file is not in the m6 build. it is in integration builds after jan 20.
I cannot find where the download is to get the new look. Obviously the rest of you have found it so could you give me a leg up? I'd deffinately apreciate it. Daniel
Created attachment 7518 [details] Screenshot of the upcoming MySQL Admin Tool I attached a screenshot of a new, official upcomeing MySQL administration tool. IMHO this is a good example of how a well design tool should look like under Windows XP. It provides a clean area and uses available OS widgets to demonstrate a clean and intuitive look and feel. Pay attention to the tabs. I like them. :) I expect Eclipse to reuse more of the available OS widgets to get as close as possible to a native look and feel demeonstrated in this screenshot.
Created attachment 7519 [details] Screenshot of new look using gray background When designing and creating a new look you should also be aware that not everybody uses a white background. This might lead to ugly looking combinations when using self defined colors and not system suggestions.
As an addemdum to my comment #50: The gray background is defined only once in the OS display settings and I do not want to adjust colors in any application I use again because every information is already defined in the OS. Another problem I see is that you guys are creating a new look. Please keep the ideas behind SWT in your mind. I like the new editor tabs drop down but I do want other tabs to be visible, too. I can't switch quickly between to editors by a single click any more. The drop down icon should be displayed next to the close button. IMHO this is a common feature which should be also made available in other view areas where the space for tabs may be limited, too.
Daniel S. Please see comment #45 for how to get the new look. The jars are in the builds already
Created attachment 7538 [details] A screenshot of the new Eclipse look on GTK linux As you can see, this is really tacky. I mean, if we are going to go native, let's go native. If we're going to s-wing it (pun intended), then let's wing it. But if we try to meet halfway, then we've got to be a lot more careful. It looks to me that the new look would look great on a Windows XP machine with the proper manifest installed. However, you're overriding the native widgets and replacing them with custom color sets, slugish widgets, and loosing all of my fast views. (package explorer is half visible). Don't get me wrong, I'm all for revamping the Eclipse look. However, let's try to remain true to what we've done before. Not in look, but in concept. I was drawn to Eclipse only because it used native widgets (SWT). Once I got past the novelty (or lack thereof), it was the unique (and well coordinated) ballance of native and custom widgets that kept me. I will be the first to say it: You guys did a great job designing the initial interface. Let's try to top that, shall we? One final thought. As I don't exist solely to test run new Eclipse stuff (though that would be a great job), I have switched back too the old look. The attached image is rather self explanitory of why. Do two things, though, and you'll make it much more liveable. First: Don't invent your own color scheme. It looks great on XP, but it's a no-no on GTK. Second: As much as the new position of the fast view and perspective change bar is more ergonomic, it looses all my fast views due to space constraints. But, you guys are on the right track (I think). Keep up the good work!
My 0,2c: The behaviour should be customizeable. Eclipse should, by default, stick to the native look and feel, but also create a possibility to use a new look and feel on demand. This helps those users who want an unique eclipse look across platforms, and those users who don't want that.
Daniel, thanks for the comments, you might want to try M6 or newer as it has changed a bit since your picture attached.
I have tried post-M6 and it is as much worse as better. Instead of showing every view's icon (and there is plenty of horizontal space), only the active view's icon is displayed. This causes the tabs to shift around left/right when I click on them. If at all, tabs should move 1 pixel up and down to simulate depth. There is slight UI bug in the editorpane. SWT sends mouseDoubleClick immediately before the mouseDown (where that mouse down is actually the same press which generated the double click). The mouseDown (or up) in these cases should be ignored since double-click is interpreted as maximize/restore the editorPane. What happens is: if you double click on the "dead" area to toggle maximize, and the drop-down dohicky ends up under the cursor afterwards, the second part of the double-click is causing the drop-down to open.
randy, i'm not sure how 'post-m6' you are, but your editor pane bug should be fixed in the branch (yesterday, i think)
I'd like to see the ability to set a scale factor or some other way of affecting the size of icons in both the new and old ui. While I agree with most people here that you can't afford to waste space in an ide, I'm currently using a laptop with a screen resolution of 1920x1200, and the icons are microscopic at that size.
Waste of space and scalable graphics are in my opinion seperate issues. The support of scalable graphics would be indeed a valueable feature: svg, wvg.
the 'commands' architecture does support binding different images to commands based on the platform. (this is functionality is not yet used by toolbars in the current integration builds.) the purpose of this is to recognize that toolbar icons can(should) look different/larger/smaller on other platforms (the mac, especially). we might also consider binding images by DPI ranges. this is a common technique in skinning systems. also, or in addition to this, scaling is a possibility, but toolbar icons are generally too small to scale well. i have logged feature request 50491 "[CommandMgmt] allow binding images to commands by DPI" to track this.
Created attachment 7558 [details] MS Outlook navigation Perspective navigation is stll really difficult. What do you think about the MS Outlook 2003 navigation? I really like it.
today i am working on implementing a few changes from the designers to help with perspective navigation. its not exactly the outlook bar, but some changes are coming in this area.
Read most of the comments, agree with many. Quit playing with the M6-based new UI peek, just didn't like it enough to test drive (on Win2K). Tried again today with the I20040128 build. Some things look better (perspective nav area smaller, icon only helps). I found the show multiple editor tabs, like that better, it brought out the drop-down for when many editors are shown (like in https://bugs.eclipse.org/bugs/show_bug.cgi?id=31564). Some issues there: - The drop down seemed to disappear at times. When I reduced from full/max window size it was gone. Took a bit to get it back, only figured out how when I found that I could make it disappear in full screen mode as well. - The list of editors that is shown when the drop down is selected is not visible (for me). This is the case when you place your Windows Start/Taskbar on the right side of the screen. Very old bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=12168) said this could not be fixed for hover help. Since the 31564 implementation works very well in 2.1.x, I can't see that being an excuse for this implementation. Another comment - the new hover style view tool bar. It is hard to see at first, not much contrast in a fairly default Windows appearance. They are also two clicks away, you have to move focus to the view to see them, then click on the one you want. In the Hierarchy view they are mixed, the top is hover, the bottom is old-style. I did not see a preference that would allow me to say use old-style task bars, I love more content in my UI as much as anyone, but I've found their use a bit difficult to get comfortable with so far. (Scratch part of the above...) I just played again to try fast view and got confused with two Fast View icons (the push-pin), you need another icon for returning the view tool bar to the view header. Once there it seemed like you were wasting space from top of view tab to start of content. This turns out to be a bit of an optical illusion. When I stacked 2.1.1 and 3.0 side-by-side it was a pixel or two less in height in 3.0. What would be really cool is if the view task bar could float into that grey area to the right of the tabs in the lower view stack (where tasks, problems, properties and the like seem to default ). When room is there, it seems wasted. Always been there, just that the new UI seems to make it more obvious. Note that it did seem hard to get a Fast view created, the drop icon did not show up on first drag several times. One last general comment on the location of preference navigation. Way off to the right seems harder to use. I typically run the mouse to the top left to use what is typically the primary content navigation view (Navigator in Resource perspective, Package Explorer in Java, ...) and then realize I need a new perspective, now I have to run the mouse way to the right to switch. Maybe I'll have to learn to use the key stroke for this (Ctrl+F8) to avoid the mouse bounce. That, or go right hand side for Nav type views in my custom perspective arrangements.... Looks better than my last peek; I'll be interested in seeing what else you might have to offer.
Comments on I20040129: - I like the triange pull down for editors and views--very cool--but I'd prefer it to show all the time, not just when several views or editors are shown. - The pull off views work better than they had, but they are difficult to manage in a dual monitor enironment. What I really want is to be able to have an editor (with the pull down menus) on one monitor and my views on another. Keeping four or five sperate views lined up on my second monitor is very tricky. I miss the docking offered by the main workbench window when manipulating tear-off views. - I am looking forward to seeing what you are going to do with color and also with the perspectives area.
Wow. I can't believe we are seeing the fly-out view toolbars again. From the mailing list, here were some reasons for sticking with regular view toolbars: - There is already a mechanism for reducing UI clutter: the view's drop-down menu. Menus look and are native, and the display the action's name! - A toolbar serves 2 functions. A) it displays the current view *status*, such as toggle enablement (e.g. are static variables displayed). B) it provides quick access to commonly used actions. Flyout toolbars do neither. An extra click in a special location is required in both cases. - Custom toolbar items like Combos require more width and will disrupt the vertical layout. Drop down actions need more width too. - There is no saved space as a result of this change. The view's title and its toolbar are usually on the same row. Even when views are stacked, it is often possible to place the toolbar to the right of the tabs. And some new observations: - The rounded floating shell looks cheesey, and covers up other information on the screen. Has Maxis decided to build Sim City 5 using Eclipse??
The fly-out view toolbars are displayed on the second monitor when Eclipse is maximized on the first screen and the view is docked to the right side (eg. Problems view on the bottom). Also the fly-out toolbars are not moved together with the view if the view is detached from the workbench and displayed on the second screen. Detached views should more look like real windows with title bar and close real icons.
Created attachment 7646 [details] Enhanced Workbench Color Scheme I'd like to introduce en enhanced workbench color scheme. There are two new colors: "Active Tab Background" and "Inactive Tab Background". "Active Tab Background" maps to system (OS) color "Application Background" (Windows name, not sure on other platforms). This color is a darker gray also used by the new Outlook 2003 (for example) as title above the views. "Inactive Tab Background" maps to system color "Window Background" (again, Windows name but it is the same background color like the view is using).
Created attachment 7647 [details] Eclipse using enhanced color scheme This is a screenshot of Eclipse using the new color scheme. PS: Its only a regular screenshot modified with image software.
Created attachment 7648 [details] Eclipse using enhanced color scheme with comments
Created attachment 7651 [details] Failure of the fly-out toolbar in dual monitor setups I attached a screenshot showing wrong positioning of the fly-out toolbar. Why not replacing the fly-out toolbar with an auto hide toolbar like the Windows taskbar? Of course this should be a preference setting as well as other new UI features. The toolbar is visible inside the view if the view is active. If another view gets focus, the toolbar will hide itself. This way it is ensured that the toolbar will always be visible inside the view area and will not hide other views or might pop up on a wrong screen.
Created attachment 7654 [details] suggestion for undocked single view Ok, and here is my adapted suggestion for an undocked single view. IMHO it should be really look like a single window with maximize and close button. I'm not sure about the minimize possibility.
Created attachment 7655 [details] Suggestion for undocked tabbed views And here my suggestions for an undocked window containing multiple views (tabbed)
A thought on the open perspective icon (+). Why can't it be placed in the same area as the list of open perspectives? It would then seem to be related to those icons. The placement several steps to the left and outside the curved pane does not suggest a relationship with the set of open perspectives.
this has already been moved inside the perspective bar area. its checked in to the new look branch, so its in the nightly build, at least.
Created attachment 7666 [details] Views with system like tool bars I did some more paintings and like to suggest changing the toolbar used inside the views into a native one or at least make it more to look like a native one. IMHO also the main Eclipse toolbar doesn't seem to use native widgets even with the correct javaw.exe.manifest file in place.
Created attachment 7670 [details] Inactive views with system like toolbars And here are the corresponding inactive paintings.
Gunnar, The paintings are neat but would you consider using png format for the next one? With gif the colors are funky, at least on my 24-bit windows display, probably because gif is an 8-bit format. jpg would probably work too but png is clearer for screenshots and takes fewer bytes. Thx.
I'd like to point out that the main shapers of the new look are windows users. The new look (as great as it is) doesn't render well on GTK or Carbon because it looks so Windows-y. We're drifting toward Windows inspired EMULATED widgets. I can't stress that key word enough. Why was SWT written in the first place? To provide Eclipse with an interface that wasn't sluggish, and non-native. Correct me if I'm wrong, but aren't we doing just that? It looks great, everyone. I think it's got great potential. But we might as well use Swing if we're going to do it this way. Come on! One of Eclipse's greatest (and most unique) features (at the moment) is it's balencing act between totally native and totally emulated. Somehow, (kudos to the designers of the orriginal interface) the Eclipse team managed to pull of the trick of giving us a native interface, that had that newness and uniqueness all great apps need to be distinctive. The look renders well on all platforms (except some WinXP themes), holds almost all of it's consistancy in porting, and at the same time is so native, that I find it hard to tell the difference some times. I don't get that feeling with the new look. And that's something I think we need to strive for. Great, let's do something new, but let's not make it TOO new, shall we?
In reply to Comment #78: I agree and I don't like the new way the UI team is currently going with the emulated widgets. That's why I try to make images showing most emulated widgets in system (native) style to show the UI team that a native look is not that bad. Of course I'm interested in screenshots showing the new look on MacOSX and themed GTK environments because they might really show the lack of the new look and the misusage of system colors (eg. ToolTip color is used to indicate the active view).
Maybe it would be a good idea to enable Eclipse to work with Windows XP themed controls first (i know it can be done by adding a manifest file, but should'nt it be the default setting ? Windows XP's native look and feel is Windows XP, not Windows 2000). The new L&F IMHO is not worth the trouble, time should be spent on optimizing the old one and trying to keep stuff small, tidy and fast, which is critical in an IDE. I've more than once thought, that maybe it would be a good idea to SWT-ize other parts of eclipse, by writing them as native libraries, which have Java interfaces. It would give eclipse a much needed performance boost in other areas too.
A comment on the floating toolbars in the new look (and a related suggestion concerning consolidating a view's menus): Carolyn MacLeod makes a strong usability case against floating toolbars in bug 51132, of which I concur. The feature I originally expected in the new look was to be able to hide a toolbar completely, even when the view is active. This is useful for two reasons: 1. It increases the client area of the view. 2. It removes visual clutter. For most views, I personally don't like seeing their toolbars at all. Most or all of a view's toolbar items are available as items on the view's menu, or through other means - keyboard input, duplication in the context menu, or direct manipulation. Additionally, our UI should support the idea that views without any toolbar items at all could recover this unused toolbar area automatically. Currently, having the 'view menu' button as a tool item itself unfortunately ensures that the toolbar always has at least one item, and hence the space can never be recovered. (there was also a close button on the toolbar, but that has now moved to the tab, so only the 'view menu' button is problematic) I propose we consider simplifying this model to the following: For any view, the user can choose to show or hide the toolbar. If the toolbar is shown, it appears as it does in the 'old look'. If the toolbar is not shown, it is completely removed. This state is maintained for each view. Views can specify optional initial behavior in their definitions, with the default being 'show' (2.1 behavior). (Though I would expect the gesture to toggle the toolbar on and off would we a menu item primarily, perhaps the designers might chooes additionally consider a small widget on the view to turn the toolbar on or off). In a related area, view's have three different menus: 'system', 'view', and the 'context' menu. It would make sense that the 'system' and 'view' menus are one in the same. This is not a new look issue per se, but perhaps the new look accentuates the strangeness of having separate 'system' and 'view' menus in the case of a floating toolbar, where it seems odd that one needs to look for the 'view' menu off a toolbar button on a floating window while the 'system' menu is available by simply right clicking the tab. I propose we consider simplifying this model to the following: The system and view menus are collapsed to one menu. Right click anywhere on the tab would invoke this menu. There is already a view icon on the tab to the left of the text, so we also have a permanent hotspot to invoke the menu with a left click. The view button comes off the toolbar. No other widgets are required on the view though a close widget would probably be included, at least on the tab of the active view, and the designer might also consider a small widget to turn the toolbar on and off, as mentioned above. Here is an example of the collapsed system and view menu, using the 'Tasks' view. (there would always be a separator between the 'view menu' items and the 'system menu' items, but there can certainly be other separators as well) ------------------------ ('view menu' items and separators start here) Sorting... Filters... ------------------------ ('system menu' items start here) Restore Move > Size > Fast View [x] Show Toolbar Maximize ------------------------ Close ------------------------ Notice the addition of a 'Show Toolbar' checkbox item which supports hiding and showing the toolbar on a view-by-view basis. As a variation which extends this slightly further, the [x] Show Toolbar menu item could be replaced with a drop down radio button menu: Show Toolbar > [o] Always [o] When view is active [o] Never or even, if we still decide to go ahead with the floating toolbar option: Show Toolbar > [o] Always [o] As floating when view is active [o] As docked when view is active [o] Never
regarding comments such as #80 about xp themed controls: this is certainly possible. last summer i wrote an xp theme skinning library for SWT. see the attached screenshot as a small example of the view title bars recoded to paint themselves using the current xp theme skin as 'MDI child title bars'. (note: this is an xp only solution. one would probably want to have similar libraries on gtk, aqua, etc.) this is the path we would probably take if we wanted to look more up to date with the native L&F, but 'new look' is not equal to 'update look to the most recent native look', for better or for worse.
Created attachment 7749 [details] example of custom skinning in XP using SWT
Well, the title of this plan item says 'evolve the user experience' which is pretty vague. The original report says it should support 'tear-off views and dockable toolbars'. It doesn't say 'make Eclipse non-native looking'. Do you want a new bugzilla for 'update look to the most recent native look'? Or is this one sufficient? See also bug 45918 ('eclipse should enable XP visual styles if available').
Allowing the user to hide the whole toolbar is like giving up. If you are concerned with stacked views which have few action (like Problems View) see my screenshot which shows how to place these toolbars without wasting an entire row. It's obvious that view toolbar bloat is going to be as much of an issue as the overall workbench coolbar. I'm already bothering JDT because they have added just enough actions to the outline view to make it wrap to two lines :-P. But, after seeing other people work, I realize that there is *no* common subset of actions for everyone. So here's a better (read "stolen") idea. Allow the user to create a subset of infrequently used actions/contributionItems per view. Then place the old ">>" toggle button which filters and unfilters the view's toolbar. If you're bored you can even animate the toggling like in the XP systray. Alas, the user could disable the feature per view by toggling a "hide inactive items" setting on the toolbar. Uber-flexibility would be to bring up a dialog of all available contributions/actions for the view, and allow the user to place them on either the view's toolbar or menu.
I'm a bit late to the party, but here are my thoughts: - generally, I like the new UI, but agree with most posters that platform-consistent look and feel is far more important than an Eclipse-specific l&f. - don't like the double height toolbar. In fact, I wish the old (maybe 1.x) collapsable coolbars were back, where you could grab the coolbar handle and hide the buttons a la IE (this is particularly useful for toolbar "friendly" plugins like Clearcase). - I *like* the single editor tab. Or more precisely, I like seeing the full name of the document currently being edited in the editor tab. I often find I'm working with files that have the same starting characters and the compressed tabs make it difficult to know at a glance which file I'm editing. I've remapped the Next/Previous Editor keys to something more convenient than ctrl-F6, so not having the other tabs visible is not too much of a problem (a shock on first couple uses, I admit).
Created attachment 7771 [details] collapsed IE toolbar
Opened bug 51628 for the requirement of updating Eclipse to the most recent native looks.
I agree with comment #65, #78 and others, which I think highlight the need for a thorough *design manual* as well as a *usability study* -- *before* any work is performed on the actual UI. Eclipse is important to many people. As one Eclipse user, I find the current iteration of Eclipse -- without the "improved" UI -- blissfully free of the kinds of unnecessary bells and whistles that have madly infected UIs of late, especially from the Microsoft end of things. Eclipse's UI works. It's extremely practical, therefore it works extremely well. From what I can see, none of the UI improvements aid usability. Flying menus, padding, weird alien colours -- it subtracts, rather than adds, to my productivity as a developer. The only potential improvement I see is the larger perspective buttons, but you don't need to revamp a UI to get those. To me, these changes look only as if catering to some fleeting notion of coolness. Tomorrow there'll be another idea for what looks "cool", and these things evolve so quickly that there is no way Eclipse can stay up to date, except by support native theming systems. What we don't need is another app that changes its UI every six months, Microsoft-style. Now, if Eclipse *needs* anything it's better integration into non-Windows window systems. Eclipse is sluggish at best on GTK+, and doesn't look great on OS X, where floating windows is the UI convention of choice. This new UI work is just a waste of effort.
When will the new UI be the default in a formal build? I ask because I think fewer people than you might think know about it, or have at least performed a test drive. Given the well hidden instructions on the JAR copy process (and one JAR in the wrong plug-in), I'd say quite a high percentage of Eclipse users have not seen/touched the proposed UI. We see the other changes to Eclipse in each build and comment accordingly, but this is a stealth activity. Don't you think you need to expose this to the general population for a more comprehensive review/feedback cycle? Maybe as an alt download for M7 (even post Feb 13), with the config changes made already, anything to make it easy to see/grab/try. I'm sure you'd hear more than the 89 entries in this bug report - and if it just shows up at the end without a cycle of full (default) exposure - you both might be surprised at the strength of the reaction and not have enough time to react accordingly. Just a thought.
Looks like nobody was interested in my comments, but I only can say it again: Make it configurable! You just can't know what the user likes. If a user can configure it as he/she wishes, it's a good thing - if the user is being forced to a specific look, it isn't.
In response to comment #90, Pat you comments are legitimate, and things may appear this way. However this is not a stealth operation and will be more available soon. The difficulty is that making a partial UI solution available just leads to more comments as many of the incomplete (yet to be done) items appear as intentional decisions and that is misleading as well. Rest assured this will be available soon.
re #90: the current thinking is that the 'new look' (currently a branch project for which we produce those replacement jars by hand..) will go live for the first integration build post-M7. this means if M7 is declared today, we will merge the branch to head as early as today, and you will see the 'new look' as the 'only look' by the integration build this tuesday.
Please do not force this new look on us by default and let the platform look be the default. Platform look, especially on XP is very important to me. (I won't repeat what other posters have said.) Thanks. Eclipse rules.
This comment is not intended to fly in the face of the last one but... the new code stream has been released into HEAD, however there are no nightly builds this weekend, so the earliest opportunity to get this build will be Monday Feb 16. It has been difficult to balance coding with reading/responding to comments etc.. up to this point. However all comments are appreciated and we look forward to engaging more on some of these topics.
Created attachment 7904 [details] .bat file to swap in new UI jars For those who just can't wait until the M7 integration builds start up next week, I created a little batch file that makes the appropriate changes and renames to enable the new look. Save the file into your \eclipse directory and run it, and it will copy/rename the jars as appropriate. Original jars are renamed to xxx-old.jar
i agree with comment #21 and many others that this is not the direction that eclipse should be going. the LAF is the domain of the OS, not eclipse or SWT. this is like reinventing the wheel to be square; it's wasted/duplicated effort creating a product that already exists when the round wheel got it right in the first place. i understand that a lot of effort went into this new look, but the fact is that the overwhelming majority of developer types will not like it after playing with it for 5 minutes. you should have gotten more feedback before you wasted all that effort. there are some good things that should be placed in the current LAF: the (un)dockable windows and the drop-down list for the editors come to mind (keep as many tabs on screen as space permits, though). besides, the new LAF may look pretty today, but as styles change it will look dated tomorrow. this supposed to be a professional product; let the makers of Winamp and EA Sports Football worry about trendy skins. the whole point of SWT is to have a uniform look across the OS. this GUI looks so alien (and is so slow) i wanted to beat my computer with my pool stick. please do not make this the default.
I'd like to add that one of positive Eclipse side effects is the ability to tell people, that yes, it is possible to create a professional GUI with Java. A non-platform LAF torpedeos the possibility of using Eclipse - the best looking Java IDE IMHO - to make that claim.
Created attachment 7916 [details] BATs to turn on/off the new look - based on previous attach Added an oldLook.bat (so you can toggle), adjusted newLook.bat so it does not copy (once you have done the copy it gets in the way). Remove the REM on the copy to let it run very first time you use it. Note: Prev(original) newlook.bat seemed to have the commands twice and some extra text.
Going to give the current new look a long test run. I already kind of like the collapsable views, wish this was in the base regardless of 'look'. A 'small issue' with these collapsed views. Shouldn't they return to normal size when focus is sent? For example, if you use F4 to open a class hierarchy, shouldn't that view return from collapsed mode? Same goes for a double-click on an entry on the plugin.xml editor extensions page which sends focus (and opens if required) the Properties view. It is a bit disappointing when these don't return to normal size - I ended up thinking I had not issued the request so I tried again and again and....
Created attachment 7919 [details] M7 screenshot showing problem with hidden stacked view. In this shot you can see that there wasn't enough horizontal space to show both the Package Explorer and Hierarchy views so only the Hierarchy tab is visible. You can get to it from the menu but it might take some doing trying to figure out which stack contains it. I'd prefer to see all the tabs even if some of them are truncated or partly obscured.
Created attachment 7920 [details] M7 screenshot showing clipped close button This is easier to see when you have the editor set to show only one tab. If the filename is large or the edit area is small then you can get your close button clipped or hidden entirely.
Created attachment 7921 [details] M7 screenshot showing diff between edit and view dropdowns View dropdown menus stay on the right hand side of the view rectangle, but editor dropdowns stick close to the edit tab. If you turn on the option to have multiple edit tabs then the dropdown stays over on the right hand side like views. Not sure if this was intentional or not but it seems like an unnecessary inconsistency.
Created attachment 7922 [details] M7 screenshot showing problem with slide out toolbar Two problems are visible here. First one is that the toolbar is too wide because of the button/pulldown combo widget for history here (not sure what the term for that is). It took me a while to figure out what the little triangle in the second column of the toolbar was. Second problem is the colors. I'm using the default colors and you can barely make out the unselected icons. When you select one, it shows a jarring white background.
Created attachment 7923 [details] M7 screenshot of junit color patch Reset the Java perspective. JUnit shows up as a fastview on the left. Turn it into a regular view and it stacks on top of Problems. Grab the JUnit view and drop it on top of the Package explorer. You'll now see a swatch of green color on the bottom of the flyout toolbar and the toolbar is wider. If you switch to a different view and come back, the swatch goes away and the toolbar is normal sized.
I have tested it for the first time now wit M7, and i think i like it.. collapsable view are very nice. for now i only notice one thing. If the tabs can't be displayed all then some will hide it self and can only be get through the popup. Now i do like this feature but i would preffer that the last used views are hidden. For example i have Navigator/Package Explorer/Synch View and Hierachy in one stack. Now Hierachy isn't used that often compared to the other 3 so i want the hierachy hidden most of the time. But if i go to Sync i loose Package.. The same goes ofcourse of the editors.. last used should be visible..
I second comment #97 and #98. While the M7 look is an improvement over the first version, it looks alien. (And too roundish for my taste.) I use Eclipse as a maximized window on a two monitor setup. The outline's sideview-thingy is placed on the second window which is really annoying. Fortunately, I can pin the sidebar down into the view, but this takes put a lot of screen real estate. The first line shows "Outline X" and the two new view controls. The second line shows the PIN icon and yet another close icon. The third line shows the usual view icons. I could resized the view so that the second and third line collape but I don't want to because that would take too much space from the editor view. If you feel the urge to create your own look, please create one that results in more - not less - real estate for the content. Due to the perspective buttons (I think) the toolbar did grow, too. I dislike that the editor view collapes all tabs into one centered title. In the old (normal?) view, one click was enough to change between editors. Now I need to target this tiny triangle and click, and click again. This is a regress in usability.
Are tear-off views broken on MacOS X, or am I doing something wrong? I can pick up a view and drag it to anywhere within the IDE, but as soon as I move it outside of eclipse's window the cursor changes to a 'no entry' sign, and dropping the view simply returns it back to wherever it came from. Do I need to do something special to 'detatch' the view from the main IDE window first ?
Tear-off views do work fine under Windows but i can only drag the window that i get when i press the mouse inside the tab. Not in the the gray area on the right of the tab. This is a bit annoying. and because of that. If i have 2 (or more) views in a deattached window. How can i drag that window without removing the view i that is selected? (move>tabgroup doesn't seem to work) And where is that nice collapse icon in a deattached window? Would be nice to collapse the complete window at once so that i only have the tabs as a window.
I tried the new view in M7. It kinda looks OK but I've got a desperate plea to you guys - PLEASE PLEASE PLEASE do not put all the open editors on one tab!!! This would destroy my workflow. I chose Eclipse for its simple interface. This would ruin it for me. If I'm working on 6 or so java files I like to see at a glance which ones I've got open and quickly switch between them. With the one-tab thing, I cannot see this, and I have to hunt on the drop-down list. I may as well not have them open at all! Please, don't do it!
You can switch back to multiple tabs! Window -> Preferences -> Workbench -> Editors Eclipse developers, please consider using multiple tabs as default preference!
Phew! Thanks Gunnar. I did look for that but couldn't find it. Thanks a lot for that. Otherwise I would have to learn to use N*tB**ns. ;-) Make multi-tab the default. Phil
Is anybody here that can do a MacOSX screenshot of the new look in M7? Especially I'm interested in rounded tabs with close button and floating toolbars. Do they look are feel native on MacOSX?
New look in M7: The colors for active/inactive views feel better and clearer now. I assume they map to system colors for inactive/active window title bars, don't they? But there is some more work left. - gradients are not native on some platforms (at least on Windows NT/2000 its uncommon) - rounded tabs simply don't feel native (maybe on MacOSX) - the close button on tabs also doesn't look native - what about positioning the close button next to minimize/maximize button - why keeping the border around views and editors (we don't need this for active view indication) - it is very hard to recognized the belonging of the minimize/maximize buttons because they are painted freely between two views (do they belong to the upside view or the downside view?) Undocked views should become real child windows (like Find/Replace dialog window) so that they can be moved and placed in other monitors _and_ all over the Eclipse workbench. If necessary we should give them another button for docking them back into Eclipse. This is probably easier and a more common behavior than dragging around and watching the mouse cursor what might happen if you release it somewhere. Is it possible to create tabs that render native on all platforms and provides close buttons like Swing does it? What about painting docked views as embedded child windows? I mean with a real title bar with minimize, maximize and close buttons ond it and a tool bar that auto hides when nothing is placed on it? Native tabs could be used then. Having a title bar and tabs is no problem et all. It doesn't add UI clutter because the title bar can be used to display important additional view information (like an active context or so). See the Eclipse tite bar. It conatins information about the current perspective and the current editor. Our application introduces some views that need to display additional context information in the view's title bar. How is this handled by the new look? Is the tab text expanded so that it will result into a very hugh tab?
My 2c... Every time I show eclipse to someone new, they're impressed immediately. A good chunk of that is the look. It looks "professional", like a well-written app for the O/S (I demo it in Windows, but it's looking better and better on other machines as well). I constantly get into debates about the merits of SWT vs. AWT/Swing, where the key IMHO is *correct* platform look and feel. Please make sure the NATIVE implementation is the default, and provide options to switch to the EMULATED widgets. I don't want every user I've converted to eclipse abandoning ship when they see this L&F. I think the only folks who will really want to use this are some developers who think it's "cool", and I think most of them will be linux folks who want to skin everything including the Statue of Liberty. General users (ie most programmers and nearly all end-users of eclipse based non-IDE apps) expect and want their apps to fit in with the machine they use.
Created attachment 7926 [details] New Look on Mac OS X Doesn't look or feel native.
Here's my unasked-for opinion: It's ugly, and please don't. One of the things that had originally attracted me to Eclipse was that it pretty much looked like a native application, no skinning nonsense. I'm sure there's still a lot that can be improved, but I'm rather concerned about the direction this is taking here.
I agree - don't do it! The simplicity of the present GUI is one of the things that attracted me to Eclipse in the first place. There are too many distracting, cheap gimmicks in this new GUI.
The dropdown list for selecting tabs quickly in a list is a good idea, but why are all tabs collapsed under one tab? A better solution would be to display as many tabs as possible on the top of the window, and collapse all over hidden tabs under this dropdow list and display an arrow to show that list.
Does this 'new ui' actually address the things asked for in the bug? "This includes allowing the user to customize the workbench by creating floating toolbars and views, and supporting tear-off views and dockable toolbars where supported by the underlying window system." These are really useful things to have. (maybe they are there but I cant discover the UI to do it) Note that the bug makes no mention of making the UI look totally alien. The whole SWT thing is 'look like (in fact be) a native app'. We eclipsers really like that. An ideal IDE should be invisible, not in your face like an MP3 player. As somebody else said - can we have a 'vote against' mechanism for this. If the RCP ends up looking like this then I can't use it (I already get complaints that its not vanilla enough) If somebody wants to invest time in allows skins for eclipse thats fine. But lets keep the 'clean and simple' skin for real work.
Eclipse-3.0M7 - new look I agree with the other comments: space should not be wasted. And in general this seems to be achive, however some times with a cost when tabbed views are to narrow to show all tabs only one are shown and the other are now 2 clicks away. One such case are the "Package Explore/Class Hierarchy" in the default Java perspective. This could easily be improved by allowing the view choice list to have a "lock in view title bar" button, kind of like the view toolbar that can be both in fly-out mode and "lock in view" mode The "fast view" icons should be in a toolbar, this would save some space to the left. And for those that prefer prefer them to the left you should just suport toolbar docking at left, right and button as well as on top. Tear-off views should be able to be in front of eclipse not only beside it. The "lock in view" button and "fast view " botton should use differnet icons since they can both be pressent in a fly-out toolbar In the new look I also miss the search view information about which scope that have been searched (in the old look this was shown in the search view titel bar) shows e.g.: Search ("main()" . 1 Occurence in Working Set - HelloWorld) The fly-out toolbar should be able to lock in view on right side as well as on top, problem is that when you have a wide but not so high view with "Veritical view orientation" and the toolbar fly invard it might cover some buttons in th lower half of the view (try doc JUnit view together with Problems view and maximize eclipse)
I renamed the four "-new" jar files to be not have "-new" and and moved the texteditor one (just like in the newlook.bat file, but I dont' get the new look. Ideas? (this is a Linux box)
This version is much better than the M6 version (see my comment #13). However, there are a few little anoying things remaining: - I accidentally cosed several views, because the close button (X) is not visible when a view is not on top. When I quickly click into a view tab, I often click in the white area right to the label. This becomes the close button. I think, a light close button would help to prevent this (or moving the close button next to the maximize minimise buttons). - Using the "Selcted Tab Background" color as the background color of the view toolbars is a bad idea, because the diasabled and "uncolored" toolbar buttons are very hard to recognize. Maybe the disabling and "uncoloring" algorithm should take the background color into account... (The problem appears on XP default theme, where the background is blue)
I posted this on eclipse.platform but figured I should append it here for the record.... Here are some of the things I like: - The active view or editor is more obvious: the tab is a different color and shape, and there's a blue outline (on Win32) around the active pane. (FWIW, I'm somewhat red-green colorblind, so I tend to have oddball opinions about color.) - It's more obvious what's clickable and what's not. - Both Views and Editors have the tabs at the top now. I had gotten used to views having them at the bottom, but it took no time to get used to this way. Consistency is good. - I really like the action for minimizing or "window-shading" a view. Very handy, especially in the Debugger perspective where there are a ton of views that I only need occasionally. - People will probably bitch about the additional level of "eye candy". I kind of like it, though, because it doesn't detract from the functionality and in some cases improves it. Things that will take getting used to: - The perspective bar is now at the upper-right, which is a less "central" part of the UI -- farther from the menus and so on and easier to forget. I understand why it was moved -- it was wasting horizontal space -- but the new position will a while to adjust to. - The toolbar and menu in views' title bars has gone away and been replaced with a vertically-oriented toolbar thing that hangs off the right-hand side of the view. This is ok but will take some adjustment. The one case where it's really strange is when a view abuts the right-hand side of the screen and the toolbar thing hangs back into the view, obscuring part of it. I haven't seen any cases where it obscured something important yet, but it's disconcerting. - The little popup window where progress information is displayed is weird. On pre-M7 builds it looked awful on my Linux box at work because it ended up with a normal window title bar, which was the only part of it you could see because the rest was hidden under the Gnome toolbar. I'll try it with m7 and file a bug if it's still broken. On Windows I've seen one case where the progress popup overlapped the taskbar, which isn't supposed to happen.
Just a reminder, Please if you are logging bugs from now on, please log a single bug report (or add a +1 to an existing one) for each individual bug. This bug report is way too large to be able to mark as FIXED as you can imagine.
What is the plan for the L&F for 3.0 final? I think the amount of feedback on this bug and in the newsgroups warrants taking a good look at what the default L&F will be. Not to mention the fact that this bug only has **one** vote. 3.0 final should use NATIVE SWT as the default; that's the main story behind why SWT exists: and the app looks and performs quite well as a native app, which is something Swing can't do. When the Swing folks hear/see this there'll be screams of "Swing can do that even better", which I would agree with. If a few people want eye candy, It's fine to make that an OPTION (or better still a separate plugin), but no way should this be the DEFAULT. I never understood the whole obsession with skinning, and I'm now getting very worried that a handful of skinners are driving the L&F without any consideration for the folks who have bought into how good eclipse is, quite often because it's truly native. When I tell folks that Eclipse is a Java app, they're floored. If they see this, they'll say "duh -- it looks like a toy". Don't screw the majority just because a few developers think this is cool. The Eclipse teams have been very good at adding new options without killing old ones, so PLEASE don't force this on everyone.
As a quick response to comment #120 (and many others) it is important to note that the item that was significantly changed in the new ui really never was a native SWT widget. Namely the Tab Folder (see CTabFolder class and it's variants) is a totally fake widget that has always looked different that the platform (more so on non Windows environments). There are a number of things that we needed our tab folder to do that were not supported by native tab folders such as having a close box on the tab. Aside from changing the tab folder, no existing use of platform native widgets was replaced with non- platform widgets.
For comments about the view status information, that is currently being investigated. The goal is to only use space for this when a view actually has status text.
response to Comment #108, tear off views are not supported on Max OSX and Linux-Motif due to platform limitations.
I should clarify my position a bit. The app should look/behave native. This L&F doesn't fit in with other apps on the O/S. While I like the concept of things like a drop down menu to quickly choose tabs (I did the same thing with my TabSplitter component back in 1998), the tabs should at least look right on the O/S. I understand that SWT normally emulates some widgets, but that doesn't give license to make them look out of place.
In response to comment #129: Michael, isn't is possible to support tear off views on all platforms if we go another way of implementation and create non blocking child windows for tear off views (like for dialogs)? These windows would conatain another tab folder and multiple views can be dragged an dropped into them. This would also allowus to place and move the views all over the workbench or to other monitors without having to watch the mouse cursor every time such a view is moved. I don't like the current behavior because it is somewhat uncommon for me as I never had an application with a similar behavior. Most apps behave like multiple window apps. Of curse this requires another button for docking the view back into the workbench but this could be also implemented using drag and drop again (the window can be moved the regular way and the view can be dragged when clicking its tab.
For those posting comments, please try to stay up-to-date with this discussion and know what you are talking about. Examples: - There is already a discussion/bugzilla about axing vertical toolbars completely. - CTabFolder was *never* a native widget. It used to be more subtle (in fact yuou couldn't even tell which tab was selected), but it was neither native nor was it perfect. The reason the new look was done "offline" was to prevent the flood of bug reports which we have seen in the last few days, like buttons being clipped, hidden etc. Don't report problems with the implementation here. I'm sure the developers are busy writing code and are fixing multiple bugs per day. Wait a week or two, and if the problem still exists, open a NEW bugzilla to track it. Let's reserve this bugzilla for constructive high-level discussions about what the New Look is and should be.
"isn't is possible to support tear off views on all platforms?" Good question, let me clarify: to maintain the precise state of a views contents when tearing them off we call an SWT method to reparent the widgets (essentially from the workbench shell to a new shell). So creating a dialog (i.e. non-blocking child window) is essentially requiring the same function in the OS. (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=13585 especially Comment #15 for a summary) "This would also allowus to place and move the views all over the workbench or to other monitors without having to watch the mouse cursor every time such a view is moved." I think this last point is a bug/feature request. Could you create a bug report indicating how you think the dragging of a view versus moving a shell etc.. could be implemented to support both?
This whole thing looks like a case of throwing the baby out with the bathwater. To implement some new features, the entire look and feel of the app was changed. Bad idea, folks. RH wrote: "Let's reserve this bugzilla for constructive high-level discussions about what the New Look is and should be." How about discussions about whether it should "be" at all. It appears from a lot of the feedback here that this will not be well-received in general. I, personally, want to see some more repsonse from Eclipse developers addressing the issue of whether this is even a good idea to begin with. This feels as if I asked a contractor to install gutters on my house and I come home to find not only the new gutters but also the house painted a new color, landscaping re-done, and a new room added on the side.
How will this "new look" impact Rich Client Platform applications built on Eclipse 3.0? I do not want my applications to inherit any of this look or these new features. Will we be able to turn the "new look" off? This is critical for our success. I also agree with the comment that the CTabFolder control looks "less native" than it did in 2.1. If the CTabFolder's looks is going to change, can it be done in such a way that it's appearance and behavior is customizable? What about apps that are built using just SWT. Will they be able to get the look and feel of the 2.1 CTabFolder when they move to 3.0?
Added bug 52175 (view tabs should be more subtle) for discussion of CTabFolder.
Judging by the comments a significant number of users do not like the new look and feel. I could not agree more with Alvin Thompson and the comments he made. I am just wondering if anyone is reading these cries of disappointment. Please do not make it a default look and feel in 3.0 release.
Ok, here's my high level comment: -1 I suggest you consider de-committing this plan item and pulling out the code. I know the new implementation must have been an enormous amount of work but judging by all the prototypes (including M7) it's not what I'm looking for in terms of improvements to the user experience.
I am using it now for a few days and i must say i am starting to like it .. so now many vote agains it i want to vote before it, ofcourse i don't like everything also (like the blue border arouond the selected views editors.. just the blue and different shaped tab is enough) but most of the things like the move of the perspective bar, drop down of open views/editors, collapseable views ect. Are pretty nice things. The only real thing that is changed visiually are the tabs if i am nog mistaken. So just tweak that a bit more that it is not so visually there (including removing the blue border around the editor/view) then it goes to the right direction.
added bug 52217 'use coolbar for perspective selector' for discussion of the perspectives area.
I have to agree with most other comments here. I doesn't like the new look very much. Please keep the simplicity!
Why we cant have the current look as default whatever (new!) as an options people got hooked to eclipse because of its L&F and you are taking it away ! Please keep the current simplicity intact !
I too will voice my opinion on the new look and feel. I have tried it in M7 and I definitely do not like it. However, this is not just subjective opinion, there are several things wrong with it. I will sort them in order of importance: 1. Breaks native look and feel. Eclipse IDE provides a lot of functionality that makes it a very useful IDE. And the fact that it followed native look and feel, was a big plus over other IDEs. However, this is no longer the case, and is a cause for concern. It simply does not look like a professional tool any more. (On windows one could easily customise perspectives to make it look like Visual Studio.NET which is a very typical professional Windows application). There is a big difference between offering custom off the wall navigation toolbars (like MS Outlook does) that look different than the standard native app, and between changing how a native component (like a tab) looks like and behaves like. Enough has been said about this already, I will not repeat the same points 2. New UI is simply broken. If enough tabs are added (either editor tab or stacked views), the ones that do not fit simply disappear with no indication that they are there. This is unacceptable. 3. The usefulness of the unpinned buttons that pop up on the side is very questionable. For most of the views I find I need to pin them to make the buttons more accesssable, since developers do use them a lot. 4. I don't understand why is it so hard to get the editor tabs behaviour right. Visual Studio.NET handles this the best of any IDE to date: little scroll arrows are always displayed, no matter how many editors are open. If only one editor is open and its tab fits in the view arrows are greyed out. If more editors are open, tabs are never shrunk to fit more tabs (tab size is always wide enough to fit the file name with extension), but the arrow becomes enabled and it scrolls the editor tabs smoothly and not in dicreet increments. That way one always knows what files are currently open, and you can get to them very fast. Tabs certainly do not disappear and become unaccessible. 5. The default colour scheme makes it very hard to see the icons. Something's got to change there, either icons become more colourful (on windows at least icons should have complementary colour to blue to make them stand out e.g. yellow (I can't imagine the colour wheel right now), on other platforms colours need to be different). The old UI handled this much better. 6. A decision needs to be made on the wide scale about the direction Eclipse is taking. This new UI has much bigger consequences for the future than one might think. Departure from native look and feel and consequences etc... One solution that most of us I'm sure could live with is to offer the old and new UI side by side and make it a user preference. Enough people have "cried" about this new UI, that it will be interesting to see how the Eclipse team deals with this challenge and how do you handle the "conflict" between the desire to re-vamp the look and feel of the IDE and the wishes of the users expressed in here.
Another addition that I forgot to mention. The ability to close the tab from the tab itself (i.e. the X icon on the tab) reduces the usability of the views considerably. In the old UI I could switch between the tabs without even looking at them, now I have to be careful not to click on the X, or I'll close the view that I want to switch to. Very silly addition in my opinion.
I'm not sure it is clear what the new bugs added are for (divide and/or focus the discussion on certain controls?) - re: https://bugs.eclipse.org/bugs/show_bug.cgi?id=52175 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=52217. I'll +1 the comment on the inadvertent close of views that happens quite often when you jump between them with the mouse (screams are common). I'll add that with the very tall and wide colored area in a view, you tend to double click there to say maximize the view - and nothing happens (very misleading and frustrating). It might be nice if the editor drop down list (shown only after n open editors), was there all the time. This list should also allow you to close editors via a context menu (the old implementation of this did that and more). The list is still off the screen when Windows start/task bar is on right side. (The old implementation did not have this problem). Old implementation = https://bugs.eclipse.org/bugs/show_bug.cgi?id=31564 And a last bit of frustration as I've been test driving the new look for a few days - the Problems view no longer shows "(Filter matched x of n items)" - this loss is subtle but painful. Beyond that - I like most of the new function (except the floating tool bars, I pin each and every one). It seems like the reactions being posted are more about the look, and the lost of visibility to the number of tabs open (in multi tab mode the number shown is less than expected). Some of the other options are nice. Couldn't this work with the old look/feel and folder?
I've been using this new look for about a day now. I think (for the most part) it is worth keeping. For what it's worth, here's a list of small changes that I think would go a long way to making this more usable: By default, the toolbars should be pinned. When they are floating I find them to be almost unusable. Most of my views are things that I visit quickly and then leave to return to the text editor. Having to click to reveal a toolbar is very disruptive to my work flow. In addition, I can't see importatnt status (such as what items a re filtered in the Outline View). The new editor tabs are also (in my opinion) a major step backwards. I can no longer see at a glance what files are open. Finding the editor I need via a pulldown menu is very cumbersome. I found it necessary to turn this feature off. I think the right approach here would be to show tabs up to a certain limit, and then use the drop down to handle "overflow". The "selected" border around the focused view is a good idea, but it is too strong. It is rather distracting. I have repeated closed tabs that I was simply trying to select. Perhaps drawing a subtle, disabled 'x' for background tabs would help here. The perspective toolbar looks too much like a tab, the curve should be reduced or eliminated.
Having looked at this new UI for some time now I still have mixed feelings about it. There are some nice additions, like floating toolbars, but the overall impression is not as clear and clean as it used to be. In particular, a lot of space is wasted horizontally and vertically for effects that do not help readability or intelligibility. For example, the tabs look very over-designed to me while losing much efficient use of space. My advice would be to start with the 2.1 style UI and add the new features in a more consistent, simple and efficient manner. For those who have not seen it yet, maybe have a look at the Red Hat Gnome UI guidelines that are a good example for efficient, simple and artistic design (imho).
Re: Comment #146 about the possibility of overflow: you can already do this. I noticed today that there's an option to enable "multiple editor tabs" or something. Give it a whirl. (still wishing the tabfolder _could_ be implemented natively -- seems like it should be able to since gaim has tabs with close buttons on both gtk2 and win32 w/wimp) mike
When a view toolbar is pinned, it appears as if it is a title bar of the view (when the view tabs are placed at the bottom of the view), but double clicking on it does nothing. Very counter intuitive, but that's what you get when you overload the behaviour of UI elements (they look like native titlebars but are not title bars !?!). If you decide you must have X icon to close the tab (I don't mind it on editor tabs since editor tabs are usually wider than view tabs), at least remove them from view tabs, since after several days of using the new UI I still keep accidently closing the views. At the very least make the close button on view tab a user preference. The fact the users now have to slow down and look where they are clicking on the tab to avoid closing the view stifles productivity. Also, view toolbars should be pinned by default.
Overall, I definitely like the new look, sharp! Much better for being able to tell which view tab is active. I also like the new position for the perspectives. However, I don't particularly like the vertical toolbars (at least not on the outside of scrollbar like that), and they pop up on the wrong screen of my multiple screen Linux desktop (I like to keep Eclipse maximized on my 2nd screen). Keep it, keep refining it, and add an option so the whiners can keep their "classic" (old, dusty) look... But glad you sharpened up the look!
Update: Vertical (aka floating) toolbars on views have been removed as of Monday Feb 16th, thanks for taking the time to make your opinions known.
If I have a file open with a really long name, I don't get to see the 'X' in the editor tab to close the file unless the editor tab is the size of my whole screen, since the 'X' comes after the end of the file name. This means I need to right-click on the editor tab and choose Close. This is overly cumbersome.
I am running: Version: 3.0.0 Build id: 200402181101 on a Win XP machine. Once the number of editors becomes sufficiently large, the editorlist dropdown shows up. But when I click on it, the lightweight popup which shows the list of currently open editors seems to extend beyond the screen. I will attach a screen shot.
Created attachment 8013 [details] Screen shot showing truncated editor list lightweight drop down
The number of attachments on this bug became too much for Bugzilla to handle. Any attachments added before 2004-02-13 16:20 have been moved to bug #52685. Please add new attachments to bug #52685. Sorry for the inconvenience.
FYI, I've opened bug 52892 [RCP] Workbench look and feel for non-IDE apps. This is specifically to capture feedback about old (aka classic) vs. new look for people building RCP (i.e. non-IDE) applications on Eclipse.
Created attachment 8146 [details] A simple bash shell script for switching the L&F Batch files are all well and good for W&*^$@ users, but for the sensible people who use Linux, shell scripts are the way to go. Here's a simple one to switch between the looks. It will switch to and from the new look. It assumes that you place it in the root directory of the Eclipse install (i.e. in the same directory as the 'eclipse' executable). It also assumes that you have moved the errant texteditor-new.jar file to it's proper location and haven't changed the names of any of the jar files involved in the switch. When it prompts you for the three digit version number of your copy of eclipse, enter '3.0.0' in the case of Eclipse 3 M7. If your plugin files show a different version number (i.e. org.eclipse.ide_3.0.1), then enter that instead.
If we're going to emulate our widgets in Eclipse for this new look, let's at least emulate all of them. I realize that emulation in the new look is really unavoidable. Asside from reorganizing the placement of the CoolBars, you really can't change the native look too much. One thing I've noticed in my Linux GTK copy of Eclipse is how startling the contrast is between the new look and the ToolBar (just picking an example). The ToolBar is still native (I'm not bashing native one bit) and it (especially the color scheme) looks foriegn when placed beside the emulated editor tabs. (that is, if the editor tabs are ever made truely plural :) My suggestion: Since we've now decided to make the new look emulated, emulate it completely. Try to remain as true as possible to the color scheme of the platform/theme currently displayed in the native ws, but deffinately emulate everything. This will certainly result in performance decrease, but if we wanted performance, we'd be using the old look. Give us two separate and distinct options: Native, and Emulated. One or the other, not one AND the other.
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.
One on the most attractive eclipse 1.x & 2.x aspect is the OS windows L&F integration and the aggressive UI performance, like the native compiled application. I think that swing framework fail its mission and SWT can beat it. Again, Eclipse can be really a generic OS Integrated application framework if it remembrer&respect its original OS L&F design. So if the new look is only optional and the additional overhead does not apply in 'native' L&F mode, than it can be an interesting new platform aspect, useful for an application subset, but not for all! Please, put an enable/disable check in the preferences for the 'platform skin feature'. Thanks. nik
HI, I like this new look but have some remarks: I use the fast view thing a lot. But i'd like to see it on the bottum, left and right at the same time. The menus look cool but they overlap the scrollbar quite often. Also it is annoying that i have to click a view to see its menu. Especialy when i want to stop a java process. Maybe this is the wrong place for this but besides that i would love to see a run button in the console menu that runs the last runned task. Maybe a complete different view for running java tasks that shows more info about what is happening (the command that is being run, some more buttons in the menu for stopping, starting, pauzing etc.)
Forget about the fixed menu problem... There is a "lock in view" option :)
As a follow up for comment #159 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
Running Fedora Core 2 test (kernel 2.6.3, gnome 2.5.90, Sun/Blackdown JDK 1.4.x) makes eclipse crash on the new look. I know that bleeding edge isn't worth fixing, but just a heads up.
Chris, Can you enter a new defect report for your crash. What you did to cause the crash and attach the contents of the .log file as well if one was generated.
Good news or curses depending on your point of view. Whatever my yum update installed last night fixed it. Everything is kosher. Except I can't figure out how to create a tear away editor. GTK2 so it should work. Is there some sort of keystroke command that is necessary? Some preference to permit it?
Tear away editors are not supported, tear away views (just drag the tab to somewhere on the desktop) are supported.
The new look and feel is very nice, but I couldn't find how to make all open editor names to be visible. Another issue is fast views opening at the bottom instead of on the right. Many views have natural vertical orientation and don't look good in the new l&f.
genady: You will get button now if you have more tabs then that area can hold it wont compact the tabs anymore until nothing can be read anymore.. The fastview holding area can be dragged to left,right or bottom. And now at default it is in the best place possible... The bottom!! Because there it won't take any space that isn't already taken anyway (statusbar) I really love this feature.. (because i don't use fastviews at all so it did take only space...)
Hi, I hope this is the correct place to make a comment to the new ViewForm widget. I noticed, that the thin, black border that seperated top-controlls and content- controlls in the ViewForm, is not showing anymore. Sample Snippet: public class Main { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); ViewForm viewForm = new ViewForm(shell, SWT.BORDER); Composite c = new Composite(viewForm, SWT.NONE); viewForm.setContent(c); Composite c2 = new Composite(viewForm, SWT.NONE); viewForm.setTopLeft(c2); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } } } Using SWT 3.0 M7 the line shows, using newest integration build swt-I20040325- win32 it is not visible. Any suggestions? Ben
Let me add my voice to the people asking for the old look. Please, please preserve it at least as an option to revert back to it. It seems I'm a little late here. I have to agree with comment #90. This might not have been a "stealth activity" for the people that actively follow the mailing lists and all the newest builds, but for the "normal" user it comes as quite a surprise in M8. And a shocking surprise for a great many I dare to presume. I have given the new look&feel a few days now to get used to it - without much success. One of the reasons why I have fallen in love with the old UI was that it was clean, clear-cut and concise. Most icons were grayed out, active tabs appeared in a decent dark blue and the overall look was pretty unintrusive, making it easy to "blend out" the surrounding tabs and windows in your mind when working on the code. The new look is bloated and cluttered with colors, color effects, curves and all sort of unnecessary eye-candy, hitting you in the face all the time and distracting from the task at hand. Nothing of that adds to the user experience that this bug aims to improve. And not only because of space wasted or because it doesn't look 'native', but above all because it is intrusive. This is supposed to be a professional tool, not a child's toy that has to sell through eye-candy. I know that this isn't the place for drama-queening. But still I have to say that if there is no way to revert back to the old look I will not use new versions of Eclipse and perhaps in the long run go and look for another IDE, as much as I would dislike that. This new look is just too disrupting to bear with on a long days work. Okay, after that rant I'd like to add that while I abhor the new look I certainly like the features that come with it, like the tear-off views, view collapsing/maximizing etc. Keep that good work up, but - to reiterate - please spare us that new L&F.
I like the new look and functionality om M8 (although I use square shape tabs) ... my screen is big enough that code takes up most of the space so the enhanced colours make it easier for me to focus as I come out of my coding haze. I think that it is becoming clear that people want choice, I hope that is possible.
Usability problems I'm a member of Java project team. We use CVS for version control. Most of the team members were using JBuilder for as development IDE. I and one of my colleagues adapted Eclipse as Java IDE. I like Eclipse and use it effectively But my eclipse newbie friends had difficulties. Here are some example complaints on working on our project: - Discovering how to check-out our project from CVS repository is difficult. When you first open eclipse there's no mention of CVS or anything like that in menues. New project wizard doesnt help at all because ther's no mention of "Checkin out project from VCS repository" They somehow have to find the little "Open A perpective" icon and "cvs" icon. - Luckily finding CVS perpective, another problem arises. Its tricky to checkout a "Java" project from repository, they've chosen the project module and chosen "Checkout" no luck, because it checks out the module but "not as a Java project" and its very difficult for newbies to make the checked out module to a Java project, but thats another story - Some luckily correctly checked out the module from "Check out as..." context menu, but this time they naively chosen the "Check out as a project in the workspace" but this also does not checks out module as a "Java" project as they expected. And there are no help or hint available on wizards. - After all this frustrating efforts some of them even refused to continue trying. - And even so, accssing to build properties, selecting source directories and library jars are also quite hidden. * There must be an easy way, to do or to discover how to do such essential tasks. There must be a list of essential "How can I ..." list * There must be a help button on all wizard pages and panels I'll try to watch a complete eclipse newbie to access the repository, checkout project and compile it, and take notes on errors they made.
I like the new "look with square tabs style" L&F. I think that there are enough people who don't like it around however, that it should be optional. R.e. screen real estate, It seems to me that this new L&F gives me better use of the screen, now that there is no perspectives bar anyore (yay!).
RE comment 174 Exactly what those who don't like the new L&F are asking for. Make the new stuff optional for those who want it, but don't force it down everyone else's throats... Thank you for being the first person I've heard who likes the new L&F and doesn't tell us "we'll get used to it".
I would like the list of editor windows (on the dropdown window) to optionally be in MRU order. I would really like for the editor tabs (if multiple editor tabs are turned on) to be in MRU order. It is very confusing to close a window and have no idea what window will pop to the front. And to open a new window and have no idea what set of editors will appear on the tabs.
all major work is finished here.
*** Bug 46236 has been marked as a duplicate of this bug. ***
