Community
Participate
Working Groups
This bug is tracking the visual design work for the e4 workbench. That is, the "default style" that the e4 workbench will have out of the box. The planning for this work is documented in http://wiki.eclipse.org/E4/CSS/Visual_Design. This bug is opened to share mockups as the design progresses and collect feedback.
Susan, one of the capabilities that the E4 model rendering strategy has but is not readily apparent is that we can have different 'stack' or 'tile' implementations. So we can, for example, have the 'perspective' stack just use a Composite rather than a CTF if we want the current 'look' but we could also use a different form of stack altogether. Some of the 'new' widgets from nebula (PShelf, PGroup...) might be worth looking at as possibilities.
Ribbon not bad, through the tabs not accepted by me. For most simple applications, too many space remains. I think combine eclipse perspective bar with Ribbon content part would be nice. Of cause the perspective bar should not fix its direction. And how about remove menu bar element, ribbion function part can present drop down menu. Find some time, I would paste a picture to attach.
I've had several folks asking when we'll have mockups to show. We've been trying to balance sharing ideas early with having a direction that we are starting to believe in. Also we don't want to get too focused on little details before we feel we have an overall theme. But we need something for those Christmas stockings! I'm getting ready to attach a few "preview" mockups that show what our visual designer is up to. These mockups are intended to show a general direction, but aren't mature as far as individual design elements. We've been playing with different elements and have just started putting them together. We will be exploring each individual element and iterating different design variations. The focus here is on "big picture" issues such as use of white space, guttering, an overall visual theme, blending with platform hues, etc. We'll keep posting mockups as we add more detail and iterate the individual design elements. A summary of the work is on the wiki at http://wiki.eclipse.org/E4/CSS/Visual_Design We are currently focusing on the visual design/theming, and some changing of the organization of the UI at the view/editor level. We aren't touching (yet) farther reaching issues such as using a ribbon instead of a toolbar, animating the toolbar, or putting things in the platform trim. Nor are we touching interaction design changes - use of perspectives, etc. Okay, disclaimers aside: comments about any/all of it are welcome. Here are some of the design elements in play: - removal of bordering around view content and use of white space around the content to give consistent edges - simpler part stack bar (removal of tabs) and emphasis on the selected tab - movement of view toolbars to their own vertical space to provide visual consistency and added white space - a local editor toolbar (in same place as view toolbar) - "plated" outline of parts with shadowing - enhanced shadowing on active part - fading of tool icons when part is not active - removal of view tab icons except for front tab - heavier treatment of toolbar and shadows to blend between platform hues and SDK colors - fading of view min/max and tab close controls (more emphasis when user is hovering) Things not shown we want to play with - intensity of platform hue (how much blue/olive/etc. to bring into the toolbar or view backgrounds?) - fading or removal of scrollbars when part is not active - fading or otherwise deemphasizing the application toolbar - placement of perspective switcher - global search bar - visual feedback/animations for moving parts and stacks
Created attachment 154950 [details] win7 mockup mockup inside a Win7/blue themed shell. The amount of blue to be picked up by the background colors, toolbar, etc. is unknown - the idea though is that colors are respecting the hue in someway while not necessarily using the colors directly.
Created attachment 154951 [details] WinXP olive mockup mockup inside a WinXP/Olive themed shell
Created attachment 154952 [details] mockup in a Mac (Cocoa) shell the tab text fonts in this mockup aren't quite right, the designer didn't have the exact Lucida font that Apple uses, so she had to pick something close. In a real implementation the fonts would be from the platform.
In future iterations we'll have mockups also shown on Ubuntu and RHEL. We simply ran out of time to get all the cut/paste iterations needed.
(In reply to comment #3) > - removal of view tab icons except for front tab The mockups look good except for the above one item. I think its better to have icons. Pictures are always quicker and easier to identify the item, rather than reading the characters (one can know the time by having a glimpse at the analog clock rather than the digital clock - the reason why most of the clocks are analog). Its easy to recognize a tab by its icon rather than by reading the title. And also assuming we go without an icon, what happens if the title has two words (Package Explorer, Project Explorer, ...). Won't it appear as if there are two views?
I've created a separate bug (bug 298481) discussing the ribbon concept. If this gains traction for e4, we might want to consider doing mockups in a "ribbon mode" besides the various platforms. This issue is called out separately because it's goes beyond visual theming and because it has different dependencies.
I think the drop shadows are too heavy. Also, why is the Mac toolbar not flat? Look at any native Mac app (Firefox, Finder, Safari, ...) - no drop shadow, no 3D look, and no separation between the title pane and the toolbar.
Some comments regarding the mockups: Good work, the overall look is very nice, although there is too much white space for a program like an IDE, which shows a lot of information in very dense screen real estate. I don't like how the editor tab headers look in a part with rounded corners. The border radius of the parts could be a little bit less.
(In reply to comment #11) > Good work, the overall look is very nice, although there is too much white > space for a program like an IDE, which shows a lot of information in very dense > screen real estate. I disagree - not wasting screen real estate used to be really important ten years ago when 1024x768 was the norm. Nowadays, we ought to have a few extra pixels that we can spend on making things look less crowded.
Overall good ideas, but I agree with Kirill: the drop shadows are too big. Furthermore the icon set does not fit well to this kind of design.
Here are my comments on the mockups, posted originally on the e4 mailing list (sorry about that :-)) 1. I like the rounded corners and the general open feeling. I can see how this design would work well for Eclipse apps targeted at the web. 2. The flip side to this, though, is that the design introduces quite a bit of white space. I'm generally a fan of white space, but this might be too much for an IDE. I understand Boris's point about monitor sizes, though I usually work on a laptop and space is still an issue for me. 3. The design discards some boundary definition that I find helpful. Particularly in the editor tabs, where the class names all blend together.
The current mockups have a lot of modern / trendy Web design elements in them - rounded corners, plenty of whitespace, eminent drop shadows, 3D backgrounds etc. I do strongly feel that this is way over the top. These elements should be used not because we can (larger screens, faster CPUs, cool code to write), but because it helps using the UI. White space is good for offsetting elements, preventing clutter, adding elegance and enhancing readability. Among all of these, the only relevant one is preventing clutter, and the current Eclipse can benefit from removing a lot of vertical / horizontal lines around and between different views. Rounded corners are good for adding a "humane" look to the otherwise rigid and precise rectangular areas. Smaller corner radius looks much more sophisticated then bigger corner radius. I think that the current look of Eclipse tabs is very good, and i do like the rectangular corners in what is essentially a "powerhorse" application that i work with 8-10 hours a day. Drop shadows and 3D backgrounds are used to create the illusion of depth. Along with the recent trend of wrapping ribbons (see the last link below) they can create the layered look and "raise" the specific UI areas in order to guide the user eye towards them. I would rather not have Eclipse UI have areas that compete for my attention. I prefer as flat a look as possible, so that i can concentrate on the code that i'm writing without the "chrome" of the surrounding view trying to get my attention. Overall, we should exercise restraint and only use design elements that will make working with Eclipse a more streamlined and pleasant experience than it is today. Adding trendy design elements just because we can is a bad thing (TM). Kirill http://webdesignledger.com/tips/whitespace-the-underutilized-design-element http://www.webdesignerdepot.com/2010/01/drop-shadows-and-gradients-be-consistent-in-your-visual-metaphors/ http://blog.creativityden.com/the-six-fundamental-ways-of-adding-depth-to-your-designs/
I'll attempt to reply to several comments here. Thanks for the comments thus far... (In reply to comment #8) > I think its better to have icons. Pictures are always quicker and easier to > identify the item, rather than reading the characters (one can know the time by > having a glimpse at the analog clock rather than the digital clock - the reason > why most of the clocks are analog). Its easy to recognize a tab by its icon > rather than by reading the title. And also assuming we go without an icon, what > happens if the title has two words (Package Explorer, Project Explorer, ...). > Won't it appear as if there are two views? I've opened bug 299535 for this discussion. Where we have some specific detailed question such as "what to do with view/editor icons" I think we should open a separate discussion. This bug can be the tracking but and focus on "big picture" issues such as whitespace, overall direction, etc. For some of these "should we do XYZ" questions we may set up a poll on that issue for input. (In reply to comment #10) > I think the drop shadows are too heavy. Drop shadows are under iteration for sure, point taken. Another point made offline was that the difference between active drop shadow and non-active is not very distinct so it almost looks accidental. > Also, why is the Mac toolbar not flat? > Look at any native Mac app (Firefox, Finder, Safari, ...) - no drop shadow, no > 3D look, and no separation between the title pane and the toolbar. The first mockups did not attempt to differentiate by platform, but rather to show what things look like in each platform. The toolbar shadowing was an attempt to clearly separate platform trimmings from the eclipse content, and to provide transition from platform derived to colors to (possibly) altered colors. (In reply to comment #11) > Some comments regarding the mockups: > > Good work, the overall look is very nice, although there is too much white > space for a program like an IDE, which shows a lot of information in very dense > screen real estate. This (as noted by Boris' comment below) is a fairly subjective matter. Note that we will include a "classic style" for those who like the current state of the world > > I don't like how the editor tab headers look in a part with rounded corners. > The border radius of the parts could be a little bit less. The treatment for the selected tab is definitely under iteration. The designer put something together quickly, the main point right now is that we are trying to deemphasize the overall "tabbiness", provide a muted look for non-active parts, and some treatment for the selected tab. (In reply to comment #13) > Overall good ideas, but I agree with Kirill: the drop shadows are too big. > Furthermore the icon set does not fit well to this kind of design. Kai, can you elaborate on that last remark? You mean the existing icon designs not fitting in? (In reply to comment #14) > Here are my comments on the mockups, posted originally on the e4 mailing list > (sorry about that :-)) > > 1. I like the rounded corners and the general open feeling. I can see how this > design would work well for Eclipse apps targeted at the web. > > 2. The flip side to this, though, is that the design introduces quite a bit of > white space. I'm generally a fan of white space, but this might be too much for > an IDE. I understand Boris's point about monitor sizes, though I usually work > on a laptop and space is still an issue for me. This flipside is what we are pushing/pulling with. Also, note that we aren't saying this is the visual style to be used for apps, the question is what style will be the default one for the 4.0 SDK? So we are trying to look a little more modern/webby on the client side. As noted above, we'll have a "classic look" where screen real estate is an issue, but we want the "new look" to be decidedly different. > > 3. The design discards some boundary definition that I find helpful. > Particularly in the editor tabs, where the class names all blend together. See bug 299535, I think there's work to do there (via icons or separators or both)... (In reply to comment #15) > White space is good for offsetting elements, preventing clutter, adding > elegance and enhancing readability. Among all of these, the only relevant one > is preventing clutter, and the current Eclipse can benefit from removing a lot > of vertical / horizontal lines around and between different views. Yes, the goal here was to remove a lot of key lines and use guttering for separation. Also to supply some "relief" between scrollbars and the edge, as the design definitely plays differently when there are scrollbars involved > > Rounded corners are good for adding a "humane" look to the otherwise rigid and > precise rectangular areas. Smaller corner radius looks much more sophisticated > then bigger corner radius. I think that the current look of Eclipse tabs is > very good, and i do like the rectangular corners in what is essentially a > "powerhorse" application that i work with 8-10 hours a day. > > Drop shadows and 3D backgrounds are used to create the illusion of depth. Along > with the recent trend of wrapping ribbons (see the last link below) they can > create the layered look and "raise" the specific UI areas in order to guide the > user eye towards them. I would rather not have Eclipse UI have areas that > compete for my attention. I prefer as flat a look as possible, so that i can > concentrate on the code that i'm writing without the "chrome" of the > surrounding view trying to get my attention. > > Overall, we should exercise restraint and only use design elements that will > make working with Eclipse a more streamlined and pleasant experience than it is > today. Adding trendy design elements just because we can is a bad thing (TM). > > Kirill > > http://webdesignledger.com/tips/whitespace-the-underutilized-design-element > http://www.webdesignerdepot.com/2010/01/drop-shadows-and-gradients-be-consistent-in-your-visual-metaphors/ > http://blog.creativityden.com/the-six-fundamental-ways-of-adding-depth-to-your-designs/ I'm thinking you might like some early unpublished mockups which really had no chrome at all (see: Tufte and data pixels), but we all felt it looked kind of "dead." I will look for a screenshot. Our feeling is that if we can style the more complex one, it should be pretty trivial to restyle to the flatter look. Remember that all this is about the default stylesheet for eclipse, and anyone/everyone will be encouraged to submit alternates. We would hope to have a pretty rich set of alternatives...
(In reply to comment #13) > Furthermore the icon set does not fit well to this kind of design. See bug 299717
Created attachment 160385 [details] current mockup state (M4) - win7 Here is the latest mockup, shown on Win7. This is still a designer's mockup, not a running implementation. I thought it would be useful to post it since there is an early prototype of the rounded tab stacks, shadows, and tabs in M4. Changes since last mockup: - view and editor icons are back - maintains the overall direction for rounded stacks with shadows, but tightens up corners and shadows - simplifies selected tab rendering on active part stack - introduces "selection color highlight" to active part stack - maintains a stylized toolbar treatment to provide transition from platform trim to custom look, but reduces the shadowing - introduces subtle selected tab emphasis in non-active stacks
To me, even with the latest design mockup the thing that jumps out at me is the view/editor toolbars. There is plenty of space for them to be on the same visual line and not steal horizontal space from the content of the view/editor. I would love for there to be a settings to control the UI. I don't want to have to choose completely between 100% old and 100% new. But in the same way, I can tweak the code formatter to do things my way, I would like to turn off toolbars on separate lines. Provide functionality like that and many people will be happy.
(In reply to comment #19) > To me, even with the latest design mockup the thing that jumps out at me is the > view/editor toolbars. There is plenty of space for them to be on the same > visual line and not steal horizontal space from the content of the view/editor. > I would love for there to be a settings to control the UI. I don't want to > have to choose completely between 100% old and 100% new. But in the same way, > I can tweak the code formatter to do things my way, I would like to turn off > toolbars on separate lines. Provide functionality like that and many people > will be happy. understood. We are trying to identify "the things people will definitely want to control" that they shouldn't have write CSS to change. In other words, the things that should be configurable even if someone likes the overall look and feel. So far, I'm aware of: - should editors have their own toolbar? - should view (and possibly editor) toolbars have their own reserved row or render on the tab stack as they do today? - location of perspective switcher. others?
Created attachment 162902 [details] win7 mockup win7 mockup shown at eclipsecon - adds search box and perspective switcher
Created attachment 162903 [details] latest mockup - winxp olive
Created attachment 162904 [details] mac cocoa mockup - flatter toolbar mac mockup includes a flatter toolbar
Created attachment 162905 [details] linux GTK mockup
Susan, have you ever considered having the PerspectiveSwitcher be a ComboBox ? IMO, this solves the layout issues associated with the PS getting longer and longer (avoiding the grotty '>>'). Also means we wouldn't have to support space saving options like 'Show Text'...
(In reply to comment #25) > Susan, have you ever considered having the PerspectiveSwitcher be a ComboBox ? > > IMO, this solves the layout issues associated with the PS getting longer and > longer (avoiding the grotty '>>'). Also means we wouldn't have to support space > saving options like 'Show Text'... A combo box would reduce UI visibility (IMHO) in that it would show you only the current perspective open and not all that a user has opened. I tend to keep 3 open all the time in a specific order and a combo would negate this.
If you have three open all the time why do you need to see them ? I'm not just defending the idea, I'm just trying to determine if there's any viable way to reduce the complexities we've managed to introduce to the PS...the current one has the "Open Perspective" 'button' (it's not a button but a drop down menu and also has a different menu when you right-click on it, quite odd IMO). Admittedly switching perspective using a combo would mean it's no longer a one click operation but a two click one. Folks that find this too inconvenient could always attach a key binding for their favorites. I'm just starting to work on a simple PS for e4 today, first cut will be ToolBar based rather than Combo so no worries. If it turns out to be as easy as I hope I'll make a second one based on a combo just to see...
Uh, no. Please no combos or drop-downs. The current art of perspective switching provides good usability. I get to see the icons and it's fairly easy to switch between them. I also like that I can arrange the icon the way I like it. Now, imagine a Windows 7 taskbar with a drop down instead of presenting the icons next to each other...
Good point...
Have you considered putting the most frequently used icons first? The rationale is that the mouse finds the edges of the screen easier. For me the most clicked icons would be the debug / run icons. Nobody I know uses the save icon (Ctrl+S instead) or new icon (context menu > New instead). Also I would have expected the search box on the right, since I'm used to that from browsers (Firefox, Chrome, IE).
Search box in the top-right corner is not only a browser convention. See iCal, Apple Mail, iTunes, Finder - and all other Mac applications.
Created attachment 164653 [details] Screenshot Looking at the running system I also think that where is too much whitespace. I think the whitespace on the right side is perfect, on the left side I personally think it is too much. I add a screenshot which explains what I mean.
(In reply to comment #31) > Search box in the top-right corner is not only a browser convention. See iCal, > Apple Mail, iTunes, Finder - and all other Mac applications. Not only on the Mac - on other platforms and with other apps, the canonical location for the search box is in the top right corner.
adding some blocking bugs - these represent work we are trying to do for 1.0 to bring the look closer to the latest mockups
Created attachment 169725 [details] latest win7 mockup
On the latest mock-up the perspective bar looks like some sort of tab header as it has same background as working area of the window. Would it make sense to extend this to make it look tab-like (i.e. one icon + optional label on a light background and others on the darker one)? Though it looks like there will be too many tabs-on-tabs.
Is the global search field still planned for the UI and more importantly is it configurable in its presence? To me, that is a hugantic (bigger than ginormous) amount of toolbar space to give up to a field a user might have never needed to date. If I had to have something on the toolbar a pulldown menu that opens to the global search field would be best from a space savings standpoint.
Personally I would like it more if the search-box was on the right side of the screen. This is the common location for the search element in other apps.
(In reply to comment #38) > Personally I would like it more if the search-box was on the right side of the > screen. This is the common location for the search element in other apps. +1
(related to comment #37 + comment #38) It looks like the search bar is a tool item. This allows it to be removed as well as placed on any side of the tool bar. I think that's a good compromise given that the right most location is dedicated to the perspective switcher. Now ... if we could only get that menu replaced with a ribbon.... ;)
I updated bug 304440 with discussion about turning search box on/off, placement. We'll have to figure out our story for docking search (and the perspective bar, which is bug 314163).
removing blocking bugs that are no longer visual design issues.
I was wondering if it's possible to change/update the default fonts on Windows 7 as part of the new look? For example, Windows 7 comes with "Consolas" font which renders better than Courier New.
(In reply to comment #43) > I was wondering if it's possible to change/update the default fonts on Windows > 7 as part of the new look? For example, Windows 7 comes with "Consolas" font > which renders better than Courier New. Are talking about the fonts in the editor? Those are not controled by CSS but the Editor font settings.
(In reply to comment #44) > (In reply to comment #43) > > I was wondering if it's possible to change/update the default fonts on Windows > > 7 as part of the new look? For example, Windows 7 comes with "Consolas" font > > which renders better than Courier New. > > Are talking about the fonts in the editor? Those are not controled by CSS but > the Editor font settings. Yes. But it doesn't matter what technology is used to set/configure those. Just wondering if it should be considered as part of the look update.
The problem is that we are not in control of them because they are contributed through bundles we have no R4_branch. IIRC the text fonts are defined in the org.eclipse.ui and point to the JFace-Text fonts who are defined by JFace. Looking at JFace there is not jfacefonts_win7.properties. Do you know what value System.getProperty("os.name") gives you? Looking at the logic in FontRegistry adding a fragment which holds jfacefonts_${win7os}.properties should give you default fonts like you want to have them :-)
Thanks Tom. Opened bug 320616.
Is it intentional that the toolbar gradient doesn't end (going from top to bottom) in the same colour as the background of the toolbar buttons? For an example of how pronounced this looks on modern GNOME desktops, see here: http://fedorapeople.org/~overholt/4x.png
In reply to comment 49. Hi Andrew, Thanks for the feedback. Yes the design was intentional. The design rationale was to create a distinctively "Eclipse" cross platform appearance style below the menu bar. The more pronounced lip at top of toolbar creates separation from the area above and is visually related to the style of the selected workbench pane.
oops correction: comment 49 was in reply to comment 48.
(In reply to comment #49) > Yes the design was intentional. The design rationale was to create a > distinctively "Eclipse" cross platform appearance style below the menu bar. The > more pronounced lip at top of toolbar creates separation from the area above > and is visually related to the style of the selected workbench pane. Thanks for the reply, Linda. It's definitely distinctly Eclipse :) I think it looks a bit out of place and rather jarring since it doesn't transition cleanly to the colour below it, but I'm not a designer so I'll shut up now ;)
Created attachment 221237 [details] Wasted space marked
Created attachment 221238 [details] Comparison with Chrome Dear Eclipse Team, I switched from 3.7 to 4.2 today and honestly, I'm quite disappointed concerning the UI. I'm using eclipse mainly on my notebook and effective screen usage is a crucial point there, but not only there. 3.7 was far from perfect in this aspect, but unfortunately it became even worse with 4.2. It's not bars and frames that I want to see, it's the content, the code, that I want to work with. A good IDE should make this easy by showing me as much code as possible on the screen. Looking at other applications, especially browsers, can give some good ideas, as there were similar discussions about user experience and usability concerning content and limited screen sizes, and they already found some good solutions, which would be a interesting for eclipse, too. I made a screenshot from my freshly installed 4.2 and made some comments on efficient screen usage in it, which I'd like to further explain here. 1. Main menu Some OS allow to put the main menu directly into the OS application bar. I'm using Ubuntu, and it works like a charm with all other applications there. If the mouse is over the bar, the main menu is shown, if the mouse is somewhere else, it displays the application title. As bars are one of the main vertical space waster, this UI feature should also be supported by eclipse. 2. Toolbar Toolbars are nice for beginners, to give them an overview and direct access to functions, without memorizing any shortcuts. When you use an application for a while, you tend to use shortcuts more often, so that you don't have to move your hands from the keyboard to the mouse. This process makes a toolbar quite redundant for IDEs, after the programmer is somewhat confident with the IDE. In consequence, every toolbar has to be able to be disabled. In 3.x it was easily possible, in 4.2 this important possibility to save screen space became practically removed. And even worse, the toolbar became much wider than it has to be, so it wastes much more space then necessary, even if the user really want's to display it. 3. Scroll bars Scroll bars generally tend to waste a lot of space without containing any relevant information, if they're not actively used. That was the reason, why they became reduced to some display-on-mouse-over-thingy in Ubuntu. This works quite well and could also be used in eclipse. Chrome had another aproach, to make them more usable, and combined the scroll bar with the search entry display bar. So break points, tasks etc, could be displayed there already. Any of these ideas would be exactly as useful for eclipse, as they are for Chrome or Ubuntu. Horizontal scroll bars should generally only be displayed, if they are required. Many programmers tend to keep some maximum width of their code for better overview anyways, so most of the time, the horizontal bars are totally useless. 4. Bottom bar One of the main space wasters in eclipse, which also can't be deactivated. If I'm using the file browser, it tell's me the number of files selected. If I'm editing text, it tells me the cursor position, if the file is writeable, and the edit mode, overwrite or insert. None of these information justifies the huge amount of space wasted, and all this information could be displayed, in a different way. Comparing to browsers again, most of them had in former times a similar bottom bar, which displayed the linked url, if you hovered over a hyper link. So if you didn't hover over a link, it was basically displaying nothing. So as the url is relevant information, which I want to see, before I click on a link, it doesn't have to be there all the time. Chrome fixed that with a nice, dynamically field in the lower left corner, which is only displayed, when there is acually something to display. Information, if a file is writable should be seen on the files tab. Some slightly different tab color for non-writeable files will do. Insert or overwrite only seems to be displayed, to put there something at all. The cursor itself already blinks as a line or as a block, so this is totally redundant. Cursor position could be displayed dynamically with this chrome mechanism, as soon as the cursor keys are used. 5. Problems tab A whole line is used for displaying information, which could also be shown in the header itself. 6. Separators and lines Maximizing visible area necessarily means minimizing frames, borders and paddings around the content areas. But even in full screen mode, on left and right side of the screen there is a frame displayed. Well ... my screen already has a hardware defined frame, I don't need another painted one there. Same applies to the frames between the content panes. They should be reduced to absolute minimum, maybe half the size they currently have. ---- So taking this all together, the usable screen for displaying the content would be increased drastically. It would make eclipse fun to use on notebooks with 1400px width and below, and also increase the efficiency, if screen size is not that limited. I really hope, that eclipse developement will catch the drift and starts focusing more on the content again.
Michael, I haven't run Eclipse on Ubuntu in the last couple of months, but when I did the Eclipse menu bar did appear in the application bar. There was support for overlay scrollbars (the OS X-like disappearing scrollbars), but it seems it was backed out for 3.8/4.2 due to crashes (bug 373618). The toolbars can be made to disappear, but there was a bug in 4.2 (bug 378835) that has been fixed for 4.2.1 (due out Sep 28). You can use CSS to restyle many of the elements, including making them disappear ("#org-eclipse-ui-trim-status { visibility: hidden; }"). You can experiment with the CSS Spy and Scratchpad (found in the Eclipse Marketplace) to craft CSS to do the right thing. Note that you may need to trigger a relayout (e.g., by resizing the window) or open a window for the effects to properly take effect.
Hi Brian! Thanks for your hints. Good to see, that some of the issues are alredy addressed. I gave the CSS Editor a try, to slim down the UI. Unfortunately there is another downside with visibility:hidden. It doesn't make the css item disappear and make the item space usable, it just let's the content of the item disappear, so that an empty unusable grey space remains (build 20120614-1722). Also, I couldn'n shrink the huge borders on the sides. Setting padding of #IDEWindow and margin of #PerspectiveStack to zero didn't do anything.
FYI: Great CSS styling can be found here: https://github.com/jeeeyul/eclipse-themes
These are really good points, Michael. The basic elements of the default 4.2 layout were essentially in place two years ago (see screenshot mockups on this bug). At the time it seemed cutting edge but the world has gone and changed again on us ;) I think especially Chrome has taught a lesson in how to get out of the way of the content entirely and for at least some Eclipse users this is a desirable direction. Luckily the principal goal in 4.x was not the design changes themselves, but putting in place a mechanism that makes these kinds of design changes easier in the future. As Brian points out you can now make many changes without touching any code, that previously required extensive manual hacks. I think at least some of your concerns can be addressed with these new mechanisms very quickly. However at least some of your suggestions would require more code changes. I suggest you open new bugs for at least your scrollbar comments, and the bottom bar comments. While we can make the bottom bar disappear easy enough, your suggestions require moving some of that information elsewhere which is more than just a cosmetic change.
Created attachment 221348 [details] Editor Chrome comparison I think this screenshot is a better illustration of Michael's comparison to Chrome. This shot shows an Eclipse editor and an Orion editor in Chrome on the same file. You can see the large amount of extra space on the right and bottom available in Chrome where every single pixel is given to the content.
I'm actually going to mark this bug fixed, since it capture the design that was delivered in the 4.2 release. Put anyone please feel free to open new bugs for ideas for the future.
