Community
Participate
Working Groups
M7 Based on the discussions in bug 52780 (not to mention bug 37997, bug 52685 and bug 52875), and on feedback received at EclipseCon, there is a strong requirement for RCP apps to look more native than the proposed new look in the Eclipse SDK. Either the old look should be the default for RCP apps, or it should be easy to configure it to have the old look. NOTE: this PR is specifically about the look requirements for RCP apps. Other PRs have asked for the new look to be completely backed out of the SDK (bug 52875) or for there to be an option to choose (bug 52780). Please distribute your comments and votes accordingly.
This is particularly true for those early adopters (with the arrows in their backs <g>) who started doing RCP apps on top of Eclipse 2.1. It should be easy for them to migrate to 3.0 without an unwanted major impact on their L&F. It would be helpful to know -which- aspects of the classic look vs. new look are most critical. Please provide simple +1s or -1s or 0s (for don't care) for the following items (of course, extra comments are always welcome too <g>), listed in order of importance for you. Note that this is not a complete list, and is just intended to get a feeling for what aspects people think are most important to their RCP app. Some of these items are opposites of each other, so vote +1 for one or -1 for the other, but there's no need to vote for both (unless you -really- feel strongly about it <g>). - square view/editor tabs (as in 2.1) - curvy view/editor tabs (as in 3.0 new look) - native view/editor tabs (e.g. see the Java > Compiler pref page) - always having a view titlebar (as in 2.1) - never having a view titlebar (as in 3.0 new look) - only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) - close button on view titlebar (as in 2.1) - close button on view tabs (as in 3.0 new look) - view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) - view toolbars always on own row (as in 3.0 > M7) - view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) [Note that this feature has since been removed, but you can cast your vote if you liked them.] - double-click to maximize view/editor (as in 2.1) - button for collapsing views (as in 3.0 new look) - button for maximizing views/editors (as in 3.0 new look) - fast views only on left (as in 2.1) - fast views on any edge (as in 3.0 new look) - perspective shortcuts at left (as in 2.1) - perspective shortcuts in toolbar area (as in 3.0 new look) - curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) - editor management using only tabs (as in 2.1) - editor management using single drop-down (as in 3.0 new look default) - editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) - no editor management (your app might not need editors) - shadow border around views (as in 2.1) - no shadow borders around views (as in 3.0 new look) - border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) - fewer border lines (as in 3.0 new look)
+1 - square view/editor tabs (as in 2.1) -1 - curvy view/editor tabs (as in 3.0 new look) +1 ! - native view/editor tabs (e.g. see the Java > Compiler pref page) 0 - always having a view titlebar (as in 2.1) 0 - never having a view titlebar (as in 3.0 new look) 0 - only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) 0 - close button on view titlebar (as in 2.1) 0 - close button on view tabs (as in 3.0 new look) +1 (big space saver) - view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) -1 - view toolbars always on own row (as in 3.0 > M7) -1 ! - view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) [Note that this feature has since been removed, but you can cast your vote if you liked them.] +1 - double-click to maximize view/editor (as in 2.1) -1 (not used often enough for a button) - button for collapsing views (as in 3.0 new look) -1 (can double-click) - button for maximizing views/editors (as in 3.0 new look) 0 - fast views only on left (as in 2.1) -1 (I was never happy with the way fast views worked, would prefer something like Windows auto-hide docks) - fast views on any edge (as in 3.0 new look) +0.5 (ok, but would prefer them to be a dockable toolbar/tray that can be put top, bottom, left, or right) - perspective shortcuts at left (as in 2.1) -1 (I find them inconvenient to search out and click with the mouse) - perspective shortcuts in toolbar area (as in 3.0 new look) -1 ! - curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 (but multiple rows of tabs would be a nice feature) - editor management using only tabs (as in 2.1) -1 - editor management using single drop-down (as in 3.0 new look default) 0 (don't like the way only some editors are shown) - editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) 0 - no editor management (your app might not need editors) 0 (I like the look, but it's not critical) - shadow border around views (as in 2.1) 0 - no shadow borders around views (as in 3.0 new look) 0 (not sure I'd miss them or not) - border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) 0 - fewer border lines (as in 3.0 new look)
+1 square view/editor tabs (as in 2.1) -1 curvy view/editor tabs (as in 3.0 new look) 0 native view/editor tabs (e.g. see the Java > Compiler pref page) 0 always having a view titlebar (as in 2.1) -1 never having a view titlebar (as in 3.0 new look) -1 only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 close button on view titlebar (as in 2.1) -1 close button on view tabs (as in 3.0 new look) +1 view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) -1 view toolbars always on own row (as in 3.0 > M7) -1 view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) +1 double-click to maximize view/editor (as in 2.1) -1 button for collapsing views (as in 3.0 new look) -1 button for maximizing views/editors (as in 3.0 new look) 0 fast views only on left (as in 2.1) +1 fast views on any edge (as in 3.0 new look) +1 perspective shortcuts at left (as in 2.1) -1 perspective shortcuts in toolbar area (as in 3.0 new look) -1 curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 editor management using only tabs (as in 2.1) -1 editor management using single drop-down (as in 3.0 new look default) -1 editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) 0 no editor management (your app might not need editors) +1 shadow border around views (as in 2.1) -1 no shadow borders around views (as in 3.0 new look) 0 border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) +1 fewer border lines (as in 3.0 new look)
0 - square view/editor tabs (as in 2.1) -1 - curvy view/editor tabs (as in 3.0 new look) +1 - native view/editor tabs (e.g. see the Java > Compiler pref page) 0 - always having a view titlebar (as in 2.1) 0 - never having a view titlebar (as in 3.0 new look) 0 - only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 - close button on view titlebar (as in 2.1) -1 - close button on view tabs (as in 3.0 new look) +1 - view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) -1 - view toolbars always on own row (as in 3.0 > M7) -1 - view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) [Note that this feature has since been removed, but you can cast your vote if you liked them.] +1 - double-click to maximize view/editor (as in 2.1) -1 - button for collapsing views (as in 3.0 new look) -1 - button for maximizing views/editors (as in 3.0 new look) 0 - fast views only on left (as in 2.1) 0 - fast views on any edge (as in 3.0 new look) 0 - perspective shortcuts at left (as in 2.1) -1 - perspective shortcuts in toolbar area (as in 3.0 new look) -1 - curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 - editor management using only tabs (as in 2.1) -1 - editor management using single drop-down (as in 3.0 new look default) -1 - editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) 0 - no editor management (your app might not need editors) 0 - shadow border around views (as in 2.1) 0 - no shadow borders around views (as in 3.0 new look) 0 - border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) +1 - fewer border lines (as in 3.0 new look)
Just to reiterate, what I'm aiming to gather here is how people think the Workbench should behave for their non-IDE RCP apps, not their preferences for how the Eclipse SDK looks. Perhaps it would help to clarify if people gave a one-line description of their app (make it as generic as you like if confidentiality is an issue).
-0 - square view/editor tabs (as in 2.1) -1 - curvy view/editor tabs (as in 3.0 new look) +1 - native view/editor tabs (e.g. see the Java > Compiler pref page) +1 - always having a view titlebar (as in 2.1) -1 - never having a view titlebar (as in 3.0 new look) -1 - only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 - close button on view titlebar (as in 2.1) 0 - close button on view tabs (as in 3.0 new look) +1 - view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) 0 - view toolbars always on own row (as in 3.0 > M7) -1 - view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) [Note that this feature has since been removed, but you can cast your vote if you liked them.] +1 - double-click to maximize view/editor (as in 2.1) +1 - button for collapsing views (as in 3.0 new look) +1 - button for maximizing views/editors (as in 3.0 new look) -1 - fast views only on left (as in 2.1) +1 - fast views on any edge (as in 3.0 new look) -1 - perspective shortcuts at left (as in 2.1) +1 - perspective shortcuts in toolbar area (as in 3.0 new look) -1 - curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 - editor management using only tabs (as in 2.1) -1 - editor management using single drop-down (as in 3.0 new look default) +1 - editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) 0 - no editor management (your app might not need editors) -1 - shadow border around views (as in 2.1) +1 - no shadow borders around views (as in 3.0 new look) -1 - border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) +1 - fewer border lines (as in 3.0 new look)
We are currently developing a commercial RCP-based application, and this look and feel issue is critical to us. We could back out at this point and go with straight SWT, but having the RCP to build on gives us a strategic advantage. Our priorities are ease of use and native look and feel across multiple platforms, in that order. We fully understand that there are non-native elements in the Eclipse/RCP UI, and many of these elements add value. The problem with the new look and feel is that it crosses a subtle line defining the comfort zone of average users (not Java developers). The only way to find this line is through usability testing, but the line has definitely been crossed. Some of the changes to the look and feel are more jarring than others, but it may be the volume of changes that has the most effect. We're not sure why there has to be a *new* UI. Our preference would be that Eclipse/RCP gradually track the UI updates that take place in the different platforms, and introduce subtle UI elements where they add the most value. We appreciate the hard work that goes into this UI work and we want the Eclipse team to keep innovating in this area. In this spirit, here are our votes for the specific UI elements. ---- +1 square view/editor tabs (as in 2.1) -1 curvy view/editor tabs (as in 3.0 new look) +1 native view/editor tabs (e.g. see the Java > Compiler pref page) This is one of the simplest changes, but also the most jarring to average users. Having tabs track the look and feel of individual platforms would go a long way toward making users feel comfortable. ---- +1 always having a view titlebar (as in 2.1) -1 never having a view titlebar (as in 3.0 new look) -1 only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 close button on view titlebar (as in 2.1) -1 close button on view tabs (as in 3.0 new look) 0 view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) +1 view toolbars always on own row (as in 3.0 > M7) -1 view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) [Note that this feature has since been removed, but you can cast your vote if you liked them.] +1 double-click to maximize view/editor (as in 2.1) 0 button for collapsing views (as in 3.0 new look) 0 button for maximizing views/editors (as in 3.0 new look) View handling is one of the Eclipse/RCP UI innovations that really add value. The gradiated titlebar, with sort/filter functinality added, was a graceful way to combine native and non-native functionalities. No space is gained or lost by moving the tabs to the top and moving sort/filter to a separate toolbar, but the overall look is complicated. Max/Min functionality could be handled in other ways (drop-down at top left, etc.). ---- 0 fast views only on left (as in 2.1) 0 fast views on any edge (as in 3.0 new look) +1 perspective shortcuts at left (as in 2.1) -1 perspective shortcuts in toolbar area (as in 3.0 new look) -1 curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) The curvy separator should go along with the curved tabs. Dockable fast views are nice, but perspectives should either be dockable as well or at the left. The upper left corner of the UI is an application's center of gravity. The primary navigation elements should be placed there (at least initially). ---- +1 editor management using only tabs (as in 2.1) -1 editor management using single drop-down (as in 3.0 new look default) +1 editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) 0 no editor management (your app might not need editors) Tabbed editors are much more standard than the single drop-down. This could be an option to be turned on by users who like it, but should definitely not be the default. ---- 0 shadow border around views (as in 2.1) 0 no shadow borders around views (as in 3.0 new look) 0 border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) 0 fewer border lines (as in 3.0 new look) This is an area where we would like to see Eclipse/RCP simply track the most- current platform UIs. ---- Thanks for listening.
I'm currently working on a client framework based on the RCP, whereas the framework will be a part of a large commercial J2EE application. Business domain of this app is insurance/health care with an architecture somewhere in the middle between data-centric and workflow-oriented. For sure we will NOT use anything from the resource/project/etc stuff. So we are mainly interested in the high-level UI features (i.e. views, editors and perspective handling) and the plug-in model. The commitment of our management for the use of the RCP based on the OLD L&F and I'm sure I'll get into serious troubles when I must explain the switch to the new (and quiet different) L&F... The new L&F is no problem for me as an eclipse developer, but it's definitively one for the development of RCP apps. Therefore I vote against the most of the new 3.0 features: +1 (native l&f) - square view/editor tabs (as in 2.1) -1 - curvy view/editor tabs (as in 3.0 new look) 0 (tabs should almost "look" native) - native view/editor tabs (e.g. see the Java > Compiler pref page) +1 - always having a view titlebar (as in 2.1) -1 - never having a view titlebar (as in 3.0 new look) 0 - only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 - close button on view titlebar (as in 2.1) -1 - close button on view tabs (as in 3.0 new look) +1 - view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) -1 - view toolbars always on own row (as in 3.0 > M7) -1 - view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) +1 - double-click to maximize view/editor (as in 2.1) +1 - button for collapsing views (as in 3.0 new look) +1 - button for maximizing views/editors (as in 3.0 new look) 0 - fast views only on left (as in 2.1) +1 - fast views on any edge (as in 3.0 new look) +1 - perspective shortcuts at left (as in 2.1) -1 - perspective shortcuts in toolbar area (as in 3.0 new look) -1 - curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 - editor management using only tabs (as in 2.1) -1 - editor management using single drop-down (as in 3.0 new look default) 0 - editor management using 3.0 tabs ("Show multiple editor tabs" on Editors prefpage in 3.0 new look) 0 - no editor management (your app might not need editors) +1 (too flat look without shadows) - shadow border around views (as in 2.1) -1 - no shadow borders around views (as in 3.0 new look) +1 (border (separator) lines provides a better structured layout ) - border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) -1 - fewer border lines (as in 3.0 new look)
The real point is that I should be able to subclass a lot of these things myself. So I should be able to supply a MyViewPane that the workbench uses instead of ViewPane, of a MyShortCutBar to replace the standard shortcut bar. I know this is a non-trivial change but it is the right thing to do. For now +1 square view/editor tabs (as in 2.1) -1 curvy view/editor tabs (as in 3.0 new look) +1 native view/editor tabs (e.g. see the Java > Compiler pref page) +1 always having a view titlebar (as in 2.1) -1never having a view titlebar (as in 3.0 new look) -1 only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 close button on view titlebar (as in 2.1) -1 close button on view tabs (as in 3.0 new look) +1 view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) -1 view toolbars always on own row (as in 3.0 > M7) -1 view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) [Note that this feature has since been removed, but you can cast your vote if you liked them.] +1 double-click to maximize view/editor (as in 2.1) -0 button for collapsing views (as in 3.0 new look) -0 button for maximizing views/editors (as in 3.0 new look) -1 fast views only on left (as in 2.1) +1 fast views on any edge (as in 3.0 new look) -1 perspective shortcuts at left (as in 2.1) +1 perspective shortcuts in toolbar area (as in 3.0 new look) (prefer more contorl over them) -1 curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 But make it better if poss (scollable tab area?)editor management using only tabs (as in 2.1) -1 editor management using single drop-down (as in 3.0 new look default) -1 editor management using 3.0 tabs ("Show multiple editor tabs" on Editors pref page in 3.0 new look) - no editor management (your app might not need editors) - need em +0.5 shadow border around views (as in 2.1) -0.5 no shadow borders around views (as in 3.0 new look) -0.5 border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) +0.5 fewer border lines (as in 3.0 new look)
+1 (native l&f) - square view/editor tabs (as in 2.1) -1 - curvy view/editor tabs (as in 3.0 new look) 0 (tabs should almost "look" native) - native view/editor tabs (e.g. see the Java > Compiler pref page) +1 - always having a view titlebar (as in 2.1) -1 - never having a view titlebar (as in 3.0 new look) 0 - only having a view titlebar (and no tab) when standalone (i.e. not in a folder with other views) +1 - close button on view titlebar (as in 2.1) -1 - close button on view tabs (as in 3.0 new look) +1 - view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) -1 - view toolbars always on own row (as in 3.0 > M7) -1 - view toolbars dynamically hanging off the right edge (as in 3.0 M7 new look) +1 - double-click to maximize view/editor (as in 2.1) +1 - button for collapsing views (as in 3.0 new look) +1 - button for maximizing views/editors (as in 3.0 new look) -1 - fast views only on left (as in 2.1) +1 - fast views on any edge (as in 3.0 new look) +1 - perspective shortcuts at left (as in 2.1) 0 - perspective shortcuts in toolbar area (as in 3.0 new look) -1 - curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 - editor management using only tabs (as in 2.1) -1 - editor management using single drop-down (as in 3.0 new look default) 0 - editor management using 3.0 tabs ("Show multiple editor tabs" on Editors prefpage in 3.0 new look) 0 - no editor management (your app might not need editors) +1 (too flat look without shadows) - shadow border around views (as in 2.1) -1 - no shadow borders around views (as in 3.0 new look) +1 (border (separator) lines provides a better structured layout ) - border lines between menubar, toolbar, main workbench area, and status line (as in 2.1) -1 - fewer border lines (as in 3.0 new look)
Here is an update on our position regarding the impact of new look on the RCP effort in 3.0. We recognize that this is a serious issue for RCP apps and that the new look, as it is now, is a non-starter for many RCP apps. We are actively working on making the default look for RCP apps closer to the old look (more native) than the new look in the IDE. This is challenging since the new look work was originally done as a replacement of the old implementation, and retro-fitting it back is non-trivial. We plan to have an interim solution in place for M8, so please bear with us. Your feedback here is very helpful, so thank you for taking the time to express your thoughts. In particular, I find comment #7 to be an accurate and articulate summary of what people building RCP apps require, based on feedback we've received here, at EclipseCon and elsewhere.
"And there was much rejoicing". :) Seriously, thanks for listening, and keep up the great work.
Personally, I like a lot of what I am seeing in the new Eclipse look and feel. :) However, I have to say that I am disappointed that nothing has been done with the Eclipse Preferences dialog. It would be nice if Eclipse would borrow some ideas from Microsoft's IE6 Internet Options. - Frames have subtle curved corners - Frames have blue captions - Lots and lots of frames to group related concepts - Icons - Gradient buttons - Curved button corners (on XP) - Subtle background gradient on the tab - Occasional bold text - Ok/Cancel Buttons on different color of gray - Active tab has a yellow highlight
The button corners and other visual elements should already be picked up from the XP theme if you're using the javaw.exe.manifest file.
Thanks Nick für your response. It's good to know that you have recognized the impact for RCP clients. Does this mean that we will have a more native look for RCP apps and a different look for the IDE?
Oh... I did not know about the javaw.exe.manifest file. Wow... The only thing that this file doesn't seem to natively offer is the gradient background that extends from the tab.
Re comment #15, we view the visual elements of the new look in the IDE as being specific to the IDE stack. As far as the RCP effort is concerned, we want the default look to be close to native (perhaps not identical to Eclipse 2.1, but close), and we want to give the app flexibility for branding elements, as well as overall workbench window layout (the RCP APIs as of M7 do not give you much control here). What remains to be seen is how open we can make this. We're pursuing both avenues of (1) having various visual attributes settable via a theme and (2) allowing the app to provide a completely different implementation for how views and editors are presented (in addition to the overall window layout).
re: comment 17: so, what you're saying is that you have no intention of changing the look back for the IDE?
I think Nick is saying is: 1) RCP and the IDE are being considered separately in some places 2) What will happen with the IDE is not necessarily related to what happens in RCP
re: comment 19: well, since you seem to be responsible for the new look and you seem to like answering for others, perhaps you can answer the question. do you intend to change the IDE L&F back?
Michael's comments are accurate. I don't want this PR, which is about RCP requirements, to degenerate into a discussion about the new look in the IDE. There are other active PRs for that.
re: comment 21: it doesn't look good when you guys have to 'tag team' to avoid giving an answer... it was good of you to to release statements on this bug addressing the concerns of those who have commented on this bug and in the newsgroups, describing what you you intend to do to address those concerns. perhaps you can convince michael to do the same? while you guys are the major contributers and you have done a very good job overall, others have contributed or otherwise invested a lot in eclipse, and deserve to have input or at least be clearly informed as to what direction eclipse is going.
You all have been providing a lot of valuable input on the look and feel effort (and its impact to the rich client platform). Your comments have influenced our work so far, but we know there is more to do. We are going to spend the next week consolidating the feedback and adjusting our plan accordingly. We will have the updated plan by next Friday (Mar 5). Thanks for your patience and your investment in helping us make Eclipse as good as it possibly can be. I know we will end up in the right place. There has been a lot of discussion about this in many bug reports so I am pasting these comments several places. Sorry for the duplication, but I wanted to ensure maximum visibility.
i am heading up a project using eclipse's rich client platform. we like the the current look and feel (M7) and don't want to be forced into using the new look and feel when we upgrade to M8. please give us an option. Steve Polyak stephen.polyak@pearson.com
We are about to start a project to reimplement our product's GUI using the RCP (anyway this is currently the plan) and I am worried about the new look and feel. I fervently hope that this non-native L&F will not be forced on us... this would create a difficult (and, it seems to me, unnecessary) conflict for us between technology and appearance. The new L&F seems contrary to the SWT philosophy of letting java apps look like other native apps. I see that some of this is already configurable in the latest integration build (3/18) but just in case... +1 square view/editor tabs (as in 2.1) -1 curvy view/editor tabs (as in 3.0 new look) +1 native view/editor tabs (e.g. see the Java > Compiler pref page) +1 view toolbars embedded in view titlebar, or moving to its own row if needed (as in 2.1) +1 double-click to maximize view/editor (as in 2.1) +1 perspective shortcuts at left (as in 2.1) -1 curvy separator between toolbars and perspective shortcuts (as in 3.0 new look) +1 shadow border around views (as in 2.1) -1 no shadow borders around views (as in 3.0 new look) And: -1 Having no identifying icon at left of view toolbar when tabs are at bottom -1 Light blue color of active tabs and (especially) the 1 pixel border surrounding the active view.
We have run our RCP applications for the first time under the new workbench look and feel (using M8) - and frankly it looks awful compared to M7. Please allow RCP apps to look and behave in the same way as they did under M7. What is the status of this work?
The new presentation manager allows most aspects of the look to be changed. For example, using the org.eclipse.ui.examples.rcp.browser as a base, it is possible to give the PartTabFolder a more native look (e.g., remove the blue outline) by adding the following to BrowserAdvisor. static class BrowserPresentationFactory extends WorkbenchPresentationFactory { public StackPresentation createPresentation(Composite parent, IStackPresentationSite site, int role, int flags, String perspectiveId, String folderId) { if( role == ROLE_DOCKED_VIEW ) return new NativeStackPresentation(parent, site, flags); return super.createPresentation(parent,site, role, flags, perspectiveId, folderId); } } public void preWindowOpen(IWorkbenchWindowConfigurer configurer) { configurer.setPresentationFactory(new BrowserPresentationFactory()); // ... } The use of the internal class NativeStackPresentation is just to make this sample shorter, it needs to be replaced with your own implemenation of org. eclipse.ui.presentations.StackPresentation.
James, it would help to know the specific areas of concern for you. Could you talk a little bit about your app and target audience, and fill out the informal survey above? Please add extra comments if there are aspects of the M8 look that are not covered by the survey. It would also be helpful to hear from those who have already responded above as to how they feel about the L&F in M8, since there have been numerous improvements and some toning down of the "new look" compared to the patch in M7. Please indicate which items are most important for you. For M8, we were able to do several things to address the concerns here. 1. Added support for square tabs, which RCP apps get by default. This is equivalent to the "Show traditional style tabs" setting on the Workbench > Appearance preference page in the IDE. This addresses the vote for "+1 square view/editor tabs (as in 2.1)" / "-1 - curvy view/editor tabs (as in 3.0 new look)". 2. RCP apps now have control over the overall window layout (but are not required to customize it). See WorkbenchAdvisor.createWindowContents(...). We want the default layout to be reasonable for the majority of RCP apps. There is still more work to be done here in M9 to address the following known limitations: - The default layout still gets the banner curve between the toolbars and the perspective bar. This is an IDE branding element which should not appear in the default layout for RCP apps. - The default placement of the perspective bar at top right is not ideal. For one possibility, check the "Dock perspective bar under main toolbar" option on the Appearance pref page in the IDE (you'll need to resize the window after changing this to work around a layout bug). - There is currently no API for adding the fast view bar or the perspective bar to a custom layout. 3. Advanced RCP apps can replace the L&F for views and editors if the default is not acceptable using the "presentation factory" mechanism. This was illustrated by Andrew's example in the previous comment. We do not expect all RCP apps to have to do this. While we want to give the app control over this if needed, we do not want to promote a plethora of different L&Fs. It's also a non-trivial thing to get right. We want the default to be reasonable for the majority of RCP apps. Also note that the NativeStackPresentation used in Andrew's example is just an internal proof of concept at the moment (see bug 54857 for more details). We are now in the planning phase for M9. There is more work to be done here, but the end result will not be identical to M7. It would be helpful to know how people feel about the default L&F in M8, and which items are most important. To quote Patrick Paulin from above: "The problem with the new look and feel is that it crosses a subtle line defining the comfort zone of average users (not Java developers). The only way to find this line is through usability testing, but the line has definitely been crossed." Please let us know where you think we are in M8 with respect to this line.
>>Please let us know where you think we are in M8 with respect to this line.<< I'll talk about the two platforms I use regularly: Win2k: The colors don't work on Win2k, using the default color set. The view title bars wind up with black text on a navy gradient, which is nearly impossible to read. Also, the juxtaposed vertical and horizontal gradients in the views across the top of the Java Browsing perspective leave me feeling dizzy. Linux/GTK (With Keramik/Geramik theme and KDE as the windowing environment): This overall looks nice. The gradients here are subtle enough that they work fine and the color choices all seem reasonable. Actually, in this case, the gradients seem to make Eclipse fit in with the Keramik theme even better than 2.x did. The only issue I've noticed so far in Linux/GTK is the following: The default toolbar in the Keramik/Germaik theme uses a gradient background to make it look curved. However, the curvy separator for the perspective switcher is drawn on a "flat" (non-gradient) background, which makes it look really out of place in the context of this particular theme. Since that theme is the default KDE theme, this will be seen by a lot of folks who use Eclipse on Linux/KDE. It would be nice if that seperator widget could pick up any gradient that is used by the platform's theme on toolbars and use it in the separator's background as well. Then the separator would look native even if it wasn't. Regarding your question about the placement of the perspective switcher, I prefer all the way to the right on the tool bar over using more vertical space for it. Vertical space is normally more precious than horizontal space, so given a choice, I would prefer the perspective switcher either where it is by default in M8 or where it was in 2.x.
David, what system colour/theme settings are you using on Win2K? I run it on my laptop with the defaults and it looks OK (light blue background for tabs, with black text).
"Windows Default" is the theme.
BTW, I posted screen shots showing the problems in bug 52780 (that was before the request for feedback came here).
One last request that I think I might have made elsewhere (but I can't find it right now, so I apologize in advance if it's repeated): I really like the new collapsable views. The one thing I miss is that with the old fast views, when you click on a non-fast-view, the fast view automatically hides itself. I'd like a closed-lock option for the new collapsable views that provides this behavior. ie: when it's enabled, giving the collapsed view automatically expands it, but giving any other view the focuse collapses it again. Maybe this could be implemented via a separate toggle on the view. Maybe this could be done using the existing button by giving it 3 states: open, closed, closed/locked.
I've filed bug 58021 for the problem with tabs being illegible if the system titlebar colours are dark.
Is it the case that RCP apps are able to use the new R21 presentation. If so - how? Can this be done programmatically?
RE comment 35 The r21presentation is selected based on some preference settings, specifically the ones listed in org.eclipse.ui.internal.r21presentation/r21presentation.ini. The current set (very unlikely to change) is: org.eclipse.ui/presentationFactoryId to "org.eclipse.ui.internal.r21presentationFactory" org.eclipse.ui.workbench/VIEW_TAB_POSITION to SWT.BOTTOM org.eclipse.ui/DOCK_PERSPECTIVE_BAR to "left" org.eclipse.ui/initialFastViewBarLocation to "left" There are several ways to set preference values, See: http://dev.eclipse.org/viewcvs/index. cgi/~checkout~/platform-core-home/documents/user_settings/plugin_customization. html See also bug 59850 comment 30 and 31.
Re comment 36: Andrew - many thanks for your response on this issue. I must admit that I'm still finding this tough going, it feels much more difficult than it should do. In my context only option 4 works out of the four options listed in the document you reference. Even then, it doesn't work well because I must give an absolute path to the .ini file. Option 1 in the first case doesn't make sense to me - what am I suppose to do in initializeDefaultPreferences() (the documentation really needs bolstering here) and in the second case I can't do because I'm not using rumtime compatibility. Option 2 doesn't seem possible in a self hosting environment. It seems that option 3 would be the most appropriate for my application, but it is not at all clear from any of the documentation how to go about this. My product is defined programatically and I can't see any reference to the org.eclipse.core.runtime.preferences.customization property. For example, this is never requested by my getProperty method in my implementation of IProduct.
In comment 36 I forgot to mention the following preference: org.eclipse.ui/SHOW_TEXT_ON_PERSPECTIVE_BAR to false I'm working on a sample to set the preferences programatically. I'll update the readme and post a note here when its ready.
Created attachment 12841 [details] doc patch This patch for the docs in platform-ui-home adds an example of how to set the R21 presentation on an RCP application. The patch adds a question to the FAQ and and an example (pointed to by the FAA) in the main page (between the Browser and Text editor examples). Also, I noticed that the faq was inconsistent in terms of putting a blank line before each answer. For consistency I changed the file so that all answers are preceeded with a blank line.
The patch has duplicates points 2 and 3: 2. Build and deploy the org.eclipse.ui.presentations.r21 plugin. 3. Build and deploy the org.eclipse.ui.presentations.r21 plugin. point 6 also says: remember to edit the osgi.bundles property (in ./eclipse/configuration/config.ini) to include the two new plugins. but there should only be one new plugin.
Opps -- originally I had included instructions on deploying the RCP browser as well. I thought I removed all those references after I added the link to the browser example. One of point 2/3 can be removed. I'm not sure what to do about point 6. It but also might be a bit distracting, perhaps it should be removed altogether? Considering that the reader would have to follow the same steps to deploy the rcp browser plugin, perhaps the extra points aren't needed.
I've released the patch with 3 changes: - removed the duplicate point - in the last point, changed "the two new plugins" to "the new plugin" - added some screen shots for the default look and the R2.1 look Closing this bug as the work on the presentations mechanism and the R2.1 presentation satisfies the original requirement and the needs of most of the responses above. Other presentations can be written by ISVs if the default presentation and the R2.1 presentation do not meet their needs (I'd love to hear of any other interesting ones being developed).
