Community
Participate
Working Groups
One of the major complains I hear is that the new styling of Eclipse 4 wastes a lot of space. I suggest to reduce this to a minimum in the default themes and see if community themes go a different way.
Simple suggestion: https://git.eclipse.org/r/17743
+1 for Lars change It's a good start in the right direction
Lots of people on EclipseCon Europe complained about the excessive use of whitespace in the current theme, the suggested patch reduces the usage.
*** Bug 362423 has been marked as a duplicate of this bug. ***
@John, can you have a look at the review? I think it is important to improve the L&L of the Eclipse IDE and the waste of space is a common complain.
(In reply to Lars Vogel from comment #5) > @John, can you have a look at the review? I think it is important to improve > the L&L of the Eclipse IDE and the waste of space is a common complain. I'm not the right person to ask because I actually like the spacing in Eclipse 4 over Eclipse 3 - it looks cleaner to me and on modern high resolution displays a few pixels really doesn't matter. I would be curious to hear what others think. Also we need to see how this looks on different platforms. I have been thinking of the idea of creating a new theme where we can try out different ideas and then collect community feedback and use that to decide what becomes the default for the next release (and maybe hide/remove the old theme if there is wide agreement new one is better).
> I'm not the right person to ask because I actually like the spacing in > Eclipse 4 over Eclipse 3 - it looks cleaner to me and on modern high > resolution displays a few pixels really doesn't matter. I would be curious > to hear what others think. Also we need to see how this looks on different > platforms. > > I have been thinking of the idea of creating a new theme where we can try > out different ideas and then collect community feedback and use that to > decide what becomes the default for the next release (and maybe hide/remove > the old theme if there is wide agreement new one is better). Whitespace is of course a question of taste. Maybe we can make a poll and ask Eclipse users for their opinion? I'm happy to set this up but if you would prefer setting up the poll, this would also be great.
In my experience, as said by John, there is not so much whitespace waste if Eclipse is used on a common desktop/laptop display, the waste of space instead comes out when the Eclipse window becomes smaller and/or when a lot of perspectives are open in the upper toolbar, in those cases the #PerspectiveSwitcher becomes too wide to fit in the same line and #org-eclipse-ui-main-toolbar doubles its height by wasting a lot of space in the bad cases (the same happens when a lot of .MToolBar are shown as for the shortcut icons). With the current CSS engine capabilities, only little and not scalable modifications can be performed to improve space usage. If I may suggest, some possible wider solutions/workarounds (that do not rely on some CSS properties modification) might be: - Setting automatically as hidden the text of the perspectives names in the ToolBar when the sum of all the widths of the .MToolBar/.MToolControl in #org-eclipse-ui-main-toolbar exceed the width of its container (this can be already done manually by right clicking on the perspective buttons); - Hiding automatically the less important/used icons or simply the rightmost shortcut icons in #org-eclipse-ui-main-toolbar when all of them don't fit in the line (this is what most GUIs usually do); - Enhancing the CSS engine in order to allow the setting of percentage (calculated according to the control's container or shell dimensions) for margin and padding (this is what happens in regular CSS); - Allowing the user to tweak the GUI as he/she likes in Preferences > Genaral > Appearence by adding an option to remove some optional GUI controls that can be useless for the user and waste space, like the #org-eclipse-ui-main-toolbar or #org-eclipse-ui-trim-status (this is one of the most appreciated feature of the IntelliJ GUI, in that way you can give it a simple editor appearance and focus on the code written); - Enhancing the SearchBar capabilities in order to be similar to what can be achieved eg. in Sublime Text 'Goto Anything' feature, this will significantly speed up a user workflow and makes useless to have all the shortcut icons in the upper toolbar (those are already pretty redundant when the same action can be found in the upper menu or with a keyboard shortcut). These are obviously some possible more generic improvements, but I think they are something users are expecting from the GUI of an IDE today to avoid wasting screen space.
OK, I see this bug is about Linux, but on Window 7 we have the same problems. Besides the spacing, the theme makes it hard to e.g. see active parts (bug 325937 and bug 374027). Lots of people complain about the current default and it this was also brought up in the IDE BOF at EclipseCon Europe. Most people are again happy(er) when switching back to the Window 7 Classic theme, which solves those issues. Same request is available for Linux (bug 385676). So, at this point, we should simply make the Windows 7 Classic theme the default. For Linux I can't really tell whether the Classic theme would also be the better default, because I'm not a daily user.
See also bug 202228.
(In reply to Dani Megert from comment #10) > See also bug 202228. Bug 355949 that is.
(In reply to Andrea Guarinoni from comment #8) > - Allowing the user to tweak the GUI as he/she likes in Preferences > > Genaral > Appearence by adding an option to remove some optional GUI > controls that can be useless for the user and waste space, like the > #org-eclipse-ui-main-toolbar You can currently hide the main toolbar using Window>Hide Toolbar PW
(In reply to Paul Webster from comment #12) > (In reply to Andrea Guarinoni from comment #8) > > - Allowing the user to tweak the GUI as he/she likes in Preferences > > > Genaral > Appearence by adding an option to remove some optional GUI > > controls that can be useless for the user and waste space, like the > > #org-eclipse-ui-main-toolbar > > You can currently hide the main toolbar using Window>Hide Toolbar > > PW That's true! I completely forgot it, thanks for the advice Paul :) So only the bottom toolbar can't be removed at this time...
> So, at this point, we should simply make the Windows 7 Classic theme the > default. For Linux I can't really tell whether the Classic theme would also > be the better default, because I'm not a daily user. I think classic suffers from the MRU setting which lots of people seem also to hate. So I personally would prefer to reduce the whitespace in the new theme, which I think is nicely done with the proposed Gerrit review. I agree that Bug 374027 and Bug 325937 should also be fixed, current theme does not handle that well.
(In reply to Lars Vogel from comment #14) > > So, at this point, we should simply make the Windows 7 Classic theme the > > default. For Linux I can't really tell whether the Classic theme would also > > be the better default, because I'm not a daily user. > > I think classic suffers from the MRU setting which lots of people seem also > to hate. The classic theme is the same as the current default. If you mean to also enable MRU again, then that can easily be added ;-).
(In reply to Dani Megert from comment #15) > The classic theme is the same as the current default. ... in respect to MRU
> The classic theme is the same as the current default. If you mean to also > enable MRU again, then that can easily be added ;-). Look to me that MRU is only enabled on Windows for certain stylesheets e4_classic_win7.css e4_classic_winxp.css e4_default_mru_on_win7.css The other windows stylesheets have it disabled: e4_default_win7.css e4_default_winxp_blu.css e4_default_winxp_olv.css Linux and Mac seem to have it always disable.
(In reply to Dani Megert from comment #15) > The classic theme is the same as the current default. If you mean to also > enable MRU again, then that can easily be added ;-). O nooo. ;-)
(In reply to John Arthorne from comment #6) > I have been thinking of the idea of creating a new theme where we can try > out different ideas and then collect community feedback and use that to > decide what becomes the default for the next release (and maybe hide/remove > the old theme if there is wide agreement new one is better). I like this idea. We could even keep working on this in the current Eclipse4 theme and if it differs greatly from the current theme, as we approach Luna we can create the new default theme and provide the current theme for those that like it. PW
(In reply to Paul Webster from comment #19) > (In reply to John Arthorne from comment #6) > > I have been thinking of the idea of creating a new theme where we can try > > out different ideas and then collect community feedback and use that to > > decide what becomes the default for the next release (and maybe hide/remove > > the old theme if there is wide agreement new one is better). > > I like this idea. We could even keep working on this in the current > Eclipse4 theme and if it differs greatly from the current theme, as we > approach Luna we can create the new default theme and provide the current > theme for those that like it. +1 from me. Can we create this new theme in a new plug-in in eclipse.platform.ui? I plan also to contribute a "as good as possible with SWT limitations" dark theme in a separate plug-in. I think having the CSS styles in separate plug-ins make consumption via RCP applications easier. I also contacted the creator the chrome theme, if he would be will to contribute this theme to Eclipse.org https://github.com/jeeeyul/eclipse-themes/issues/99
(In reply to Lars Vogel from comment #20) > I also contacted the creator the chrome theme, if he would be will to > contribute this theme to Eclipse.org > https://github.com/jeeeyul/eclipse-themes/issues/99 +1 His plugin is great step in the right direction. The only way to somehow use Eclipse 4.x for me is by using his themes, especially because they allow to customize spacing, colors and MRU behavior. If he will dislike the idea or for any other reason preventing integration of his work into Eclipse, for all the new themes please allow to customize MRU. It is pity to have a nice looking but actually unusable (because of fixed MRU setting) themes.
> It is pity to have a nice looking but actually unusable (because of fixed > MRU setting) themes. I think you are obsessed with MRU. ;-) I always forget what this is, but IIRC you don't want it enabled, which is the case in all "new" themes, so you should be fine.
(In reply to Andrey Loskutov from comment #21) > The only way to somehow use Eclipse 4.x for me is by using his themes, > especially because they allow to customize spacing, colors and MRU behavior. Who on this bug is actually *happily* using the original 'Windows 7' theme (without any personal CSS modification)? For me it is unusable due to bug 378672, bug 325937 and this bug here.
(In reply to Dani Megert from comment #23) > Who on this bug is actually *happily* using the original 'Windows 7' theme > (without any personal CSS modification)? For me it is unusable due to bug > 378672, bug 325937 and this bug here. I am using the original Windows 7 theme without modification. I am not arguing that one is better than the other though. If anything I would reduce wasted whitespace inside the part (between part border and scrollbars, etc). Since the active stack title bar color is strong blue I never found the active part to be confusing. I am fine with switching to the Classic theme as well.
(In reply to John Arthorne from comment #24) > (In reply to Dani Megert from comment #23) > > Who on this bug is actually *happily* using the original 'Windows 7' theme > > (without any personal CSS modification)? For me it is unusable due to bug > > 378672, bug 325937 and this bug here. > > I am fine with switching to the Classic theme as well. OK, I suggest we move forward with this so that we have a usable/nice default again on Windows 7 (I won't speak for Linux here). I'm OK to keep the MRU off if that makes more people happy. Does it??? I also looked at the Chrome Theme. Out of the box it has the same reported issues (too much whitespace, all tabs are white, etc.), BUT: it offers a GUI which allows to change all of this, including the MRU behavior. I think the right solution would be to incorporate that (or a similar) preference UI, so that it can be used for any theme that's currently selected - but that's different bug.
> OK, I suggest we move forward with this so that we have a usable/nice > default again on Windows 7 (I won't speak for Linux here). I'm OK to keep > the MRU off if that makes more people happy. Does it??? Is this a new topic or do you also want to have less whitespace in the windows theme? > I also looked at the Chrome Theme. Out of the box it has the same reported > issues (too much whitespace, all tabs are white, etc.), BUT: it offers a GUI > which allows to change all of this, including the MRU behavior. I think the > right solution would be to incorporate that (or a similar) preference UI, so > that it can be used for any theme that's currently selected - but that's > different bug. This customization is really nice. Please open a new bug report for this feature.
(In reply to Lars Vogel from comment #26) > > OK, I suggest we move forward with this so that we have a usable/nice > > default again on Windows 7 (I won't speak for Linux here). I'm OK to keep > > the MRU off if that makes more people happy. Does it??? > > Is this a new topic or do you also want to have less whitespace in the > windows theme? Getting rid of whitespace is a concern on all platforms (at least for me), but since I mainly work on Windows 7 and not Linux, I can't really tell whether the 'Classic' theme on Linux would also be better appreciated by users as default, than the current default (GTK). Bug 385676 indicates that we should switch back to 'Classic'.
Created attachment 237480 [details] "MRU" on linux 4.3 "classic" theme (In reply to Dani Megert from comment #27) > (In reply to Lars Vogel from comment #26) > > > OK, I suggest we move forward with this so that we have a usable/nice > > > default again on Windows 7 (I won't speak for Linux here). I'm OK to keep > > > the MRU off if that makes more people happy. Does it??? For sure, but see below :) > but since I mainly work on Windows 7 and not Linux, I can't really tell > whether the 'Classic' theme on Linux would also be better appreciated by > users as default, than the current default (GTK). Bug 385676 indicates that > we should switch back to 'Classic'. "Classic" is *much* better as "GTK" or "Default" on Linux, or let say it differently, other two are simply huge UI design disaster. Regarding MRU "disabled" in Classic Linux theme: it is still available (I don't know if this is a bug or feature, because you told it is disabled in Classic), see attached screen shot. The behavior from the original bug 68684 comment 10 is still same on "Linux Classic" in 4.3. Anyway, it looks like taking "Classic" as a new "default" theme is a good step for fixing this issue on Linux/Windows (no idea about Mac), but I would at least make sure that MRU is configurable.
I'm for reducing the whitespace usage (especially between the stacks) for this bug. I'm not for switching the default back to the 3.x. AFAIK you switch the default on all platforms (one default theme, and the platform specific CSS is picked up). PW
(In reply to Paul Webster from comment #29) > I'm for reducing the whitespace usage (especially between the stacks) for this > bug. I'm not for switching the default back to the 3.x. There's not just the whitespace that's currently wrong. There are many issues that users complain about (not just via bugs but also at EclipseCon Europe - I heard) and fixing those takes time. As you can see from Andrey's comment and bug 385676 they also suggest to switch on Linux. So, I'm really inclined to make that change and let people work on the themes until are ready for prime time. > AFAIK you > switch the default on all platforms (one default theme, and the platform > specific CSS is picked up). The 'Default Theme' has already been remove since it was unusable (see bug 371785).
(In reply to Dani Megert from comment #30) > > There's not just the whitespace that's currently wrong. There are many > issues that users complain about (not just via bugs but also at EclipseCon > Europe - I heard) and fixing those takes time. As you can see from Andrey's > comment and bug 385676 they also suggest to switch on Linux. So, I'm really > inclined to make that change and let people work on the themes until are > ready for prime time. Some users that don't like the new colour scheme and wasted space (which this bug is to address) are suggesting we switch it back. But unless you want to add a question to the IDE group of questions we both know that kind of feedback isn't representative of what users want, just what some users want. Given that this isn't up for one of those IDE questions and that whatever isn't the default shipped with eclipse is effectively unreviewed (no one is working on the Classic theme now because most users don't use it) then I'm not willing to abandon our current theme for the old theme. > > AFAIK you > > switch the default on all platforms (one default theme, and the platform > > specific CSS is picked up). Oh, I don't mean that default but the one that will be chosen by the SDK. I believe we get to pick one (specified in the product) and the CSS engine picks the platform specific implementation of it if it's available. PW
(In reply to Paul Webster from comment #31) > Some users that don't like the new colour scheme and wasted space (which > this bug is to address) are suggesting we switch it back. But unless you > want to add a question to the IDE group of questions we both know that kind > of feedback isn't representative of what users want, just what some users > want. I don't think that only *some* users are unhappy with 4.x UX. It's a common sense that 4.x UX is (ways) behind 3.x. > Given that this isn't up for one of those IDE questions and that whatever > isn't the default shipped with eclipse is effectively unreviewed (no one is > working on the Classic theme now because most users don't use it) then I'm > not willing to abandon our current theme for the old theme. Even if the new theme fixes multiple reported problems? Sounds really strange. > "Unreviewed" I don't think so. "Classic" works fine for me and others on Win/Linux boxes, so I can't understand your fear. The most often tip on internet how to fix "4.x" Eclipse is to switch to the "Classic" theme. *Any* change might introduce regressions, so what, should we stop to change? At least we are not talking about switching just before release, we are in M4. And BTW who reviewed 4.x default theme at all? On any measure you might have - user experience, usability, UI design etc the 4.x "Default" theme is a huge step back from the "unreviewed" Classic theme. What we should clearly separate here is: technology-wise *all* 4.x themes are on same level, so the risk is low to break something by changing the theme. From the other point of view - the 4.x "Classic" theme inherits most of the UX design decisions from 3.x, which was fine for Eclipse almost 10 years. This was effectively reviewed by millions of developers year by year. 4.x "Default" theme UI design principles however were never publicly reviewed in the same manner. You can't deny that lot of people started to complain on 4.x UX since it's introduction. This *is* the actual review and this review is unfortunately *failed*. So why not take well designed, tested and accepted UI concept (4.x "Classic") and make Eclipse end users happy again? P.S: If one really want fix 4.x "Default" theme, one must provide *better* UX than with the "Classic", which is not just fixing few aspects of it here and there. UI design for IDE is more than few CSS rule fixes, it requires careful conceptual work and understanding of the use cases, it requires testing and *iterative* work on users feedback. None of that happened with 4.x "Default" theme (or at least not in public), and I do not see it happen for 4.4 without spending lot of time and effort.
Can we move the general discussion to Bug 421657? This bug is about white space reduction in the default themes. I changed the title to make this clearer.
(In reply to Andrey Loskutov from comment #32) > > I don't think that only *some* users are unhappy with 4.x UX. It's a common > sense that 4.x UX is (ways) behind 3.x. The plural of anecdotes is not data. That's my point. > I don't think so. "Classic" works fine for me and others on Win/Linux boxes, You can continue to use it. That's not what we're working on going forwards. > And BTW who reviewed 4.x default theme at all? On any measure you might have > - user experience, usability, UI design etc the 4.x "Default" theme is a > huge step back from the "unreviewed" Classic theme. You've repeated this fallacy over and over again, that doesn't make it true. That theme was created with a UX designer and someone that invests time in UX. You don't like it (that's your opinion). "Who reviewed it at all...?" Of course it was reviewed when it was created (that's a fact). If you want to be taken seriously, you better get your facts straight. > So why not take well designed, tested and accepted UI concept (4.x > "Classic") and make Eclipse end users happy again? It's not well designed. It was created the same way this was, and was complained about the same way (it was dubbed the pink shag toilet seat cover of desktop applications). So personal preference isn't good enough here. I would be willing to accept the work of a UX designer that worked on the 4.x theme with us, to improve it. Or you can help improve the 4.x theme. Or you can switch back to Classic if you want. PW
(In reply to Paul Webster from comment #34) There are many bugs with hard facts about where the E4 theme objectively lacks quality: Bug 378672, bug 320901, bug 340889, bug 355949, and to some part bug 388476, bug 393454. As long as nobody even tries to justify any of those wrong decisions, we can fairly assume that the E4 design didn't get a professional review. > You've repeated this fallacy over and over again, that doesn't make it true. Same to you. Please address the bugs I listed or justify the decisions. An unknown UX designer who anecdotally should have reviewed this has no credibility whatsoever. Let's talk about facts, not job titles.
(In reply to Markus Keller from comment #35) > (In reply to Paul Webster from comment #34) > There are many bugs with hard facts about where the E4 theme objectively > lacks quality: Bug 378672, bug 320901, bug 340889, bug 355949, and to some > part bug 388476, bug 393454. Some of these bugs are personal preference, so perhaps you should look up what objectively means. Bug 378672 - don't care, that seems to be preference related. bug 320901 - to be fixed bug 340889 - is being fixed bug 355949 - already has a patch. bug 388476 - MRU, don't care bug 393454 - scheduled to be fixed. > > As long as nobody even tries to justify any of those wrong decisions, we can > fairly assume that the E4 design didn't get a professional review. You need to understand the difference between "I don't like" and "this is wrong" You don't like colours, but the java content assist not returning anything is wrong. The bugs that are marked to be fixed are bugs, not features. And I'll get you the contact information for the people involved, you can go talk to them. And off you go back to Bug 293481 where they did work on the style part (the colors, etc). PW
We all need to take a deep breath here. UI design is inherently subjective and there are very few objective facts either way. There seems to be pretty wide agreement on the whitespace so why don't we move forward with that one as a start. Lars would you mind posting a before and after screenshot showing what your patch does and we'll see if we can agree on it.
To add a different POV. I would really like if Eclipse does not define its own themes but rely on the system ones. This would make it really fit into user machines and one wouldn't have to play with setting the Eclipse theme as long as he/she has choosen his system one. This would not be liked by many(most?) but I write it here for the sake of having all opinions and pointing that these are relly personal preferences.
I'm just thinking about the issue with supporting the CSS stylesheets for different platforms by single person that uses the specific OS only. Quite often fixing something that requires the CSS change, it is impossible to verify it correctly for all platforms (lack of physical assets or the particular OS experience) and the change can work improperly. Maybe we could introduce some process extension where fixing something in CSS we are responsible for our OS and for opening proper porting bugs for other platforms (and keeping track on it). The bugs would be ported by the specific platform users. I believe it can improve the quality of the CSS stylesheets. Daniel
*** Bug 355949 has been marked as a duplicate of this bug. ***
Created attachment 237703 [details] Lots of whitespace - Current
Created attachment 237704 [details] With Minimal Whitespace
(In reply to John Arthorne from comment #37) > Lars would you mind posting a before and after screenshot > showing what your patch does and we'll see if we can agree on it. Sure, done. Fix available in https://git.eclipse.org/r/17743
(In reply to Lars Vogel from comment #43) > > Fix available in https://git.eclipse.org/r/17743 I'm fine with this fix. PW
> > Fix available in https://git.eclipse.org/r/17743 > > I'm fine with this fix. > > PW Cool. Unfortunately I can't push it, as I have no commit rights for the platform repo.
(In reply to Lars Vogel from comment #45) > > > Fix available in https://git.eclipse.org/r/17743 > > Cool. Unfortunately I can't push it, as I have no commit rights for the > platform repo. I'd like to hear back from Dani, Markus, or John first though. PW
Created attachment 237861 [details] Screenshot of r/17743 I agree with the direction, but https://git.eclipse.org/r/17743 currently creates more problems than it solves: - screen cheese in the tab bar (white line on the bottom, see red arrows) - places where we have 3 adjacent 1px lines (orange arrows) -> visual noise; looks like views are glued to the outer border If the cheese can be fixed, then we can go with the proposed changes in .MPartStack*, but set all four .MTrimmedWindow.topLevel margins to 3xp. Reducing more gaps would require us to get rid of some border lines, but that can only be done as part of a larger design change and not as a point fix (e.g. the whole "active part" concept, see bug 378672 & bug 355949 comment 0 etc.)
(In reply to Markus Keller from comment #47) > - screen cheese in the tab bar (white line on the bottom, see red arrows) That looks similar to bug 420951, see screenshot there. Did your eclipse.platform.ui include that fix when you took the screenshot? It's a bit unfortunate for this kind of work that the theme is in a different repository.
(In reply to Robin Stocker from comment #48) > That looks similar to bug 420951, see screenshot there. This fix should have been in Tuesday's I build (it was released Monday) PW
> That looks similar to bug 420951, see screenshot there. Did your > eclipse.platform.ui include that fix when you took the screenshot? Yes, I have that repo in my workspace and it includes that fix. Changing the magic number to 3 fixes the cheese (but I also don't have a clue whether that's generally correct). I'm on Windows 7. My UI font in the OS is Tahoma 8, if that matters (but the problem stays if I fix the hardcoded Segoe UI 9 in e4_default_win7.css).
(In reply to Markus Keller from comment #50) > > That looks similar to bug 420951, see screenshot there. Did your > > eclipse.platform.ui include that fix when you took the screenshot? > > Yes, I have that repo in my workspace and it includes that fix. In that case it's different on Windows. > Changing the > magic number to 3 fixes the cheese (but I also don't have a clue whether > that's generally correct). Neither do I. It would be good if one of the original authors could have a look at it.
> If the cheese can be fixed, then we can go with the proposed changes in > .MPartStack*, but set all four .MTrimmedWindow.topLevel margins to 3xp. 3px look still much better on Linux. I updated the Gerrit review. https://git.eclipse.org/r/#/c/17743/
Created attachment 237911 [details] With reduced Whitespace
(In reply to Lars Vogel from comment #53) > Created attachment 237911 [details] > With reduced Whitespace Markus and Paul, could you give it a try? Would be nice to have an improved UI representation in M4.
> Markus and Paul, could you give it a try? Would be nice to have an improved > UI representation in M4. I don't need to review the change I proposed in comment 47, since I've already tested that. What's missing is an explanation for why there's platform-dependent cheese, and a fix that works by design, not by trial-and-error.
(In reply to Markus Keller from comment #55) > > Markus and Paul, could you give it a try? Would be nice to have an improved > > UI representation in M4. > > I don't need to review the change I proposed in comment 47, since I've > already tested that. What's missing is an explanation for why there's > platform-dependent cheese, and a fix that works by design, not by > trial-and-error. On Linux we don't see the cheese, so it is hard to find out on our side. I don't have access to a Window machine anymore. and I assume you don't have the time to look at it in detail. IMHO a fix which works and improves the Eclipse SDK appearance is better than a potential perfect solution based on an investigation which properly will not happen. Btw: I love to be proven wrong on the "investigation will not happen" statement.
(In reply to Markus Keller from comment #47) > Created attachment 237861 [details] > Screenshot of r/17743 > > I agree with the direction, but https://git.eclipse.org/r/17743 currently > creates more problems than it solves: > - screen cheese in the tab bar (white line on the bottom, see red arrows) > - places where we have 3 adjacent 1px lines (orange arrows) > -> visual noise; looks like views are glued to the outer border Daniel, can you please look at Lars patch set #7 and the implementation of CTabFolder and try to find out what's creating the cheese that Markus found? Other than that, I like making the top 3 pixels. PW
(In reply to Paul Webster from comment #57) > (In reply to Markus Keller from comment #47) > > Created attachment 237861 [details] > > Screenshot of r/17743 > > > > I agree with the direction, but https://git.eclipse.org/r/17743 currently > > creates more problems than it solves: > > - screen cheese in the tab bar (white line on the bottom, see red arrows) > > - places where we have 3 adjacent 1px lines (orange arrows) > > -> visual noise; looks like views are glued to the outer border > > > Daniel, can you please look at Lars patch set #7 and the implementation of > CTabFolder and try to find out what's creating the cheese that Markus found? > > Other than that, I like making the top 3 pixels. > > PW The 'cheese' is caused by the 'swt-shadow-visible' property of the MPartStack element that has been disabled in the patch. When it is false the CTabRendering class adds 1 pixel instead of 3 to the header's height and it produces the gap (CTabRendering.drawTabHeader, line 243). The minimum height value of the tab's header is the toolbar height. We can try to modify the background images for toolbars to fix the gap or revert the previous value of the property. Daniel
(In reply to Daniel Rolka from comment #58) Can you explain why the cheese is only visible on Windows, but not on GTK (e.g. comment 53)? Note that the fix for bug 420951 recently changed the value from 0 to 1.
(In reply to Markus Keller from comment #59) > (In reply to Daniel Rolka from comment #58) > Can you explain why the cheese is only visible on Windows, but not on GTK > (e.g. comment 53)? Note that the fix for bug 420951 recently changed the > value from 0 to 1. I don't know, maybe toolbars are rendered differently on Linux and Windows. Maybe with original padding/margin values it was hidden. Daniel
(In reply to Markus Keller from comment #55) > > Markus and Paul, could you give it a try? Would be nice to have an improved > > UI representation in M4. > > I don't need to review the change I proposed in comment 47, since I've > already tested that. What's missing is an explanation for why there's > platform-dependent cheese, and a fix that works by design, not by > trial-and-error. Markus: Dani reports in the Gerrit review that the suggested change still generates cheese with his Windows installation. Can you please verify, if the change really works for you?
Created attachment 238289 [details] Another gap issue (In reply to Daniel Rolka from comment #60) > I don't know, maybe toolbars are rendered differently on Linux and Windows. > Maybe with original padding/margin values it was hidden. > > Daniel The 'cheese' seems to be caused by some gradient support issue. After changing the style: .MPartStack.active { swt-unselected-tabs-color: #F3F9FF #D0DFEE #CEDDED #CEDDED #D2E1F0 #D2E1F0 #FFFFFF 20% 45% 60% 70% 100% 100%; } into: .MPartStack.active { swt-unselected-tabs-color: #F3F9FF; } I got another issue (or the same but rendered in the different way), see the 'Another gap issue' attachment. I will continue my investigation, Daniel
(In reply to Lars Vogel from comment #61) > Markus: Dani reports in the Gerrit review that the suggested change still > generates cheese with his Windows installation. Can you please verify, if > the change really works for you? I never said the proposed change works for me. In comment 50, I said that I had the fix for bug 420951 in my workspace, and that "Changing the magic number to 3 fixes the cheese". The magic number is the one that was changed from 0 to 1 in that fix: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a670ec8283925660f1842660b166f345fc1ba349 Someone needs to dig into the CTabRendering code to understand how it works and to replace the magic numbers with something that makes sense. Just setting that number to 3 is not a solution, since this may cause issues on other platforms.
Independent of the white space issue, is there anything one can do to hide these accursed horizontal scrollbars? I mean, in what reality does it makes sense to always show horizontal scrollbars even when text does _not_ extend beyond viewing area? The issue is magnified when splitting coding area up into multiple tabs (e.g. a quadrant layout). The ever present horizontal scrollbars waste valuable coding real estate, not to mention look hideous. Please expose, preferably via CSS, a means to hide scrollbars. The rest is done, can hide status bar, toolbar, everything but the scrollbars. With that in place the UI is perfect AFAIC.
Not everything, you can't hide the menu bar (to only show after Alt or F10 is pressed).
(In reply to Timo Kinnunen from comment #65) > Not everything, you can't hide the menu bar (to only show after Alt or F10 > is pressed). Well now you're getting into Nirvana territory, the ability to show/hide the main menu bar, would be thrilled to see that functionality. re: pointless horizontal scrollbars even in empty files, apparently OSX is not affected. Here on Linux very much affected. Not sure what the deal is, but they serve no purpose other than to waste space. CSS Spy shows that scrollbar widgets are not exposed. There's also a 12px column just to the right of vertical scrollbar that is non-editable via pure CSS; would love to get rid of that, losing 24px of screen real estate for no reason. Almost there: with show/hide main menu + horizontal scrollbar default hidden + 12px column to right of vertical scrollbar hidden we have near pure coding space to work with, not unlike VIM or other lean and mean text editor where code reigns (as it should).
(In reply to James Lang from comment #66) > re: pointless horizontal scrollbars even in empty files, apparently OSX is > not affected. Here on Linux very much affected. Not sure what the deal is, > but they serve no purpose other than to waste space. See bug 424501 for that, which has a working patch and is waiting for a reaction from the Platform Text developers.
(In reply to Robin Stocker from comment #67) > (In reply to James Lang from comment #66) > > re: pointless horizontal scrollbars even in empty files, apparently OSX is > > not affected. Here on Linux very much affected. Not sure what the deal is, > > but they serve no purpose other than to waste space. > > See bug 424501 for that, which has a working patch and is waiting for a > reaction from the Platform Text developers. Awesome, looks like Lars just chimed in today re: getting your patch in place for bug 424501. Of course I voted for it, scrollbars on demand would be a godsend for the eyes ;-)
(In reply to Daniel Rolka from comment #62) > Created attachment 238289 [details] > Another gap issue > > (In reply to Daniel Rolka from comment #60) > > I don't know, maybe toolbars are rendered differently on Linux and Windows. > > Maybe with original padding/margin values it was hidden. > > > > Daniel > During further investigation I've found that the 'cheese' is caused by wrong drawing of the CTabFolderRenderer.PART_BACKGROUND tab's item (the drawing bounds are calculated improperly). I've created the fix proposal for the issue: https://git.eclipse.org/r/#/c/20389/ The patch uses the 'magic' values and we can not simply eliminate it (the CTabRendering and CTabFolderRenderer classes operate in this way). thanks, Daniel
(In reply to Daniel Rolka from comment #69) > During further investigation I've found that the 'cheese' is caused by wrong > drawing of the CTabFolderRenderer.PART_BACKGROUND tab's item (the drawing > bounds are calculated improperly). I've created the fix proposal for the > issue: https://git.eclipse.org/r/#/c/20389/ > > The patch uses the 'magic' values and we can not simply eliminate it (the > CTabRendering and CTabFolderRenderer classes operate in this way). Submitted with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=77108408a6915617564b031709f0596fa7c75394 And submitted the CSS changes with http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=3dac7f9625fc21cf30d0510044c6b8936fbcfcba
(In reply to Dani Megert from comment #70) > (In reply to Daniel Rolka from comment #69) > > During further investigation I've found that the 'cheese' is caused by wrong > > drawing of the CTabFolderRenderer.PART_BACKGROUND tab's item (the drawing > > bounds are calculated improperly). I've created the fix proposal for the > > issue: https://git.eclipse.org/r/#/c/20389/ > > > > The patch uses the 'magic' values and we can not simply eliminate it (the > > CTabRendering and CTabFolderRenderer classes operate in this way). > > Submitted with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=77108408a6915617564b031709f0596fa7c75394 > > And submitted the CSS changes with > http://git.eclipse.org/c/platform/eclipse.platform.git/commit/ > ?id=3dac7f9625fc21cf30d0510044c6b8936fbcfcba Thanks Daniel and Dani!
Verified in N20140115-2000.
