Community
Participate
Working Groups
Under the auspices of bug 52685 (continued from bug 37997), the look and feel of Eclipse was changed significantly. Many people have commented about problems with this new look and I won't repeat them here. Work has been done to address some of those concerns but it's still not enough. This bug entry requests that the original look and feel simply be restored to its M7 state. Unlike bug 52780 it doesn't ask for an option to toggle the look, because such options needlessly complicate the code, support, and documentation. It doesn't ask for one thing to be done for RCP and another thing for the Eclipse IDE. It recognizes that CTabFolder is not currently a native widget and that the classic look is not perfect, however it's much closer to perfect than the new look. Finally it doesn't say that Eclipse's look can never be updated, it simply requests that such updates be done with native look and feel foremost in mind.
In addition to what Ed said, I'd like to add the following: Please keep up the usability work that was started under the auspices of the new look. But please do it within the constraints of making sure that things still look and feel as "native" as possible. What do I mean by this? Some people have pointed out that the gradient title bars on Eclipse views aren't strictly "native." While it is true that these kinds of gradients on tiled subwindows don't appear in Windows applications, these kinds of gradients do appear on application windows. So there is a precident for that kind of UI ideom within Windows business applications already. Some have pointed out that Eclipse's tiled view mechanism does not have a precident within any other UI. However, this kind of tiled view can be viewed as being derived from the old Windows MDI mechanism, but with significant usability improvements. Also, people are used to working with tiled data in web applications, because that's the only way a web application can work. On the other hand, the only place you consistently see curvy lines separating views on Windows (and other platforms too) is in games. I'm not sure we want to communicate that Eclipse is just a game. ;-) So in my opinion there definitely is room for innovation within the Eclipse UI. But please keep in mind the current UI precidents, how they're used, and how changing various UI elements will change the things that people associate with Eclipse. --- I also am -1! on themes. If people want themes then they can use: 1) Linux/GTK 2) Windows XP 3) Swing where themes are already supported natively on the O/S and therefore in SWT. Any work on themes should focus on making Eclipse's UI innovations play nicely with the native themes and theme engines on the various platforms.
I'm voting for this as well as bug 52780 -- I would rather have either of these than the new look and feel. Note that if there is an option, the OLD L&F should be the default, not the new one.
I'd like to point out again that it is a very simple matter to make CTabFolder look native on windows xp. Just use DrawThemeBackground API call to render tabs and put as many widgets on top of it as necessary.
Please revert to classic look and make it look and feel even more native in windows. Because that is what our average serious-looking mildly-to-moderate- IT-savvy end-user wants. If this new look is enforced, the chance of getting Eclipse RCP adopted over here will be seriously jeopardised. What about depressed button in the main toolbar (similar to draw buttons in MS Word)? What about hiding the less important buttons and remembering which ones are shown (MS Word again)? These are native features that our users want.
i will go even further and say that native widgets should be used for tabs as well, even if it means no close buttons on them. there is a reason why microsoft implements widgets that way. i give microsoft its due, and they know useability. to say that a few eclipse developers know more about how a UI should look than microsoft and its billions of dollars poured into R&D every year is hubris. remember, this is an open-source project; please conform to the majority will and revert these changes quickly before someone utters the 'f' word.
>>i will go even further and say that native widgets should be used for tabs as well, even if it means no close buttons on them. there is a reason why microsoft implements widgets that way. i give microsoft its due, and they know useability.<< While I agree in general that Microsoft is pretty good about usability, I definitely don't think that they are the be-all-end-all as far as usability is concerned. The close button on tab example is one excellent example. I greatly prefer Eclipse's style: close buttons on tabs, than the alternatives. For example, Mozilla puts the close button way off to the right of all the tabs where it is not visually associated with the thing that it will close. If you put it inside the tab, you waste space, ... As a second data point, consider the successful third party applications for Windows such as Quicken. Intuit has made a business at least partly out of creating usability innovations that are quickly copied into Microsoft's products. (And Intuit copies Microsoft's innovations back, too...) I've been generally happy with the usability innovations in Eclipse up to this point because they have kept with the spirit of how native platform applications generally behave. It's when they go off and try to implement a whole new look and feel that I start to feel uncomfortable.
Re Comment 6 and the close button on the tab: unfortunately the close button does not currently waste space. (No that's not a typo.) Instead, the close button uses existing tab space. When I click on a tab, occasionally I happen to click to the right side, which causes a close button to magically appear under the pointer, and something unexpected happens. Very annoying, and bad UI design. I prefer the Mozilla style with a single close button in one place. I'm in general agreement with the first paragraph in comment 5 here. I'm also in agreement with the final paragraph of comment 6.
yes, i agree w/ #7. close buttons on tabs seems like a good idea 'on paper', but more often then it's worth, you close a window by mistake when trying to rapidly switch tabs. really breaks your concentration when you have to stop, find/navigate to the file that was open, reopen it, and find/navigate to where you were in the file.
[Is there a specific bug created for the tabs and/or thrie close button(s)?] I disagree - I have Mozilla and Firebird configured (with plug-ins?) so that each tab has its own close button. The reason I prefer this is so I don't have to drag my mouse all the way over to close a tab - it is usually already at or near the tab selector; the "single close button" design leaves the close button way out of the way. BTW, if you accidentally close a tab in Eclipse, simply use the editor navigation buttons on the toolbar to go back - they operate like a browser Back/Forward buttons, and "Back" will automatically re-open a closed editor if it was just closed.
re: comment 9, i use firefox, also, and it makes more sense to configure it to close a tab when the tab is middle-clicked. it's the best of all worlds; it's one-click closing, there's no possibility of accidently closing when switching tabs, the tabs are smaller without the close button, and you can use the native widget so you don't have to worry about making it conform to the OS look and feel. i suggested this earlier in the newsgroup/other bug, and i suggest it again here.
If you want to avoid moving your mouse, use Ctrl+F4 (and Ctrl+F6 to navigate). (In Firefox, that's Ctrl+W and Ctrl+Tab.) Reopening the editor with the navigation button isn't a problem: it's losing my train of thought in the middle of an editing session that bugs [sic] me: as comment 8 says, I still have to navigate back to where I was.
You all have been providing a lot of valuable input on the look and feel effort (and its impact to the rich client platform). Your comments have influenced our work so far, but we know there is more to do. We are going to spend the next week consolidating the feedback and adjusting our plan accordingly. We will have the updated plan by next Friday (Mar 5). Thanks for your patience and your investment in helping us make Eclipse as good as it possibly can be. I know we will end up in the right place. There has been a lot of discussion about this in many bug reports so I am pasting these comments several places. Sorry for the duplication, but I wanted to ensure maximum visibility.
I don't understand why a project that created a wonderful native Java windowing toolkit (SWT) is now implementing UI attrocities like application theming and emulated widgets. Themes belong at the OS level *not* the application level. If you don't like how Windows looks then use Linux or Mac but please don't implement yet another theme system. If I wanted tons of emulated widgets and themes I would never have stopped using Swing. It will be extremely frustrating trying to explain to customers why my Eclipse based RCP app looks and behaves strangely. The main reason I, and many others, chose the Eclipse IDE and RCP is because it understands that native integration into the host platform is a top priority for Java on the desktop. Please don't let down the community; use native L&F wherever possible.
re comment 13: you're preaching to the choir here; we all think the same thing. just like redhat forgot what got them to the top of the (U.S.) linux heap, the eclipse people seem to forgotten what got them to the top of the IDE/platform heap. virtually everyone i talk to (myself included) say what first impressed them first and most about eclipse was how *professional* it looked, and most people (myself included) were shocked that a java app could look so good (and native) and perform so well. adding themes and emulated widgets just adds to code maintenance without any gain. in fact it destroys what attracted most people to the product in the first place.
As a follow up for comment #12 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 (NOTE the wrapping of the URLs): 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
As per comment #15, since this clearly isn't the direction things are headed in, then this request should be closed and marked as WONTFIX or perhaps INVALID.
I like the new look and feel and the idea of themes(if you can goind to take it away). Things seem to tuck away cleaner and allow me to code. If I spend most of my days coding in this thing, I should be able to customize how this looks.
marking as WONTFIX, the request in this bug is in minor conflict with bug 52780 which is currently being worked on.
I almost fell of my chair when I learnt that Eclipse grew themes. This is the kind of code bloat that kills useful applications. Stop the madness. Theme support should be left to the underlying widget set (e. g. GTK+ 2). If you make Eclipse any slower or bigger without adding Real Functionality, you're going to annoy your users. The new UI was wasted man-hours that could have been spent bugfixing, instead of creating more. I also despise how 'cutesy' and Fisher-Price the default M8 theme is, let alone how much space it wastes with pointless curves, and the visual clutter of big, fat blue editor borders.
