Community
Participate
Working Groups
I could not see this as an existing separate bug request And it must be programmatically exposed to RCP apps that dont show WIndows- >Preferences
I think there should be a way of having both looks. specially for people doin RCP apps. Why throw something that *works* !
No argument (this bug does not ask to throw away the new code - simply that it be a choice for both IDE users and RCP apps). In fact I raised another bug request asking for skinning, so that I can make my IDE or RCP app look any way I like, from minor tweaking (remove gradient on view title bar) to totally outrageous (Blade Runner L&F )
In my experiences with our RCP consulting clients and additional discussions I had at EclipseCon, the new interface is a non-starter for RCP work. Non-native look and feel is one of the big issues with using Java on the desktop. The current, native look must be supported or RCP won't get nearly the adoption it deserves.
Regarding comment #2, if you want skinning, stick with Swing. SWT and Platform UI only need to provide the native look and feel, in my opinion. If the native OS supports skinning somehow (like WindowBlinds, themes, etc.) then that's different and should be supported through native mechanisms. Given there are so many votes on this bug (compared to 2 asking for the new look), I think what people *really* want is to revert back to the classic look and not have the new look at all. Then an option would not be necessary. Having two looks complicates the code, complicates support, and complicates documentation. Should we open a new bug for that?
I see this is now marked RCP instead of Workbench, and that the lead dev has changed, this subtley changes the meaning of the bug. I think that many IDE users will want the capability to revert to the classic L&F. I merely emphasized that it must be exposed programmatically as well as through the IDE UI - not only for RCP devs.
Ok, I've added bug 52875 to request an unconditional reversion, in the entire UI not just for RCP.
I've been using the new look since M7 was released, I wanted to give it a fair go before I knocked it right away. The intention of reclaiming lost space due to the constraints of rectangluar windows and full width view titlebars is laudible, but i think the execution falls somewhat short. The tab-like title bars are nifty and help in that they remove the need for a somewhat redundant tab list at the bottom of the view, however they introduce the unfortunate "fly-out toolbar." The tabs fit a common physical and UI paradigm, but the fly-out does not and that makes the app look foreign. Finding a more familiar way to incorporate the view toolbar might go a long way to remedying the problem. With respect to comment #3, we never really had a 'native' look and feel for the views in the first place. The 'old-look' views were only constrainted approximation of MDI that had no real counterpart on the OS. So I'm all for an effort to see how that can be accomplished with a greater degreee of efficacy, but I think that the current incarnation is more alien than effective. So I'd suggest the old look be the standard, but the new look still be iterated upon and made an option for early adopter types to critique and provide feedback on until its ready for the average user.
I'd like an *option* to revert for the entire UI, and that's what I voted for here. The originally intended scope of this request was not exclusive to RCP. Please de-classify as RCP.
I would prefer to see the new L&F be the option that had to be enabled explicitly. Make the "classic" Eclipse look the default and let those who want eye candy choose this new stuff if they want it.
We interpreted the original entry as being mainly a request for RCP API, but based on the above discussion that does not to be the case. We feel it's better to treat these as separate issues (bug 52875 not withstanding). I'm reverting this one to be about having an option (preference setting) in the Eclipse SDK to control the overall look (classic vs. new), and have entered bug 52892 to capture the need for RCP apps to have a L&F that's closer to classic. Please distribute your comments and votes accordingly.
i just saw the new look - wow, seems like eclipse is defeating its own purpose +1 here
I have lost track now of these bugs. I think the main thing to take away from all this is a) a lot of people really dont like the new L&F (and remember that the vast majority of devs havent seen it yet) b) they will vote for anything that makes it go away c) and RCP people really hate it d) see b Dont take the votes for each bug as a decider on the specific outcome, the distinction between them is not all that clear. I agree with Ed that making it a run time choice might be lengthy, complex and buggy (not to mention a maintenance nightmare). In that case just back the work out. However some people seem to like the new look and the devs put a lot of work in; so if its a no brainer then keep it.
I don't know exactly where to vote, there seems to be quite a few "bugs" entered for this new look thingy. So I just want to chip in my 0.02 RMB here. The new look turns me totally off! We hate it, and we want to have the look as it is now. One reason we walked away from developing our apps in Swing is that we want our application to look exactly like other apps. If anyone wants the new look, please give them the option to turn it on, thru eclipse pref page or thru any API flag. But we want the current (classic) look to be the default.
I have just finished re testing the new look and feel in order to validate my first reactions. My conclusions have not changed and I have grave concerns about the implications of this L&F for RCP applications. There are many small concerns which I shall refrain from detailing here, but the accumulation of these is that all applications based on the Eclipse platform will inherit an "Eclipse-style". This is something we had not anticipated, indeed the reason we chose Eclipse as a platform for our tools was its application-neutral interface. This neutrality has been reinforced by the RCP-effort to remove "Eclipse" specific detail (the project menu, for example), in our view the new L&F is going against the grain of this effort. For these reasons, it is imperative that RCP developers are given the option to revert the original L&F. This comment is not intended to diminish the hardwork of the L&F team, some important and valuable ideas are evolving, however it is important to ensure that the broad spectrum of the requirements of Eclipse users' are not compromised.
James, please see bug 52892 [RCP] Workbench look and feel for non-IDE apps.
I'm voting for this as well as bug 52875 -- 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.
classic look and feel should be default
Give us options a) classic b) new (evolved ) Majority of devs will take (a) The classic look is the major reason why eclipse rocks . Its self defeating to have some thing which doesnt look like my current desktop application . The major reason for having a SWT app is the look and feel and you are taking it away without givin a option .
+1
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.
*** Bug 53369 has been marked as a duplicate of this bug. ***
+1 vote. BTW, another reason is in the bug #53370 (tabs bar still shown when only one tab (unstacked views))
As a follow up for comment #20 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
Regarding this point :- "5. The argument around native vs non-native controls is more about meeting the user's expectations than whether or not the chosen widget is supplied by the operating system. " This is the swing argument - "who cares how its works as long as it looks like the OS" The points that this misses are a) If the platform changes (new theme for example) then an emulated widget wont change with it b) the behaviour is never quite the same c) it performs worse
I agree with the previous comment. It seems like there's suddenly been a major change in Eclipse's UI philosophy from "use native controls wherever possible and supplement with native-feeling custom controls where necessary" to "give 'multiple rendering options' including possibly using native controls". Seems like a real loss to me. It throws away the major tenet that made SWT interesting in the first place, Java applications that look and act like native applications. If you're going for 'multiple rendering options' you should've just stuck with Swing rather than invent a new platform. All told I was pretty disappointed with the response. The gist of it seems to be "we heard your complaints, we'll make some tweaks but for the most part you're stuck with the new UI so deal". Yes you'll give us options to hide some parts of the new UI, but by default Eclipse will no longer look like a native application. That's a shame. It's also a shame that the reaction of the user community evidently carries no weight with the Eclipse UI team. One of the justifications for this was "to ensure that the eclipse user interface remains vibrant and current", personally I'd rather the goal be "to ensure that the eclipse user interface is functional, efficient and seamless". If I want vibrancy and currency I'll pick a new theme from my OS.
Comment 25 -- well said!
Re: Comment 24, I see your argument about point #5. The offending lines have been removed from the response. Let me reiterate how important and fundamental SWT integration is to eclipse. It has been, is, and will be essential for eclipse use native controls. There is exactly 1 new custom control in the 3.0 builds (the separator for the perspective switcher) and as was outlined in the response, there will be an option (not yet implemented) to allow you to remove the curve. Every other control has either always been a control that the eclipse team has created explictitly for the eclipse UI or is a standard SWT widget.
Comment 25 well said ! may be our reaction doesnt carry any weight
[quote] Supporting both the old and new look implementations is difficult. There are underlying technical reasons why supporting two “look and feel” implementations in the workbench is not only difficult to implement but also will lead to significantly more resources to test and maintain the code, putting the team in a very difficult situation when they are inevitably asked to back-port enhancements. [/quote] What makes a new L&F so important that it outweighs the cost of "significantly more resources"? Is there a reason why the team prefers to be put in "a very difficult situation", rather than just maintaining a single L&F? Personally, I'd rather these resources were used more functional areas. [quote] The goal is to end up with a polished UI that ... new users can quickly become comfortable with. [/quote] A reasonable expectation might be that users are already comfortable with the L&F of the platform they are using, and yet (to paraphrase the above) it is a goal to end up with a different UI that users are (at least initially) not comfortable with. Hmm.
Comment 29 is right on. I don't hear lots of people asking for the new L&F. In fact I hear lots of people *objecting*. We've had almost three years to get used to the current L&F, and lots of folks really like it. If it's so hard to maintain two L&Fs, drop the new one, and instead make some subtle changes to the old to answer the original (vague) bug report. Things like * make the tab selections more obvious (but keep them looking similar) * give an option to move the perspective bar as a normal toolbar
I'll just chime in with one last observation here. There seems to be some consensus among some of these comments that the motivation to push forward with the new L&F, even in the face of much vocal criticism, is unusual. The thought occurred to me that this pressure to go against the grain on this matter might be coming from inside IBM. Perhaps the new L&F is really all about developing a new L&F for the *WebSphere* IDE (WSAD customers may have expressed a greater desire for UI changes than the Eclipse community has), and having the Eclipse team do the work is probably much cheaper than doing it in-house. That said, I don't mean to accuse anyone in IBM (I'm ex-Big Blue myself) or start any conspiracy theories because we know that many parties are pushing their own agendas in the Eclipse project, and that's what it's about really: community involvement. I only hope that one party doesn't hold too much influence over the direction of development.
Well, in theory there is always the possibility for a fork of eclipse.platform.ui...
re comment 31: no, i don't think it's an IBM conspiracy, i think it's just ego. i think Mr. Van Meekeren (mostly he, it seems) committed a lot of time and effort to this new UI and he is one of those people who refuses to admit when he is wrong. my guess (and my guesses are mostly right ;) is that he's a smarter-than-average person, and like many smarter-than-average people he assumes he knows what's best for everyone. unfortunately, like many similar people, he confuses what works best for him with what's best for everyone. and he's determined to do what's best for everyone whether they want it or not, and even if he has to use his position to try to bully people into it. he's hoping that if he forces people to use the new UI now people will get used to it, then like it, and therefore he will be proven right. unfortunately for him (and us), taking the approach he has taken ensures that he will never be right, simply because people don't want to be forced into something whether it's 'good for them' or not. so the masses will now never support the new UI no matter how good he thinks it is. ok, i put away my amateur psychology book now. :)
Guys, please keep your discussions objective! Eclipse is developed by a several teams and especially the new look is not the result of a single person. Nothing is done without the admission of a PMG or something similar.
ok, i change my vote to 'conspiracy theory', then. :)
+1 comment 25 and comment 29.
I am just going to be speaking in terms of Windows XP here, as it is the platform I run the IDE on the most. I am concerned that Eclipse is moving away from the native L&F with the new UI. I find the new blue border highlighting scheme, popup to navigate between tabs, and curved tabs both ugly and disimilar to other native apps. I'm a big fan of Eclipse over Netbeans, but surprisingly Netbeans 3.6 beta has a more close L&F to Windows XP *in these areas* than Eclipse appears to be evolving to. In particular, the new XP L&F in Netbeans uses the "orange line at the top" of the tabs, a more "Windows XP" looking gradiant on the tabs, and a tab management system that looks more like, say, Microsoft Visual Studio. If you're going to evolve the Eclipse L&F for RCP, please focus on making it look more like the native platform, rather than going in a whole new direction.
I would prefer the option to revert between the old L&F and the new L&F. +1
I preferr the new Layout, if the Layout runs fast on old maschines too. +1
I prefer the behaviour and look of the new layout. Should this vote be counted as -1 then.
Eclipse' biggest UI problems are: 1) Need for vertical editor tabs; due to horizontal fitting only ~8 readable 2) Flawed idea of 'follow with editors' when single-click on debug stack trace - I'm clicking to close and could dbl-click if I wanted to see 3) Mouse scroll wheel requiring focus, and click, and editors changing etc - All I wanted to do was see further down the stack trace. None of these would appear to be effectively addressed by the L&F stuff. (I want vertical editor tabs visible all the time, not some drop-down). I also regard the current L&F as of fairly high functionality and professionalism. Since this direction of L&F work doesn't seem to address what issues are significant, and offers small/ arguable benefits, I think this should be shelved until more important usability work is completed. I have no beef with tearaway views or support for people's dual monitors though. Regards, Thomas
to comment 41: >1) Need for vertical editor tabs; due to horizontal fitting only ~8 readable you should propose instead to eliminate icons, use smaller font, stack tabs (2 or 3, or N rows, according to a user pref) >2) Flawed idea of 'follow with editors' when single-click on debug stack trace > - I'm clicking to close and could dbl-click if I wanted to see No this is perfect as is, BUT should require a ctrl-click just like navigation (I think it was ctrl-click some versions ago...) >3) Mouse scroll wheel requiring focus, and click, and editors changing etc > - All I wanted to do was see further down the stack trace. Your mouse driver sucks. Use a better one. You should NEVER have to click to scroll. Hovering while "mousewheeling" should give focus to component underneath. I use logitech 9.42 (exactly 9.42, no younger, no older). (if only drivers were open source...)
I've been using this new look for a week now, trying to give it a good "objective" evaluation (not very objective as you might guess, as I have more or less my mind made up). But anyways, here's what I think: - it looks like a half-baked keramik theme (which I hated). Why half-baked? Everything is classic style, and flat (if you use the simple theme in Gnome like me), but the tab and the frame surrounding it is roundish, and just pop up in your face. If you want to have this kind of L&F, at least, be consistent, and make it that way _everywhere_. - Did I say the color scheme seems at odd with my overall desktop theme? And I'm using a very conservative theme now. I don't want to imagine how it would look like if I switch to my Matrix theme. - What's wrong with having tab in the editor title area, instead of giving the whole title bar to one single file? There's a ">>" symbol to show how many files are open, but the worst part of this is that it's just right on the right side of the "X" symbol, which closes the file. I usually use keys to switch between open files, but I do click sometimes. And 3 out of 5 times, I have my file close instead of the drop-down list. The classic style has the problem that if you have a lot of files open, they are jammed together. However, you can control it by setting the max number of open files. I found that 10 open files is the most that most people can track anyways. - Theoretically, it's nice to have the whole path of an open file displayed on the title bar. But most of the time, that's way too long, and instead of helping the user, it just contributes to the busy-ness of the GUI. If you must have this, at least, provide a way to configure or format what is display there, a la Emacs. But how would you apply this preference to all editors, including GEF editors? - I think the perspective icons on the left side is a better idea (classic style). It conveys to the users the idea that a perspective is not a function. It's a different thing. Now, all your function buttons are below the menu bar, and what functions are shown depends on which perspective you are in. The two things are othorgonal. But now, the buttons are at the same place? - This new look eats up more real estate that it needs to, just like keramik, thingeramik, and the WinXP look. Sorry, I want every inch of my desktop real estate, I work on a Thinkpad laptop, not a 21-inch hi-res LCD with a monster graphic card. I want it clean and simple. A couple of these problems are simple to resolve, but the biggest problem is that it is half-baked. I'm not trying to discard the efforts of the developer(s), but please do not check in half-hearted attempt like this. More people would like it better if at least, it looks consistent. Ok, now can I turn this off in the code?
This is now the 4th most voted for bug - and the code hasnt even shipped to the wide world yet. Despite that the response is "We already did all this neat stuff which a couple of people like - we are not backing it out" So much for the open source 'community'
Hi Quartz, people, thanks for your comments, I think the multiple editor issue is *really* important. Switching editors would probably be the most-used 'surface' of the user interface, besides the text pane itself and perhaps the outline view. So we are talking priority A1 here. This surface has *absolutely* to be clean, functional and immediate. Vertical editor tabs: > you should propose instead to eliminate icons, use smaller font, stack tabs > (2 or 3, or N rows, according to a user pref) Icons, small font and intelligent multi-word abbreviations would be partial workarounds. Stacked tabs are worthless rubbish the moment those tab lines start moving. Drop-down lists also act against human positional memory and navigational abilities. Try driving around a city where the landmarks disappear when you put the map away. And I have almost zero general need to see path names. Vertical tabs would not be a workaround but a totally effective and preferred solution. Vertical tabs are 'ergonomically correct' in a large range of situations where horizontal tabs or drop-down lists are definitively not correct. I've used the editor management & pinning, I use the Window palette, I use Open Resource, I use back/ fwd, I use back/ fwd dropdowns, I use manual closing sweeps, I use all of these workarounds to try and find the windows I'm working in. None of this is a satisfactory solution to what doesn't have to be a problem. In fact, my main and constant practice is to use Ctrl-Shift-R and type the name of the file I'm after. I'll already have the file open in an editor; but Eclipse's tabs just become completely useless to find files among, as a matter of course, in standard work situations. Vertical tabs would scale to 20+ files. My needs are in the range of 6 - 15 files. There is no other solution. I can't believe how core this is to basic editing work and how much time can be wasted trying to find what's already on screen. 'Follow with editors' when single-click on debug stack trace: > No this is perfect as is, BUT should require a ctrl-click just like navigation > (I think it was ctrl-click some versions ago...) If it worked that way, which you say it should work, it would be fine. Mouse scroll wheel requires focus and changes editors: > Your mouse driver sucks. Use a better one. You should NEVER have to click to > scroll. Hovering while "mousewheeling" should give focus to component > underneath. I don't want to give focus to the stack trace, or outline view, or whatever; I just want to see further down the list. My time finding things and locating editors where I'm working is precious. I work only on medium size projects but still have substantial costs in 'wading' thru files and the code body; much of which is added by unintelligent Eclipse behaviour.
I would like to update my previous comment in light of 3.0M8 to say that I am very pleased with the new look and feel on Windows XP save one area: tabs should highlight using an "orange line at the top" like the majority of native Windows XP applications. The solid blue tab is a unique look, but that doesn't mesh with SWT's premise of integrating with the native look and feel. Otherwise, I like the changes made and appreciate the flexibility in configuration that we see in M8. Nice work.
*** Bug 56474 has been marked as a duplicate of this bug. ***
i'm not sure bug 56474 is a dup. it appears he's asking for the ability to use win2k widgets instead of the winxp widgets?
ack, i need to read better before i open my pie-hole. it looks like he was using win2k/winXP as an example...
regarding Comment #46 , are you saying you would like an orange line at the top of tabs specifically, or that you like it when tabs highlight themselves when the mouse moves over them?
Created attachment 8985 [details] Image of Native Windows XP Tabs I think this might be what Ben means. Ben: do you want the selected tab to still have a blue gradient background colour as well as the orange highlight?
Created attachment 8987 [details] Illegible Win2k CTabFolder tabs Using Windows 2000 and the default colors results in CTabFolder tabs that are illegible (black text on navy background).
Created attachment 8988 [details] Excessive gradients I find the use of juxtaposed vertical and horizontal gradients as shown here in the Java Browsing perspective to be visually distracting at best. The effect is worst when there are a large number of tiled views open.
...on the other hand, I like moving the perspective switcher to the upper right. However, how the perspective buttons look kind of like tabs, so I expected to find a close button on them just like are found on the view tabs. I also like the way you can collapse a view, but I also wanted to be able to "pin" a view in the collapsed position so that when it loses focus, to collapses again automatically (just like the fast-views used to hide themselves automatically upon losing focus). This is really useful for fast access to things like the Console view that you need badly when you need them, but that are a useless waste of space most of the time.
The new look is much improved in M8, Kudos! If improvements keep being made at this pace, I think things will work out in the end. I like the new widgets to min/max the views. Would there be any possibility of putting the close widget in the same grouping and then possibly you could use the native tab widgets from the platform OS for the tab itself. If that could be done, wouldn't it resolve the majority of the complaints? I would like to see the native XP tabs, as an example, but I would hate to see you try to do it through emulation. Why not try to redesign the UI in a way that would allow the native widgets to be used without losing the functionality that you wanted to add?
ditto on comment 55. the new defaults/look is quite tolerable. excellent work on improving it based on the feedback. the added functionality is excellent. also, the close/max/min stuff is already on the context menu, so there can be an option to use native tabs without losing anything...
RE: comments #50 and #51 Sorry for not being more specific in my comments. The attachment Douglas provided illustrates exactly what I meant to advocate: no blue gradiant, and the use of a orange bar across the top of the tab to indicate selection. For examples of this look and feel on Windows XP, please see the tabs on the "System" control panel, tabbed browsing in Firefox 0.8 (www.mozilla.org), or the tabs in Netbeans 3.6 under JDK 1.4.2's Windows XP Swing L&F. (I'll add that the orange bar appears temporarily on tabs as the mouse hovers over them, indicating that a mouse-down will perform selection. This behavior occurs even in the Windows XP Swing L&F and the Firefox browser (using XUL?).) I'm not sure how specific this L&F behavior is to Windows XP vs. Windows 2000. To my eyes the blue-gradiant tabs stood out as "non-native-looking" under Windows XP. I feel very nitpicky bringing this up; M8 is fantastic! Thanks for listening to my feedback.
+1 for the "orange highlight" tabs. The editor tabs in M8 are too close together. In Windows XP, there is a small gap between unselected tabs. A selected tab has no gap on either side, but is taller by the height of the orange highlight. Both the System Properties tabs and the Firefox tabs do this and look good, whereas the M8 tabs are insufficiently distinguished from each other. Also, I still don't like the way that close buttons appear out of nowhere. Firefox does this right with a single close button on the right, but I'm pretty sure that's a personal opinion. :-) (For multiple rows of tabs, moving the rows when a tab is selected (as in the XP System properties) is bad.) The tab highlighting also applies to the "Problems", "Ant", "Console" etc views, which I have overlapping. However, these tabs are worse because they change size when selected. Please don't do that. In summary, do what Firefox does. :-) (I'm not sure why rounder, less well defined arrows are better than the sharper arrows: now some icons are sharp, and some are rounded, but that's relatively minor. :-)
logged bug 56733 against SWT for highlight support on tabs
Now that this has quietened down (asn we can see M8)I'd like to summarize where we are. I will attempt to keep subjective feelings out of this (although its a struggle - we all get very attached to the tools we use , especially if we REALLY like them). 1. THis is the third most heavily voted for bug in eclpse ever. People feel very strongly about it 2. M8 fixed a lot of the really bad things from the previews. But the fundamantal changes remain 3. we are left with something that looks and feels quite different from 'classic' eclipse. <emote> 4. It looks like a toy, feels clunky and cheesey and has no benefit. I get tabs for things that dont need to be tabbed (single view). Things that used to be in fixed places (close view) now move around. The clean simple crisp UI of old is replaced by something that I would fire my devs for creating. AAARRRGGGHH. I used to smirk at all the other toy IDEs , pitying people who had to put up with such flaky UIs full of needless trimmings, whereas I used a slick clean tool that looked great, now I am in that state too. :-( The explanation of keeping it seems to be - we already wrote the code so we are going to keep it. How about spending this effort on the fact that GTK eclipse is unusable on linux. </emote> So my question is - is there any intent of doing what this bug asks for? Please
The new l&f (even in m8, where it's better) has opened SWT up to criticisms like those at: http://homepage.mac.com/spullara/rants/C1464297901/E1351958235/index.html To quote: >>>>>> Eclipse needs to switch to Swing before SWT really gets out of hand The latest release of Eclipse (3.0-M8) now has custom look and feels. The default one is pretty random and doesn't look like my Mac. For some reason, many moons ago, I thought the reason for SWT's existence was two-fold: 1) Look like the native platform using native components 2) Higher performance than Swing On the Mac platform it now has neither. Swing both looks the same as the native platform and performs better than SWT. Will they please just give it up and switch to the standard controls? Can anyone explain why SWT still exists? <<<<<< I know that he's confusing SWT and JFace, but people *perceive* Eclipse to be the premier example of a SWT application. One of the things Eclipse customers have prided themselves in is that you generally can't tell that Eclipse isn't a native platform application, yet it's written in Java. Consequently, I am *still* very concerned that we are shooting ourselves in the foot here...
another point about the UI It makes views and editors look the same (the tabs are the same size , shape, place,etc) but the rules for them are different. I can drag a view anywhere I like but not an editor page This is confusing to a new user Also having the tabs change size I select them is very distracting Why do you add the view icon to the selected tab. Having an icon in the top left of a view was OK - always look in the same spot and you can see what it is. Since it dances around now there doesnt seem much point (and its the main reason for resizing the tabs). And whats with the enourmous X for closing things. For everybody else a simple X is good enough
Time for me to pop back in again... Again I must ask that y'all respect the obvious, overwhelming, VOTED opinions of those who want the *actual* old L&F back, *not* at attempt at an emulation. I've tried using M8 since it came out, and while I like a few features (like the tear-off views) I still can't stand the eye candy and quikry behavior. Here's a quick list of my opinions. In short, "ugly and awkward" sums things up pretty well for me. Eclipse has been my tool of choice for almost three years now, and now many of the things I liked about it are ugly and hard to use. Some things I hate * The ugly, "look at me!" tabs. Ack! * The chevron -- just keep the tabs like they were before or give an option for those folks who wany multiple rows of tabs. I clicked on the "hierarchy" tab and the "package explorer" tab turned into a chevron -- I wanted to just click and click again to return but now my thought process is interrupted because I have to think about "where did the package explorer tab go??" * Progress status is nicer now, but for some reason I really want it on the left side of the status bar... * Placement of the perspective switcher -- way awkward to use * Pane borders (I still want the 3D "floating" look back -- it fit well with the presentation of menus in Win XP) * No title bar in views when view tabs are placed at the bottom * Making all of the changes the defaults -- LEAVE THE DEFAULTS AS IS, LIKE PLACEMENT OF VIEW TABS! If someone wants the new eye candy mess, THEY should have to change, NOT ME. * Full page welcome screen is confusing -- where did my workbench go? -- Keep it a view like it was before; it was nice and you don't need that much room... * Having to click twice to get to synchronize view (ok, not really an L&F issue, but it really annoys me... gotta open a bug on that) Things I like but could be done with the old L&F: * Better D&D feedback * Tear-off views BUT: You must drag the tab, not the title bar -- very confusing if the tab is on the bottom (where it belongs by default...) This is really bad once you've move it out, as you have to drag it around by the tab at the bottom of the window when it looks like there is a perfectly good title bar area available * Progress feedback using tab font styles * Workspace chooser To be honest, I can't decide if I like the new icons or not... -- Scott
RE comment 62 -- I couldn't agree more. Keep the tabs the same size when you click on them. Rule #1 of GUI development is don't change the GUI while the user is interacting *unless* they're explicitly choosing a widget that is used to change the GUI. (So clicking on "resize" should change the GUI, clicking on a tab should change the visible pane, but controls shouldn't randomly change size just because I clicked on them. As for the "X", why not just put it in the right-corner of the title bar like every other reasonable tabbed-document app out there? It allows someone to rapidly close multiple windows with a few mouse clicks... -- Scott
#64- The X used to be in the right place (right hand corner). Didnt move, correct size, .... M* decided that everybody else had it wrong
The more I work with M8, the more I've been wondering if part of the reason for the new L&F is to make Eclispe look more "at home" on Windows XP with the default "bubblegum" theme... Given the relative marketshare directions of Windows XP and Win2k and the popularity of Keramic on Linux (the default KDE theme that presents a similar style to the default XP theme), this would be an understandable goal. But it also appears to be much more difficult to do this well than to do the previous conservative implementation well--where well is defined as, "This thing really blends well with arbitrary platform X" where platform X uses a less visually aggressive theme than the default XP theme does. Gnome and MacOS X both use a much less aggressive set of colors than XP's default theme and Keramic. They also seem to use gradients differently. And then there's venerable old-and-mostly-stable Win2k, that still pretty much uses the Windows 95 look and feel, with an occasional gradient in the title bar area... A L&F that will blend well with all of these platforms would seem to need to take all of these things--aggressive versus conservative color choices, use of gradients or lack thereof, positions and functions of gradients--into account. If you are in fact trying to do what I'm suspecting here--make Eclipse look more at home on OSs with more "modern" (read: aggressively-styled) themes, then I can respect that. After all, I use Keramik at home on Linux. But please don't leave everyone else--Win2k, MacOS, Gnome--behind in the process.
Heres the point. Eclipse already matches win xp perfectly - since it is native, it just works. You have to install a manifest file to tell xp to theme it, it then looks just like any other windows app running under win xp theme. Turn XP mack to classic L&F - eclipse goes back to classic. Awesome, magic, ... this is why SWT is sooooo good. Now under m8 it looks a bit like m8 all the time on any platform whether you like it or not (which is where we all started - swing metal l&f - yuuuk) I shudder to think what the Mac people think of this
Hi people, Scott, Thanks for your opinions in favour of functional UI. The user interface is our direct work surface which all our daily tasks must go thru - editing, debugging and navigation within current task and projects overall. > * The chevron -- just keep the tabs like they were before or give an option > for those folks who wany multiple rows of tabs. Well, vertical tabs would be enormously more usable than any multi-row layout. I don't know about the rest of you, but switching between open files is a core part of my editing work. People need to be able to see *currently* on screen what files they have open. This is more important than the Package Explorer or Navigator which consume a lot more real estate. Now this requirement for direct visibility, rather than drop-downs, is really a requirement of the way human interaction and positional memory work. You can't hide or rearrange the list because it breaks the memory and the instinctive usability/ findability of that file. The other benefit of vertical tabs, as well as not truncating file names to be indeterminate, is that they scan visually rather well. Even better than a horizontal layout were everything to be fully visible. This has got to be in the top-5 usability. Is there any other window or control which anybody uses more frequently than this, other than the editor itself???
As a CC comment - I do like how the new L&F fits into XP overall L&F. Maybe it should be the default on WinXP only.
Noooooooooooooooooooo.................... I don't think it really fits with XP at all (I run XP, and it just doesn't look right, esp the tabs). Again I say the defaults should not change. If people want changes, they should change their settings. Those of us who want things status quo should just get status quo without having to change back to it... -- Scott
I have always preached to doubters about Eclipse's open-source nature and how responsive to the community the dev team is, accepting patches and feature requests from ordinary users, etc. It seems very clear to me that this "new UI" issue is proving to be the big exception - looking through thhe numerous messages, there is little response to the criticism "why change what is not broken" and the other philisophical questions raised here. In fact, there doesn't seem to be much in response from Eclipse developers at all. Sad to say, but it appears that this issue is being pushed aside even though a significant portion of the community is in outrage over it. I have to wonder why...
http://www.eclipsepowered.org/archives/000052.html refering above link ... Eclipse (itself )should be flagship of RCP . Rather eclipse itself was the real proof of java desktop applications. The classic look was fabulous ,slick ,fast and native.
The new look is much more polished over the six weeks from M7 to M8 (by any measure). If this progress continues between now and when 3.0 ships the result will be truly amazing. Our goal is a more functional, scalable, multi- platform, easier to use and easier to learn base for not only IDE's but generic applications as well. This is a lot of work, but possible if all of us stay focused. It has been interesting to see the response to M8 not only in defect reports like this but also in the wider community. The first posts after M8 was released in this defect report was: https://bugs.eclipse.org/bugs/show_bug.cgi?id=52780#c46 A defect has been created by Mike to improve tab highlighting. (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=56733) A few more comments in this defect report have been generally positive as well: https://bugs.eclipse.org/bugs/show_bug.cgi?id=52780#c55 https://bugs.eclipse.org/bugs/show_bug.cgi?id=52780#c56 Now that M8 is out it is also interesting to see the reaction to M8 in the broader community. For example: http://www.theserverside.com/news/thread.tss?thread_id=24749 http://www.eaves.org/blog-archive/000060.html http://www.laurentm.com/10Goto10/archives/eclipse/000109.html http://jroller.com/page/BillDudney/20040331 http://jroller.com/page/cblackbu/?anchor=eclipse_m8 http://sys-con.com/story/feedback.cfm?storyid=44278 http://www.redtailcanyon.com/items/42564.aspx <== My personal favorite "... putting lace on jock straps ..." http://www.eclipsepowered.org/ http://www.eclipsepowered.org/cgi-bin/mt/mt-comments.cgi?entry_id=52 http://www.eclipsepowered.org/archives/000045.html http://www.ryangrier.com/news/archives/000329.php http://homepage.mac.com/vineetb/iblog/C684524823/E493671520/ http://www.scottishdevelopers.com/modules/newbb/viewtopic.php? viewmode=flat&topic_id=294&forum=3200 http://www.corvine.org/blog/archives/000008.html (You can find more of these by googling "eclipse M8") So, where does this leave us? The general sense that I get, is that while M8 has bugs (many not related to the UI changes) and there are UI elements that can be further improved, people generally like the changes. We won't have universal consensus - there will be those who have issues with the 3.0 UI, just as there have been with 2.x and 1.0. That's ok - and we still need your input. To keep the momentum going I'd like to encourage everyone to continue identifying specific problems (like the problem with tab colors), enter defect reports, submit patches etc.
>>To keep the momentum going I'd like to encourage everyone to continue identifying specific problems (like the problem with tab colors), enter defect reports, submit patches etc.<< Bug 58059 added.
How can you POSSIBLY say "people generally like the changes" in light of all the negative posts in the newsgroups and the votes on the "against" bugs!!! Do you have numbers? Evidence of some sort? I have to say that I really respect the amount of work y'all do on Eclipse, but THIS IS REDICULOUS! How can you totally ignore the numbers in front of your face and have the gall to say "people generally like the changes"!?!?!?!?!??!?!?!?!?!?!?!?!?! I'm absolutely disgusted! How can we make it more clear: TONS OF PEOPLE ***HATE*** THE NEW L&F!!! COUNT THE VOTES DAMMIT! -- Scott
Comment #75 is right. You can't skim a few blogs and claim that their contents are representative of the Eclipse user community. Even if the sentiments of a few loudmouth egotistical self-styled pundits somehow accurately reflected the total picture of public opinion, they haven't *voted*, so their voices can't be objectively measured. Our voices here, however, *have* been objectively measured. This question has been raised time and again: Why does the Eclipse team continue to ignore hard *numbers* in the form of votes, instead touting some ephemeral Eclipse community "zeitgeist"? This is beyond reasonable. And once again, I have to ask, because the longer this issue continues, the more inexplicable the reasons behind it seem: Who is behind this "momentum" you speak of to change the UI from a native L&F to something which defies the very reasons for SWT's existence? Exactly who is pushing so hard for this that hard numbers are ignored? We deserve an unambiguous answer to the following: Is IBM behind this? Are they looking to "improve" WSAD's UI in the face of competition in the IDE marketspace, and so decided to use the labor of the Eclipse team to do carry out this commercial agenda without having to spend their own money? If none of this is true, please enlighten us because I am having a hard time imagining any other rationale.
>Our voices here, however, *have* been objectively measured. Sure and I also think that the look still don't look native but you can't just hang on the votes in this bug. It's not really comparable because there is no bug for voting "pro" the new look. Remember that event not every Eclipse user is automatically an active bugzilla user. The only chance to solve this is to start a survey on www.eclipse.org. >We deserve an unambiguous answer to the following: Is IBM behind this? >Are they looking to "improve" WSAD's UI in the face of competition in >the IDE marketspace, and so decided to use the labor of the Eclipse >team to do carry out this commercial agenda without having to spend >their own money? You are mixing up things here. Althoug Eclipse is an open source product it's development is still supported by companies (Eclipse.org members). The _major_ part of this finance effort is still spend by IBM (FTEs, hardware, software). Look at the comitters. Most of them are "@us/ch/fr/ca.ibm.com". Eclipse development is their full-time job. Thus, IBM is already spending a lot of money to support Eclipse development and believe me, not all of IBM are happy with the new look. Especially the RCP clients were unhappy but they now have options to render the Eclipse UI the way they like.
> The only chance to solve this is to start a survey on www.eclipse.org. I agree with this. Lets ask the general community. I suggest that the survey include the platform they are using as I'm sure there will be large differences across platforms.
Well, I do quite like the new UI in some aspects. It is more spacious and sophisticated in appearance. Folding tabs and window-menus into the same bar works at least fairly well for subsidiary panes, as does integrating perspectives into the toolbar. These combine to give a significant and useful increase in square-inchage (tm) for the development surface. The blends seem to me to be reasonably slick, the curve slightly less so. I'm working with Eclipse maximized so there are few conflicting OS elements visible. However the slick non-linear elements are, by the number of colour/ contrast/ gradient curve/ orientation factors involved, always going to have the potential to differ from OS l&f. Unless we have a 'UI tweak window' with banks of slider controls for UI details? But one major aspect of the new UI is tab treatment. And this requires different interaction & UI design solutions, for the edit pane tabs, from what this L&F program is delivering. So I'd like to thank the Eclipse team for their work and I am pleased with the space improvement, but my number 1 Eclipse issue is still the 'blindness' and unusability of editor tabs. Cheers, Thomas
>>Our voices here, however, *have* been objectively measured. >Sure and I also think that the look still don't look native but you can't just >hang on the votes in this bug. It's not really comparable because there is no >bug for voting "pro" the new look. Actually there _is_, it is called something like 'evolving the eclipse user experience'. And it has 18 votes...
For your convenience, here are the bugs Luc is referring to and the current bug counts as of this writing. Most comments are going to bug 52685 and bug 52780. This is not a complete list, just the ones I found with the most votes. Original bugzilla entry: Bug 37997 - 18 votes Continued entry because there were too many comments on the first one: (people were asked to vote for this if they liked the 3.0M8 look) Bug 52685 - 1 vote Request to add a preference setting in the IDE to revert to the 3.0M7 look: Bug 52780 - 93 votes Request to revert back to the 3.0M7 look in the IDE unconditionally: Bug 52875 - 54 votes Request to revert back to the 3.0M7 look only in non-IDE applications: Bug 52892 - 20 votes Update look to most recent native look: Bug 51628 - 5 votes New look not good on Mac: Bug 56476 - 4 votes List of all bugzilla votes: http://tinyurl.com/63mp
I like the new look and feel. I vote against reverting back. I work all day in this thing. At least it can look nice.
For many of us, it did look nice. Professional and clean. Options for eye candy are ok, but forced eye candy is a cause for revolt. And tossed-up lunches. -- Scott
For those of you who care, who take time to evaluate the new lnf, and actually spent time to voice your concerns and what you think is wrong, and those of you who have been the biggest users/developers/evangelists of Eclipse, and now that the Eclipse dev team just give you a middle finger (well, kind of!), do you feel like an idiot? I do! I've been using Eclipse since the first release, have been proposing it to people which are using "pirated" JB, having been using it on a daily basis as the primary development platform, am beting currently our company's RCP apps on this, I really feel disappointed. It looks like Eclipse team is defeating its own purpose with this new look, and is leading the whole community astray. What will it take the dev team to realize that this new look just doesn't fit well in any platform at all (we are using Linux, WinXP, Win2k)? A fork maybe? What we'd like is someone from the dev team to come out from their hiding, and tell us what's really on their mind. I know it's their product, they can do whatever they want. If that's what really is how they think, just tell us clearly to fuck off, and we will not complain in this so-called "community" anymore. Isn't that simple or what?
Obviously the developers and project managers care about users think, otherwise you wouldn't see PMCs like John Wiegand and Kevin Haaland taking time to write long responses to our comments. Questioning someone's motivations is only going to alienate them, hurt their morale, and harden their positions. I know if would for me if the situation were reversed. Wouldn't it for you? Who was it that said "people of good character can disagree"? Committers, PMCs, committee members, board members, and sponsoring companies ultimately make these decisions, not voters. Votes, comments on the newsgroups, and so on are helpful suggestions but they don't have to be followed no matter how much we'd like them to be. The people that are willing to spend money for developer time and other resources for the Eclipse project deserve the right to make those decisions. See http://www.eclipse.org/org for the bylaws and development process for how it's supposed to work. Now, I've been using the "new look" since the prototypes first came out. In my opinion it's been improving but hasn't gotten back to the elegant simplicity and usability that evolved over the course of previous Eclipse releases, what we're calling the "old look". But I think we'd all be better off if we stuck to constructive comments. I'll try if you will, ok? :) Cheers, --Ed
If you look at the history of the debate on this issue, this has been a very "cool" debate since the beginning. People have been inputting calmly what they think. I've also spent time working with the new look, on and off, since the first I-build with the new lnf after M7. And people have "voted" on this forum, whether this is a fair vote, an equitable vote or not, those are the votes from people who really care. Those who think the new lnf is just plain wrong, including me, do not deny the new look totally. We have been saying since the beginning, just leave an option for us to switch back. Is this too much of a request? If yes, just say so, just say that you are not going to provide anything to go back, that's it, that's all, and we know there's nothing we can contribute anymore, and we wouldn't even bother. But we are clinging on to the hope that once the internal dev has things settled a little bit, then an option would be provided for people to choose from. Obviously, this doesn't look like a good bet at this point. Just look at the postings here and on NGs, people would have appreciated a clear answer (positive or not), instead of this ishy-washy blurb talking about "overall positive response". I have no problem with the development process, and that the org members have the final say. Obviously, it's their money and their product. What is worrying is that, the publicly stated philosophy and goal of the Eclipse platform is to stay "native", clean, simple and elegant, and as result of that, this has gathered a large group of loyal followers. But then suddenly, almost at the end of the dev cycle, this 180-degree turn is forced onto everyone. And that is after people have invested time and money on this project. Our small startup has spent one-year of development on an eclipse-based apps, and we are at the beta phase, and what we end up with is a look that we tried to avoid from Swing since the beginning? We have used Eclipse since the first release, and have seen it evolved over a couple of years, and have thought it to be something nice we can bet on. However, if we knew from the beginning that this would happen, we'd probably reconsider our options. And when I said we had been led astray, can I not say that, after spending all these development efforts and investment ourselves? Now, if Eclipse is intended to be just an IDE, we wouldn't scream so much. We would have used it as a dev platform only, and it would stay inside the company. Whether we'd like the look or not would be irrelevant. But the publicly stated goal is to make Eclipse a generic rich client platform, and especially after people have bought in, you can't go and make such a drastic change at the end of the dev cycle without having people screaming bloody, can you?
I would have to second the sentiments in comment 86. ASC has invested a lot of money based on the bet that the Rich Client Platform will be widely accepted. This was based on the success of the initial look and feel. We have no problem with evolution from that initial base--carefully tweaking specific UI elements to solve problems represented by specific use-cases. But such an abrupt wholesale change in the look and feel starts to feel like the Platform/UI developers are playing Russian roulette with our investment in Eclipse. We are naturally very concerned that this investment may come to nothing, not in small part due to the significant changes in the look and feel. We need evolution, not revolution, in the look and feel department. As Kevin requested, I posted bug 58059, 58062, and 58063, describing the specific use-cases that I believe represent the worst regressions in the current look and feel compared with the previous one. To all others here who are concerned about this issue, I invite you to vote for these bugs and/or annotate them. If anyone here feels that I missed something, please file additional bugs. If you file additional bugs, I would appreciate if you would also report the new bug numbers back here so that the rest of us can consider them as well.
question for comment #79, can you clarify what you mean by ... "the 'blindness' and unusability of editor tabs" perhaps log a bug report specific to the problem?
I have been using M8 since it came out to get a feel for the new look. Once I changed the color cheme to more closely match the native widgets the new lnf did not bother me overly much for working with eclipse as an IDE. The exception of this is the chevron, which I dislike intensely. It interferes with the ability to scan visually for a particular editor or view and therefore is anathema to the way I work. On the other hand from an RCP standpoint the lnf is a definite step backward. Bring back the consistent gradients please and if possible it would be nice if they could match the color scheme of the native widgets. At the very least return the tab widgets to their previous color scheme by default. Also if there is only one tab in a particular area it would be nice if the tab covered the entire top. This is especially true since when you do tear-away views the view looks awkward with the dead space to the right of the tab.
"bother me overly much" is very telling The IDE shouldn't bother people; it should help them...
It's hard to come up with a list of usability regressions in the new look as opposed to functionality additions to the old look. But I'll give it another try starting with these new bug entries: bug 58157 - [New Look] Chevrons decrease usability bug 58151 - [New Look] Dock perspective buttons on the left bug 58148 - [New Look] Allow clicking on view/editor title icons to drop down a menu bug 58150 - [New Look] Use view title bars bug 58153 - [New Look] Minimize/maximize buttons and gradients make UI too busy bug 58154 - [New Look] Part highlights are too intrusive bug 58146 - [New Look] Keep Eclipse and RCP presentation the same
bug 58160 - [New Look] Bring back thin borders and shadows around views and editors
While I can see the value in splitting up the problem areas in the new look and feel as the bugs listed in comment #91 I think in the end it dilutes the problem. The issue boils down to the fact that the new look and feel is inferior in usability and presentation as a native app versus the old look and feel. What I would like is an option to (preferably programatically) set the look and feel to be indistinguishable from the old look and feel. This may sound extreme but what it amounts to is that the new look and feel incorporates too many features that interfere with UI flow. There are a number of features that I do like in M8. Namely I like the tear away views, the improved positioning for views, the ability to minimize/maximize, and probably other features that do not come up off the top of my head. I would give up all of these in a heartbeat to get the UI back to a more native look and feel. It is a question of value-added versus value-lost. I could back up to M7 and just use that, but that is not a constructive way of going forward.
Bug 58174 - [New Look] UI is now very sluggish
Mike (#93), I've argued that too but I've been told by several people that unless there is a specific enumeration of problems and issues and regressions in the new look in the form of bugzilla entries then nothing can be done. Let's say that's true... Then the most helpful thing at this point would be for you and everybody else to review all the bug entries that have been listed in the comments and see if you can find any holes (missing entries or unclear ones you can add comments to). Any help organizing and sumarizing those entries would be appreciated (maybe a web page response, hint, hint). Then we'll take this list to the PMCs and the board and try and get some consensus about what to do. (I was *really* trying to not get drawn back into this, honest. Argh. Nick and David this is all your fault!! :-)
[Quote] Any help organizing and sumarizing those entries would be appreciated (maybe a web page response, hint, hint). [/Quote] You are killing my spare time... I have been looking over the bug activity on the various bugs involved and now have better idea of where the disgruntlement lies. I still feel that isolating the individual components makes understanding of the problem more difficult, but perhaps we can narrow the focus down a bit. I make no promises but my thoughts were to first attempt to quantify some of the issues by looking at just a representative view frame, then other parts later. I am working up a page but it might be a few days before it is done. The outline is like this however (note these are just my opinions of where the problems lie, I am sure most will disagree on at least some of my points): 1. The use of chevrons in a view frame makes visual scanning more difficult. 2. The positioning/addition of minimize/maximize and close buttons clutters the interface. 3. The view menu uses the inactive end color whether the view is active or not. 4. Default color scheme of Elipse is too far off the default color scheme of any version of Windows and Gnome known to man (except maybe Blue Curve). 4. By eliminating the view title bar the full title for a view may never be visible. Further by eliminating the title placement inside the view bar, placement of the tabs at the bottom creates a "void" where a user would reasonably expect the title. (i.e. the top) 5. Some issues with how mouse clicks on view bars are handled that I do not quite understand yet. The important thing in my opinion is not the precise look but, at the risk of buzz word compliance, the "user experience." Eclipse, and by extension other RCP aplications, should give a familiar, or at least comfortable, user experience when compared to a native application. This means not only should a widget not look too out of place but when a user who knows nothing about the application interacts with a widget it should behave in a predicable manner. Color schemes do not need to be precise, nor do widgets need to look completely native, just not so foriegn as to cause discomfort. The reason I qualify these statements with "too out of place" and "do not need to be precise" is that most Windows and Linux users are used to some variations based on the application being used, so variance to a certain extent is acceptable. Just not to the extent that M8 went.
That looks like a good start though some bug numbers need to be added and it needs to be fleshed out some. Maybe you could put the page on the eclipse wiki (http://eclipsewiki.swiki.net/) where everybody could help edit it? There's a board meeting this Thursday so if we can get it somewhat complete by, say, midnight EDT Wednesday night that would be helpful in case it comes up (sorry for the short notice but I just found about about it today myself). Something that followed the format of http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_0- Look/UIResponse.html, kind of a response to the response as it were, might be effective. Not necessarily with the same points though since some of those have been addressed and others have been uncovered. I don't understand your point 4. On point 5, I believe most of the click/double click regressions have been resolved except for one about clicking on the view/editor icon in order to drop down a menu (the 'system' menu that has minimize, close, fastview, etc.).
I will see what I can do. Unfortunately, I won't be able to post anything till after 5PM EDT. If someone else wants to start something I would be happy to go in there and add to it when I get off work. Point number 4 can best be explained this way. Open M8, move the tabs to the bottom and use the squared off look. Now you have a look similar to M7 except now you need to travel visually to the bottom to get a cue as to which view is opened. Compare this with M7. There was always, regardless of the tab placement, a view bar that included title name, the menu dropdown, and the close button. Unless you made the view very narrow the entire view name was always present, which is helpful in visual scanning. The need for the title in the view bar is mitigated somewhat by the presence of the tabs at top. The problem is that rarely is a space constrained area will you see the entire title in the tab. This is not a major problem in the IDE unless someone is trying to emulate the old lnf, it could potentially be more of a problem in an RCP application. I did not notice it till I opened M7 and M8 side by side to do comparisons of how I operate and what features in each cause disruption in the experience. The problem I can not see a solution for is what to do about minimize and maximize. The features are useful but the location unfortunate.
Created attachment 9438 [details] Screenshot of Different Tab Folders on Windows XP (zip of bmp) This is just to show a bunch of different tab folder designs on Windows XP. Partly to help us make ours better, and partly as an explanation that very few people really use native tab folders nowadays. Have fun. There are six (arguably seven) different styles of tab folders displayed here.
I like the "eye-candy" in general. I'm glad I'm able to set the gradient colors of the tabs, and whether I can use square tabs or rounded ones. The one thing that bugs me a bit is the perspective tabs: Perhaps the "New Perspective" button should NOT be on there because that means I have to visually click on the 2nd icon in order to go back to my default perspective (Resource). I'm also thinking that perhaps these perspective buttons could be in the toolbar tab. Or even a floating tab that can be called up with a quick keystroke. Something to think about. Thanks for a wonderful job you all are doing.
Created attachment 9439 [details] Screenshot of Different Tab Folders on Linux (png) This is a similar screenshot showing many different tabs. In this one, we're trying to show a bit about how different applications deal with too many tabs to fully display in one line. As a note to the previous screenshot, NetBeans uses multiple rows when it runs out of room for tabs -- as does the native tab folder on Windows XP.
The old version of netbeans is not a good example to use. The best examples in comment #99 are the VC++ ones (Solution Explorer, Server Explorer, Properties, etc.) but also the Display Properties dialog. Eclipse can make a dialog that looks just like Display Properties but not (in M8) views that look like VC++.
bug 58322 - Active part on inactive stack not highlighted bug 58323 - View dropdown wrapping wastes space bug 58325 - Inactive part background used on active part
At the risk of opening my mouth and removing all doubt I have done my best at trying to summarize the commentary on the new look and feel into one page including links to all the applicable bug reports I could find. http://eclipsewiki.swiki.net/2622 Please go in and correct any errors or add your own opinion. While the bug list is definitely the place for achieving the goal of fixing the issue, at least I have found it difficult to grasp with over a dozen related reports.
Created attachment 9473 [details] Unreadable Tabs with med-large worksets re: Blindness and un-usability of editor tabs When Eclipse has more than a few files open, 50% of the visual real estate is wasted by 'J' and 'X' icons and the '...' periods. This leaves about 7 characters of visual representation. If you happen to be working with a couple of collaborations or modularly named functional areas, your tab labels will represent all files from the same functional area with indistinguishable labels. The new chevron is slightly better in this situation than the previous UI, since the chevron is more usable/ convenient than going to the 'windows' dialog. This work with multiple files is fairly much my daily usage, maybe I'm engineering over fairly large spans but the intention is that Eclipse should be a strong engineering tool. So for a high proportion of my daily work, the tabs really do become quite non-functional. 'Blind' is the sense of first glancing and then examining them more closely, looking across them, and just being completely unable to see the desired file; or even determine whether it's shown on the list at all.
comment #105, I see you are finding the editor tabs difficult to use, what are you suggesting? Have you tried the single tab mode using the (Ctrl+E) function to drop down the list and let you change editors?
I added an outside-the-box idea for resolving the view and editor L&F issue as bug 58559.
Re comment 105 and comment 107: I agree with comment 105. I too have many files open every day. Comment 107 suggests single tab mode and Ctrl-E. When I have a few files open, it's easy to see what they are with multiple tabs. Using single tab mode would take that away. As I open more files and switch between them, the tabs appear in the order in which I opened the files. However, when I open a file that creates enough tabs to cause the chevron to appear, and I click the chevron, the list of filenames appears on the right under the chevron, but they're now in alphabetical order: cognitive dissonance! Even weirder, if I type Ctrl+E (which is presumably supposed to be the same as clicking the chevron), the list appears on the left side instead of the right side. Why is the location different? Also weird: I currently have nine files open. I open a tenth, which causes the chevron to appear and the left-most tab to disappear. I select the file that just disappeared from the drop-down list, and now all ten tabs are showing, with no chevron! I've given the chevron a go and tried to get used to it, but I just can't. I find that searching a separate list (especially one that is ordered differently from the tabs) is just too annoying. I might even be happy to go back to an infinite number of tabs: in the short term, I can remember where my file is, with tooltip assistance. Can we please have multiple rows of native tabs, so we can consistently see all the tabs all the time? If this means taking the X off each tab and having a single X on the right, so much the better.
Unreadable Tabs with med-large worksets: created separate bug #58590. I've posted my previous comments into this.
For status of this effort see John Wiegand's recent newsgroup post at: http://dev.eclipse.org/newslists/news.eclipse.platform/msg18591.html
Here is the first pass of implementing a parallel plugin that will provide the UI with a new appearence. To start with we are using the native tab folder. The idea is that we now have a framework within which to build and patch. We are still working on finding a home for this source code so unfortunately you will need to import it into your workspace if you want to work with it for now. Here is how to run it: 1) download and extract the "Runtime" version of the patch into an April 20th or newer build, into the \eclipse directory (we realize that there are some problems in these builds, they should get ironed out, and we were able to work with the build from the 20th) 2) download and save the r21look.ini file to your \eclipse directory 3) start eclipse with the following: eclipse -plugincustomization r21look.ini What you will see: You should see eclipse running with the SWT native TabFolder class. This will not contain the features of the current tab folder (such as a menu on the tab), and it should be considered work-in-progress. Next Steps: This work enables us to start collaborating on an R2.1 style tab folder look as well as some of the other features... Here is how to work with the code: The third attachment is the Project containing the source for this plug-in, download it, and import it to start working with the code. As mentioned we hope to find a home for this, for now submit patches back to this bug.
Created attachment 9734 [details] Runtime Plug-in for initial R21 look presentation
Created attachment 9735 [details] R21look.ini - ini file with settings to select R2.1 style presentation
Created attachment 9736 [details] Source Project for initial R21 look presentation
there doesn't seem to be anything in the 'features/org.eclipse.pde.container.feature_1.0.0/' folder of the attachment. doesn't work w/ 4/20; complains: Unable to find feature.xml in directory:/data/opt/eclipse/features/org.eclipse.pde.container.feature_1.0.0
Created attachment 9738 [details] Runtime Plug-in for initial R21 look presentation [revised] It should be possible to ignore the error described in comment 115. Failing that you can just delete the directory (not sure how it got there in the first place). This attachment has the same contents as 9734, without the pde folder.
Created attachment 9739 [details] Runtime Plug-in for initial R21 look presentation [revised] It should be possible to ignore the error described in comment 115. Failing that you can just delete the directory (not sure how it got there in the first place). This attachment has the same contents as 9734, without the pde folder.
hmm...well, it doesn't work here. i get the new look.
also, the plugin doesn't show up on the 'about...plugins' page
are you sure this is actually working for linux?
(Windows XP) The "three dimensional" look makes it easier to distinguish one tab from another, but even if they are native, they look clunkier than native tabs. Compared to the "My Computer -> Properties" dialog box, the tabs still don't have the flat edges, the gradients, or the orange highlighting. Ah, I just compared with a Windows 2000 system, and the tabs have the Windows 2000 L&F, rather than Windows XP. For comparison, running the wxPython demo on each Windows system produces native looking tabs correctly: gradients and highlighting on Windows XP, flat on Windows 2000. If wxPython (based on wxWidgets, previously known as wxWindows) can manage the correct per-system native look, why can't SWT? I much prefer the old "infinite number of tabs" to the chevron: displacing tabs into a list with a different ordering is very disconcerting. The "left-right" arrows to shuffle the tabs is unacceptable, but this is a work in progress, after all. Will you be producing a multi-row tab version so we can look at it? I also notice that more icons have the fuzzy, pastel look. Will the new "native" look bring back the clean well-defined icons? Please? Thanks for the viewing.
I contributed a patch to support multi row native tabs on Windows using SWT.MULTI that could be helpful for the native presentation. See bug 58868. Bug 58945 is related (multi-row emulated CTabFolder tabs) but that's harder.
Michael, how do you get your patch to work in self-hosted mode? I downloaded I20040420 and imported the source folder into my workspace but when I run the run-time workspace the new plug-in doesn't show up in the About box. This is on WinXP with 1.4.2_04 JDK. No errors in the log. I added the -console option and ran an "ss" command in the osgi console, and I see the org.eclipse.ui.workbench.r21look bundle is "RESOLVED". I specified the "- plugincustomization d:\path\to\r21look.ini" option on the command line but it had no effect and gave no error.
Peter (comment #121), you're undoubtably missing the javaw.exe.manifest file. You can find it in your eclipse directory somewhere - copy it everywhere on your system you find javaw.exe and restart Eclipse. That will give all SWT apps the current XP Theme. I doubt we'll see the old icons back officially. But if you saved a copy of 3.0M7 it should be possible, with some work, to make a zip file that would overlay all the new icons with the old ones. Copy the directory, delete everything that's *not* a .gif file, zip it up, then unzip it on top of your new install. Or something like that.
That did the trick, thanks Ed. Should/would I have been able to figure this out from the documentation provided? However, I'm still curious: if wxWidgets can figure it out, why can't Eclipse? This is excellent (with the same comments about shuffling tabs as comment 121). Keep it up. Pity about the icons: they lean towards "pretty" rather than "easy to read", and lend a dumbed-down feel to the GUI. I suspect that the more native the L&F gets, the less the fuzzy icons will fit in.
Peter, for more info on XP themes and why they're not picked up automatically see bug 53859.
Regarding comment 120; I just confirmed that it works for me on linux (gtk). Is it possible that you either didn't provide the "-plugincustomization r21look.ini" command line option, or put the .ini file in a place that wasn't found? You could use an absolute path to rule out the second possibility. The option is still required in order to work around bug 58975. As for the other issues with the plugin missing from the about dialog. I agree that its strange, but I confirmed that its also missing from my linux workbench. Right now I'm suspecting a problem with the way the about dialog is building the list of plugins, but I'll investigate more tomorrow.
But damn if those back/ forward arrows aren't the ugliest stupidest icons I've seen in a long time. (The rest are pretty good, I'd say).
+1 for the comment 128 What was wrong with the older ones ?
The plugin is not displayed in the about dialog because of the problem described by bug 57960 -- the dialog is building its list incorrectly.
Ok, it's still not working in self hosting mode for me. I specified this option on the command line (in the Program Arguments field of the run-time workbench launch configuration) but it had no effect: -plugincustomization d:\path\to\r21look.ini Other variants didn't work either: -plugincustomization file://d:\path\to\r21look.ini -plugincustomization d:/path/to/r21look.ini -plugincustomization file://d:/path/to/r21look.ini -plugincustomization file:///d:/path/to/r21look.ini What am I doing wrong? Thanks.
I traced the r21look self-hosting problems (described in comment 131) to a problem with a fix we made yesterday (to a workaround to an unrelated problem). Using the workbench (org.eclipse.ui.workbench project) from the apr20 intergration build, rather than what is in HEAD right now should allow self-hosting with the r21look.
the native tabs look much more, well, much more native. if you had used these in the first place, i doubt you would heard a peep. it's not the product that people had a problem with, it's the packaging. should we post RFE/bugs against the 'new new look' here? (or should that be referred to as 'classic look' :) if here, getting the file names on the editor tabs and just sticking the buttons/regular stuff on a context menu would make it just fine by me. adding an optional middle-click or double-click to close tabs would make it peachy. since the 'new new look' appears to still use the 'old new look' rendering code, the performance issues are still there, i guess, but already it just 'seems' better... re: comment 131: specifying the absolute path worked for me. if you're using a shortcut, try making sure the working dir is where the ini file is located...
Regarding comment 133 and others, lots of good points: Regarding the look of native tabs, we agree it has some limitations: comment 121 describes a situation (win2k) where native is not ideal the tab looks like tabs in other applications, but when presented in the eclipse layout sometimes it appears less than optimal (3-d look appears clunky) nonetheless, running the current version of this plugin (with some future fixes for title bar, etc.) will give end-user's a native presentation Regarding the future: We are working on having tabs that look like eclipse R2.1 We are excited that there is now a good base to allow people to experiment with their ideas, this patch provides the template people need to get started
Created attachment 9803 [details] Screenshot of native l&f with multi-tabs under XP To do this I made a one line change to R21LookStackPresentation: tabFolder = new TabFolder(parent, tabPos | SWT.MULTI); and applied the patch from bug 58868.
Created attachment 9804 [details] Screenshot of native l&f with multi-tabs under XP To do this I made a one line change to R21LookStackPresentation: tabFolder = new TabFolder(parent, tabPos | SWT.MULTI); and applied the patch from bug 58868.
Re comment 134 > comment 121 describes a situation (win2k) where native is not ideal I said nothing like that. What I said was that Windows 2000 tabs did not look right on Windows XP. Windows 2000 tabs on Windows XP are not native. I was clearly saying that *not* native is not ideal. > We are working on having tabs that look like eclipse R2.1 Just native tabs (and other native features) will do fine, thanks. :-) Re comment 136 > Screenshot of native l&f with multi-tabs under XP Excellent!
Instead of arguing to use this non-native tab or that non-native tab, I still suggest to just purely use native tabs (Bug 52787, including screenshots). If people want fancier tabs, just change their theme on whatever OS they are prefering.
Created attachment 9814 [details] Screenshot with native tabs on the bottom under XP (looks bad) Unfortunately I've discovered that the native tabs look unacceptably bad when you set the option to put them on the bottom on XP. This appears to be a limitation of the native XP themed tabs, not anything Eclipse can fix. Since this is such an important platform, the native tabs will be of limited usefulness (to me, anyway). Unless somebody can figure a way to disable the themed tabs without disabling the rest of the XP theme-y-ness, I now think that "quasi-native" tabs, i.e., tabs that are kind of bland looking that can pass for native (similar to the win2k tabs or the tabs used in VS.NET 2003) will be the best choice. See some work I did for bug 59297 for a possible direction. VS.NET tabs are even plainer than that and nobody complains about them. (P.S. after mucking around with CTabFolder for a few days I have a newfound respect for Veronika's attention to detail - yikes! is that tedious)
Ah, the paradox of choice. When you start offering alternatives, complexity starts growing. Now we're looking at "native", "Eclipse2.1", "new", and "native with 2.1/Win2K/.NET tabs". It could be argued that putting native Windows tabs at the bottom of a window isn't native. :-) I don't want native tabs taken away and replaced by something with a non-native L&F, just so someone else can do something non-standard. Or in other words, I don't think that "quasi-native" tabs are the best choice at all. Conversely, I want you to have your option: by all means, let's have the choice, if possible. The trouble is, where do we stop? We are in a maze of twisty little L&F passages. Unfortunately, they're not all alike. :-)
Personally I think the guiding principle of this effort is that we are attempting to replicate 2.1--not create something new. The new look does that. After 3.0 we can update this, enhance it, create additional looks, etc. but the whole thing we've been after here is that we want the 2.1 look back. Granted the 2.1 look isn't perfect, there are known problems, etc. but I don't think this is the place to address them. Otherwise we just have two new looks. Once again--additional work may be worthwhile, but let's not do it here now. In SCM terms: one doesn’t introduce new changes during a merge operation, though one might choose make them immediately afterward. Granted, we are not going to get a look that is exactly what the 2.1 look was since we are building on the new look infrastructure, but I'd suggest that at every decision point we don't ask which solution would be cooler, more usable, etc. we simply ask “what gets us closest to 2.1.” This question will have a relatively objective answer and we won't fall into the trap of making controversial value judgments which the larger community doesn't share. Given our limited time and the current climate, keeping our scope objective and as predictable as possible is in our best interest. 3.1 will start soon enough.
Re comment 141 > the whole thing we've been after here is that we want the 2.1 look back. Er, no. I want a native platform look, and I don't think I'm alone. Eclipse 2.1 was acceptable because it was close enough to native to not upset most people. Personally, I'd be happy if I never saw the 2.1 look again, as long as we get what SWT was apparently designed for: the L&F of the platform. After seeing Ed's screenshot in comment 136, why would I want the 2.1 look back? Having said that, comment 141 seems pretty sensible to me.
Hi Ed, Thanks for your work on multi-row and native tabs. (Still want vertical ones as the only real solution). Hey, I wouldn't worry about 'native tabs at bottom' at all! The native stuff looks fine to me, if the users prefs their tabs to be at bottom and there are a few pixels of rounded-corner rendering wrong, I see this as fully acceptable. Were there any other problems than the direction of those rounded corners? Were there any problems when the tabs were in their proper place, eg at top? This really would appear to fall into the someoneElsesProblem/ don'tCare/ allOfTheAbove categories. Again, vertical tabs are the real need. But your native stuff looks fine to fulfill people's 2.1 look requirements. Cheers, Thomas
Re comment 139: I wouldn't care much about that problem. Native look and feel is limited in several ways. It differs from platform to platform. If on some platforms for some reason bottom tabs arn't practicable, then this is a limition of the specific platform. The Eclipse presentation UI might honor that and hide several options depending on the platform support.
Nice to see what's happening here. The native tabs look much better. But I have to agree about the icons. The "Create class" icon and such look like they've got the mumps in a 60's cartoon...
RE Bottom tabs... This is the type of thing that leads me back to the "give me the old L&F back". While I like the native tabs when they're at the top, at the bottom they look like a real problem. Comments like "someoneElsesProblem / don'tCare" are the reason why I'm still very suspicious that we'll actually get a usable 2.1 (or more native 2.1 like) L&F back.
I believe the patches that Michael made were to just show off a framework that can be used to support more than one presentation (i.e., look & feel). I think he grabbed the native presentation and used that as the first one simply because it was handy and small. It shouldn't have been called R21 though. Anyway, it's kind of interesting and thought provoking on its own but as John- Mason pointed out it's not the main point of this exercise. Is someone actively working on creating a plug-in that recycles the old viewform/ctabfolder code from 2.1/3.0M7? I expected more coordination either here or in platform-ui-dev. If you want our help and support you've got to talk to us and include us in the thought processes. A temporary scratch area or branch in a CVS repository somewhere with many permitted committers would be helpful too for history and patches.
What problem to vertical tabs solve? You still need to dedicate a horizontal row to the view's local toolbar, so you don't regain that space.
You can fit quite a number of tabs in a vertical arrangement. I do the same with my Windows taskbar. Currently I switch to other Eclipse editors using the next and previous editor actions which pops up a list of editors, but it would be nice to have the always visible tabs be useful as opposed to just taking up valuable vertical space (on most desktops this is the limiting axis). I don't see why a horizontal row would still be needed if tabs were arranged this way.
I am working on getting some space for us to share our work, please stay tuned for more information on this as soon as it is available.
i agree with most here that i'd much rather see just the native tabs. they are mores than adequate and would greatly simplifies maintainability, since there is no need to create separate code for each L&F you may run into. comment 139: the problem w/ the XP tabs on bottom is just that SWT is drawing them using the wrong orientation. i think that's a bug with SWT or the SWT code. once they are oriented properly, they should look like any other windows program with tabs. that's not really an argument for non-native tabs on windows, it's an argument to fix the SWT stuff. comment 149: as far as vertical tabs are concerned, i agree they'd make a nice addition, but let's not divide ourselves so close to achieving our primary goal. adding them later should be relatively simple by changing the tab position in SWT. but first, we need that SWT tab folder.
The points in comment 147 are correct. 1) We haven't posted enough detail on the direction that our version of the plugin will take. I'll do that here by saying that we're working on bringing the 2.1 versions of ctabfolder, viewform, etc., into this plugin in order to provide a look that's as consistent as possible with 2.1. When completed this will provide the 2.1 look with just the plugin and the preference to set the active presentation factory. 2) Its true that the current version only provides a basic native look. Its very much a work in progress and the R21 portion of the name reflects our focus on turning this plugin into a provider of the R21 look. In retrospect it would have been better to change the name to "Native..." before "releasing" that interim version. At the time our two goals were to give people a starting point for their own look customizations (as Ed has been doing) and to demonstrate that purely native tabs are possible. Ed's description of our intent for the native functionality is correct. It was a quick way for us to demonstrate the framework, we don't have plans to continue development on that look. Instead, Michael and I will be putting our efforts into porting the 2.1 look. If there's enough community interest in the native type of look then perhaps someone could coordinate the completion and enhancement of the current sample plugin. Where we are: 1. The base eclipse functionality allows the ui to be customized through the presentation factories provided by plugins. 2. The plugin released thus far shows how to exercise that functionality. Where we're going: 1. Michael and I will continue to add 2.1 components to the plugin; the ultimate goal being to provide a 2.1 type of look. 2. Interested community members can continue to complete and enhance the native look plugin.
Re #151: Alvin, I don't think it's that simple but we should probably move the native tab discussion to a different bugzilla entry like one of the following. I suggest the first one but take your pick. Others may want to comment on and/or vote for some of these too: bug 52787 - please use native TabFolder widget Bug 28722 - Split Tabs in editor into several lines Bug 58868 - TabFolder should support multi row style option Bug 58945 - CTabFolder should support multi row and vertical style options Bug 59297 - CTabFolder tabs should always have a border around them
re comment 153: those bugs seem to support the opposite argument - that any current limitations of native tab folders are fixable SWT issues, and once addressed there will be no need to create a non-native implementation since it will have the desired functionality. re comment 152: really, if you just added context menus back to the tabs and properly titled the editor tabs, this current patch would be all that's needed to make many of those who are opposed to the new look happy. most just want a vanilla, native tab folder; things like vertical tabs and close buttons are nice-to-have but not critical features. i've read through most of the many bugs related to this subject, and what most people (including i) would be happy with is this native implementation. why make more work than necessary? in addition, i don't see how creating yet another non-native implementation would solve anything. it would just be yet another thing to maintain *that can never make everyone happy*. with the native implementation, you can make many more people happy since they can simply use an OS theme that suites them. the look is guaranteed to match their OS, because it *is* their OS. yes, i said earlier that 'i'ts all about the packaging', but at this point just rewrapping the same product in an older wrapper would not be seen as giving those who have spoken what they want, but rather it would be seen as giving them what *you* want and hoping they're too dumb to notice. right now there's just too much scrutiny here to get away with that. to combine what i and others have said, just because there weren't many vocal complaints about the tab folders in 2.1 does not mean all was well. it simply meant that since it was asthetically(sp) tolerable and since eclipse was overall a great product, most were not motivated to take up arms about it. that is no longer the case. this patch has proven that using native tabfolders is not only feasible, but there is really little functionality gained by using non-native tabs. if this patch was supposed to show that the emulated widgets are necessary, it backfired. now that 'the natives' smell blood (excuse the pun), they won't be happy until they get those native widgets. really, all you need to do for this patch to be ready is add a context menu and fix the editor titles. why not just give the people what they want?
As one of those who spoke out against the new L&F, I wanted to chime in with thanks and support for this effort. I am especially pleased to see input and response from the Eclipse dev team like the one above from Andrew. Not only do I apprecaite the work, but also the effort to keep us (the cummunity) informed about the goals and direction. As for the native tabs, without going through the work of installing this patch to see them first hand I have to agree that purely native is better; I agree that it is going to make the most people happy in the end. (I hope to find the time to install this patch and play with it soon) All that said, there are still other issues besides the tabs that need to be brought back from "Fisher-Price" land. I hope those other things are not gorgotten in the effort to get tabs back to native or native-looking.
BTW the wiki page is back: http://eclipsewiki.swiki.net/2622 The wiki page collects and summarizes the feedback on the new look in one place. It attempts to answer the question, "what's wrong with the new look (that we'd like to fix)?" and "what's right with the new look (that we'd like to keep)?". It's open to anyone to add their own comments and edits. John Wiegand is trying to recruit developers with some spare time to help with l&f code changes. If interested, send him email directly (his email addr. can be found on this bugzilla entry somewhere). I'll comment on the native l&f over in bug 52787.
Re comment 154: +10 Re comment 152: > Instead, Michael and I will be putting our efforts > into porting the 2.1 look. If there's enough community interest in the native > type of look then perhaps someone could coordinate the completion and > enhancement of the current sample plugin. How about doing it the other way around? Put your efforts into finishing the native look. If there's enough community interest in reviving the 2.1 look, perhaps someone could coordinate it.
Why is there still insistence from the Eclipse team to create multiple non-native UIs? There is an obvious disconnect between the goal of SWT to provide native UI and Eclipse's use of SWT that is difficult to understand. Why would I want to replace the 3.0 non-native look with a ported 2.1 non-native look? This discussion is particularly frustrating given that many developers have spent countless hours creating the UI look and feel for their platform (Win, Mac, Linux, etc.) and we're still bickering over the best way to *not* use their work. If I wanted my apps to look non-native, I would have used Swing. I thought choosing SWT and Eclipse would give me an easy way to create native apps but now you're basically telling us you're not interested in native l&f (at least for tabs) so just go do it yourself, which is really disappointing.
David (and others), I've argued for a pure native l&f myself so I know where you're coming from and I'm on your side. Eclipse uses native buttons, native menus, native dialogs, native toolbars, and so forth. The only exceptions of note are the perspective switcher swish, which should definitely go, and the tabs used for view/editor switching. With me so far? Native tabs on XP are just not flexible enough for good solid view/editor switching. As a programmer I tried to make it work, and failed. See my earlier comments on this. Perhaps the tabs on Mac and Linux are, but not on Windows, which is all I have. I'm perfectly willing to be proven wrong on this (that's a challenge, go do it!) but until then, this is one of those places where either a) a native control should be used on some platforms but not on others, or b) it's simple enough that it can be emulated and nobody can tell the difference. Do this exercise: take a close look at other native Windows programs that implement a view switching paradigm like Eclipse does and see if they're using the standard Windows tab control. The ones I looked at, mainly Microsoft products like VS.NET and Office, are NOT. The Windows tab control sucks, plain and simple, and even Microsoft recognizes that. A number of third party companies offer replacement tab control libraries (do a google search on xp tab controls to find them). They are probably implemented in C code. Does that make them native? Not in my book because I take "native control" to mean "provided by the O/S or window system". If you're going to have to draw something yourself, Java is a perfectly good language to do it in, just as good as C. To summarize, the native built-in Windows XP tab controls are not a good fit for view switching in general. I used to think otherwise but after digging some more I changed my mind. I urge you to either do the digging yourself, prove what a brilliant programmer you are and make it work yourself, or just take my word for it. In any case this entry is long enough so please vote for bug 52787 and help work out solutions with XP tabs over there so we can reserve this bug for trying to recover some of the usability lost from previous versions. Sound fair?
Ed, Re comment 159, Amen!
Created attachment 9896 [details] Editor tabs in IntelliJ On comment #159 from Ed Burnette: I disagree that "Native tabs on XP are not flexible enough for a solid view/editor switching". I've attached an example from Eclipse's maybe biggest compeditor (on the Java IDE market at least). These tabs have no feature or behavior beyond standard native tabs (maybe the look better on the bottom, but someone said that was a SWT bug and not a XP problem). So since they can do it I'm sure we can as well. My biggest thing about non-native tabs is that Eclipse isn't just an Java IDE; it is supposed to be a rich client platform. For some RCP applications, it looks a little out of place to have these fancy tabs instead of just plain simple ones (IMNSHO of course). That is why I think it should be an optional solution to have native tabs using TabFolder instead of CTabFolder on the workbench.
Regarding comment # 159: "b) it's simple enough that it can be emulated and nobody can tell the difference." Assuming native tab controls can't be used for lack of needed functionality, I agree with the above statement. What I'm really after is the l&f match the underlying OS and if that can be done accurately by emulation, great! I just don't want to explain to users why some tabs in my RCP app look native and some (views and editors) are different.
A new project has been created in CVS for the R21 style presentation. Currently it contains our initial CTabFolder port. This provides the 2.1 style tabs and borders. Next up should be view title and tool bars; this is very much a work in progress. To get this code, use CVS to connect to: Host: dev.eclipse.org Port: Default Repository path: /home/eclipse - Log in as anonymous, no password is required. - Check out the "org.eclipse.ui.internal.r21presentation" project. The new .ini file in the plugin replaces the version posted to this bug earlier. The file needs to be copied to your eclipse directory. Then launch with the command line option: -plugincustomization r21presentation.ini
A new bug 59850, has been created to track all work being done on the R2.1 presentation style.
re comment 159: ed, can you give some specific examples of how the native tabs aren't flexible enough to be used on windows? i use windows xp/2000 as well as linux, and i don't see any problem with this patch except those aready noted (editor titles and no context menus/toolbars) which have nothing to do with the widget set. the only thing that you mention in your comments is the look of the native tabs when oriented on the bottom when using the winXP theme. this is a glitch with SWT and hardly a reason to abandon SWT in favor of a non-native implementation. it also is an asthetic issue and does not impact funtionality or flexibility. additionally, since the current new look is themeable, wouldn't it make more sense to work with that for your case instead of saying that all windows users must use a new, non-native look instead of the native look which many say they want? just because one person doesn't like how tabs looks when he puts the tabs on the bottom, everyone must use a non-native widget? that's the kind of thinking that got us into this mess in the first place. the point is, people should have a choice between native and non-native, and many people (myself included) have expressed the opinion that they would rather have native. please don't take offense, but what makes your opinion so valuable that it outweighs those who have unambiguously stated that they would rather have a choice to use the native theme, regardless of (temporary) glitches?
>>the point is, people should have a choice between native and non-native, and many people (myself included) have expressed the opinion that they would rather have native.<< Yes, but what constitutes "native"? According to your definition, Microsoft Office isn't native. Quicken isn't native. I could go on. I never heard a single person complain that Eclipse 2.x was not native enough. Rather, Eclipse 2.x received many accolades from across the industry about how native it looked. This was in spite of the fact that Eclipse 2.x used several significant non-native UI elements, most notably the ViewForm for views and CTabFolder for editors. It seems to me that perceived nativeness is what Microsoft does with Office, Intuit does with Quicken, and what we did with Eclipse 1.x and 2.x. And it seems to me that this is really what we're still after. Eclipse 1.x and 2.x did it with clever use of shading, coloring, and gradients that matched the shading, coloring, and gradients of a majority of platforms. Therefore, I support Ed's conclusion that "native-looking" is fine when it comes to using CTabFolder versus TabFolder. Maybe there's a third option: Use TabFolder when the tabs are at the top, but CTabFolder when they're at the bottom... It's worth investigating anyway...
re comment 166: please read the entire history of the dicussions in the bugs/newsgroups. the issues you bring up here have all been discussed ad nauseum. to recap, if you read the SWT documentation it should be obvious what a native widget is. whether or not Office or Quicken use native widgets is a red herring (it's not relevant); we already have a mechanism for rendering skinnable non-native widgets, but we would like a choice. the advantages of native widgets are have also been discussed ad nauseum. i'd also like to point out that Microsoft and Intuit do not have to worry about how their non-native widgets in Office and Quicken look on the diverse range of platforms that java/SWT run on. if you read the entire discussion of the matter, you would see that one of the major recurring themes is that it is impossible to make everyone happy with one non-native widget/skin, and that you have a much better chance of success if you allow people to choose a widget's look through the OS.
Al, a few points: 1. A patch was posted to allow native tab controls to be used for view and editor folders already so anyone who wants to use that and enhance it can do so, and hopefully contribute improvements back, 2. Limitations of XP themed tabs have nothing to do with SWT - you can duplicate it in C code, 3. Implementation details of the tab control are a small part of the usability of Eclipse, and finally, 4. bug 52787 is open for using the native tab control for views and editors, and would be a better place to discuss that.
Created attachment 10061 [details] latest snapshot of work in progress
Created attachment 10300 [details] May 5 snapshot of work in progress this obsoletes the previous image
The toolbar at the top of the page looks like it wastes considerable screen space above and below the icons. I realize that this is still a work-in-progress, but I noticed this in the previous views as well. Compared to the file menu bar and the tabs, the toolbar looks way to big.
The tall toolbar can also be seen in the 'new look' presentation. It seems to be something to do with the curvy perspective switcher.
Created attachment 10384 [details] Screenshot from May 6
The separator lines are still missing from the Coolbar. In 2.1, the Coolbar was not SWT.FLAT, and you could distinguish one coolitem from the other.
I'm not sure this is the appropriate place to ask this question. Is it the intention for the new "old" look and feel to also support the ability to minimise views? As much as I want to go back to the 2.1 L&F, this is a new feature that I would really like to use in that context.
re: comment 175 The goal for the R21Presentation project is to produce as close as possible to a pixel for pixel reproduction of the eclipse 2.1 look and feel. That being said we're expecting to integrate some 3.0 features if they meet all of the following criteria: - don't adversely impact the 2.1 l&f - are highly desirable - and especially, will not endanger timely completion of development The last point is especially important given the short amount of time remaining in this release cycle. For example, the 2.1 fast view bar was fixed on the left side of the window. In 3.0 it can be dragged to any of the left, right, or bottom sides. It would be more effort to disable this functionality than to leave it in AND there doesn't seem to be a cost to it since clients that want it on the left can leave it there. To answer your specific question, the decision has been made (bug 59952) to leave the view minimize functionality available as a menu option in the view title bar's drop down.
Can someone post a win2k default theme screen capture please. Same size same arrangement as the screenshot from May 6. thank you.
The R21 presentation pretty much does what it set out to do, i.e., emulate the R21 L&F for views and editors. There are some minor cleanup things than can be done to it, but I'm not sure what the future of this is so I'm not sure what the priority is. If the new look is going to remain the default, indeed the only, convenient UI for Eclipse then it might be better to try and take some of the R21 lessons and apply them to the R3 presentation in the time remaining. I've started doing that in bug 58150. If you look there you can see a screenshot and a patch to re-implement view titlebars in the new look code. The changes are fairly minor so I hope that will be considered to improve the polish and usability in 3.0.
Created attachment 10949 [details] Snapshot of Preferences Dialog showing option
Created attachment 10950 [details] snapshot of M9 switched to the R21 presentation
fixed in M9
