Community
Participate
Working Groups
Created attachment 262993 [details] Screenshot We should enable Eclipse to use selection colors on the top similar to the popular UI paradigma in the mobile and web world. Screenshot attached.
Simon, are you interested in implementing something like this?
New Gerrit change created: https://git.eclipse.org/r/83168
Created attachment 264839 [details] selected-tab-highlight-color for the dark theme
Created attachment 264840 [details] selected-tab-highlight-color default theme
(In reply to Simon Scholz from comment #4) > Created attachment 264840 [details] > selected-tab-highlight-color default theme Looks very cool.
To me this looks too intrusive and is a non-standard UI to mark an active tab. Also, it uses a color which does not integrate well with the other colors in the theme (both, default and dark). I would not add this.
Forwarded from mailing-list: """ I'm 0 for that change, which means that I don't find it that necessary from my user POV (Linux, GTK3, Fedora 24, light theme) because active part stack and tab on GTK is already properly enough highlighted and if we want to improve it I would rather go for just tweaking the gray-scale background colors rather than introducing a new concept and color. That said, I don't think this is a bad change and it seems to be necessary for a comfortable usage of the dark theme. Also, can you please share screenshots of how it looks on Windows? To me, the active part stack issue is currently the most annoying on Windows and given that it represents more than 70% of Eclipse IDE user-base IIRC, that's probably the one we need to focus on when making such choice. """ Also, I'm windering whether this isn't a dup of bug 325937
(In reply to Mickael Istria from comment #7) > Also, I'm windering whether this isn't a dup of bug 325937 +1!
+0.5 as: +1 I like the idea (very much), including how it looks on default/dark themes -0.5 It is non-standard UI, the risk is adopters don't understand. I checked solutions proposed in bug 325937 (which I think is related). >> I think we could modify a little bit Simon's solution, and highlight the full tab header by adding a "#blue" color using transparency 50%, where I expect: - in light themes - getBackgroundColor() returns ~ #white - #white + #blue_trasp50% = light-blue, good to highlight tabs in light themes - in dark themes: - getBackgroundColor() returns ~ #white - #black + #blue_trasp50% = dark-blue, good to highlight tabs in dark themes
(In reply to Dani Megert from comment #8) > (In reply to Mickael Istria from comment #7) > > Also, I'm windering whether this isn't a dup of bug 325937 > > +1! +1 *** This bug has been marked as a duplicate of bug 325937 ***
Created attachment 282489 [details] Modern Dark Theme red tab highlight As requested, here's a picture of how this change looks with my Modern Dark theme (which is still in an early state).
Created attachment 282490 [details] Modern Dark Theme yellow tab highlight And here's the highlight being set to yellow, to make it a bit more obvious of what change is made.
The yellow highlight looks odd IMHO, the red one looks nice. Any reason why the Variables tab on the right seems unaffected?
Not a dup, related to bug 325937 but not the same
New Gerrit change created: https://git.eclipse.org/r/161627
(In reply to Pierre-Yves B. from comment #13) > The yellow highlight looks odd IMHO, the red one looks nice. Any reason why > the Variables tab on the right seems unaffected? The variables tab seemed unaffected because the color of the highlight is the same as the color of the tab :P The yellow one does look odd, but it proves that all tabs get the higlight applied :)
Created attachment 282612 [details] Active Tab Top Highlight with Square Corners Here's how the latest patch looks like when the highlight is set to the top of the tab, with square tabs. I hope this gets merged, as it looks really nice imo :)
Okay, so I've tweaked the patch for this bug and checked out how it looks in both light and dark theme, with both rounded and square tabs. I'll post screenshots of how it looks in the default themes on Linux. Note that, the new patch does *not* change the light/dark CSS. It simply gives a new CSS option for those who want to use it. Whether we want to use it in the Platform themes is for a followup bug (assuming the new patch gets merged).
Created attachment 282842 [details] active tab bottom highlight dark square corners
Created attachment 282843 [details] active tab bottom highlight light square corners
Created attachment 282846 [details] active tab top highlight light square corners
Created attachment 282847 [details] active tab top highlight dark square corners
Created attachment 282848 [details] active tab bottom highlight dark round corners issue Note that, there's a off-by-1px issue with the dark theme. Because the dark theme has no visible outline, the border radius (used by this patch) is off by 1px. This issue does not exist when switching to the light theme, which has a visible outline.
Created attachment 282849 [details] active tab bottom highlight light round corners no issue Notice the off-by-1px issue is not present when using the light theme with rounded corners.
Hey Andrew, I think you should be able to reduce the width by one and it will look good on light and dark. The highlight should stop before the tab outline. Is say right now it looks wrong on light and dark.
Based on this bug, i tried to add access to system accent color: bug 563282 see related attachment: https://bugs.eclipse.org/bugs/attachment.cgi?id=282907
(In reply to Philippe Dul from comment #26) > Based on this bug, i tried to add access to system accent color: bug 563282 > > see related attachment: > https://bugs.eclipse.org/bugs/attachment.cgi?id=282907 Awesome, thanks!
(In reply to Lars Vogel from comment #27) > (In reply to Philippe Dul from comment #26) > > Based on this bug, i tried to add access to system accent color: bug 563282 > > > > see related attachment: > > https://bugs.eclipse.org/bugs/attachment.cgi?id=282907 > > Awesome, thanks! Lars, Andrew's patch (https://git.eclipse.org/r/c/161627/) is still in flight (and so close to get merged!), I don't think this should be marked as RESOLVED FIXED :)
(In reply to Pierre-Yves B. from comment #28) Unintentially closed the bug, sorry for the noise.
(In reply to Mike Marchand from comment #25) > Hey Andrew, I think you should be able to reduce the width by one and it > will look good on light and dark. The highlight should stop before the tab > outline. Is say right now it looks wrong on light and dark. Hey Mike, I tried reducing the width by 1 pixel and although it fixes the issue when using round tabs, it looks kind of aesthetically unpleasing on both the light and dark themes with square tabs. I'll attach some photos. Do you know if the dark theme lacks a border? (Trying to find the root cause of why the light theme looks different than the dark theme with round corners.) As a workaround, I could try using different gc.draw parameters if the corner radius is below or above 6px. I don't think this should be the permanent fix however as it'd just be a workaround.
Created attachment 282914 [details] light theme 1px less, square corners Note the highlight ends 1px too early (on the right side)
Created attachment 282915 [details] dark theme 1 px less width, square corners Note, the highlight still ends 1px too early (although it's harder to notice)
Created attachment 282916 [details] light theme 1px less, round corners This looks good imo
Created attachment 282917 [details] dark theme 1 px less, round corners This looks good IMO.
It's possible that the selected square tabs are off by +1 in their width, and that's why you need the special case for square/round tabs.
Andrew, I also wanted to mention that the dark theme does have an outline, it is just harder to see, if you zoom in you should be able to see it. On dark theme you really want to avoid high contrast outlines since they draw too much attention to something that should just exist without drawing attention.
(In reply to Mike Marchand from comment #35) > It's possible that the selected square tabs are off by +1 in their width, > and that's why you need the special case for square/round tabs. Actually... having taken a look at the code, it looks like the round tabs may be off by -1 in their width. I think for now it should suffice to adjust based on cornerSize == SQUARE_CORNE, else.
Created attachment 282918 [details] Square tab highlight - bottom tabs When we have swt-selected-highlight-top: false; We are drawing SWT.BOTTOM selected tab highlight at the bottom, we need to consider the bottom case as well. Round tabs are even more affected by this since it's not only in the wrong spot, but it also looks wrong.
Created attachment 282919 [details] Square tab highlight - bottom tabs
(In reply to Mike Marchand from comment #39) > Created attachment 282919 [details] > Square tab highlight - bottom tabs This is actually round tabs
Created attachment 282946 [details] Wrong adjustment on package explorer Things look great on all square tab configurations from what I've tested! However, with round tabs, the width adjustment is not always necessary. See in the Package Explorer in the attached screenshot. Unless Mike or someone has an obvious solution in mind, maybe we could merge as is for 4.16 and refine later? I'm expecting the main use case to be square tabs anyway, putting a rectangular highlight on a round tab will probably not be common.
(In reply to Pierre-Yves B. from comment #41) > Created attachment 282946 [details] > Wrong adjustment on package explorer > > Things look great on all square tab configurations from what I've tested! > > However, with round tabs, the width adjustment is not always necessary. See > in the Package Explorer in the attached screenshot. > > Unless Mike or someone has an obvious solution in mind, maybe we could merge > as is for 4.16 and refine later? I'm expecting the main use case to be > square tabs anyway, putting a rectangular highlight on a round tab will > probably not be common. Have you tried bottom tabs?
(In reply to Mike Marchand from comment #42) > Have you tried bottom tabs? Yes, I checked on the light theme on Windows with a CTabFolder[style~='SWT.DOWN'][style~='SWT.BOTTOM'] CSS selector.
> However, with round tabs, the width adjustment is not always necessary. See > in the Package Explorer in the attached screenshot. > > Unless Mike or someone has an obvious solution in mind, maybe we could merge > as is for 4.16 and refine later? I'm expecting the main use case to be > square tabs anyway, putting a rectangular highlight on a round tab will > probably not be common. +1 for merging and improving afterwards. I think the core issue is the width for round tabs is off by 1, and fixing that is ouside of the scope for this patch. Once the round tabs width issue is fixed, I'll gladly update the highlight drawing code. However if someone as a better solution, I'm open to it.
This (In reply to Andrew Obuchowicz from comment #44) > > However, with round tabs, the width adjustment is not always necessary. See > > in the Package Explorer in the attached screenshot. > > > > Unless Mike or someone has an obvious solution in mind, maybe we could merge > > as is for 4.16 and refine later? I'm expecting the main use case to be > > square tabs anyway, putting a rectangular highlight on a round tab will > > probably not be common. > > +1 for merging and improving afterwards. I think the core issue is the width > for round tabs is off by 1, and fixing that is ouside of the scope for this > patch. > > Once the round tabs width issue is fixed, I'll gladly update the highlight > drawing code. Sounds good. Is there an issue for round tab width? This is probably borderline for 4.16 time-wise, however I think it should be squeezed into M3 or RC1: * it only touches internal classes and CSS processing. * there is no visible impact to users, i.e. this is to support new CSS properties, but does not enable them in any of the themes shipped with the Platform. * the risk of regressions is low. The new logic is properly guarded by checks on the existence of said CSS properties. * theme creators (Andrew, possibly myself) will be able to use these in their custom themes, which will roadtest the implementation and allow to start a conversation on whether we want to enable these in the built-in themes or not.
Moving to 4.16 RC1
> Sounds good. Is there an issue for round tab width? The calculation of the round tab width seems to be inconsistent, which leads to the issue you showed with the wrong adjustment on the package explorer (but not the editor tabs). > This is probably borderline for 4.16 time-wise, however I think it should be > squeezed into M3 or RC1: > * it only touches internal classes and CSS processing. > * there is no visible impact to users, i.e. this is to support new CSS > properties, but does not enable them in any of the themes shipped with the > Platform. > * the risk of regressions is low. The new logic is properly guarded by > checks on the existence of said CSS properties. > * theme creators (Andrew, possibly myself) will be able to use these in > their custom themes, which will roadtest the implementation and allow to > start a conversation on whether we want to enable these in the built-in > themes or not. +1! I really would like to see this patch in for 4.16 and all the reasons above are good arguments as to why it should get in imo :)
Created attachment 282995 [details] Tab highlights with different settings Top row: square tabs. Bottom round: round tabs with 16px corner. Left column: highlight top true. Right column: highlight top false. Pixel calculation seems correct everywhere as far as I can tell. The bottom left screen looks odd, tab highlights on top with round tabs is not aesthetic in my opinion, but hey, it will be up to users to mix and match the settings they want. :)
Please open bug for using this in the dark theme or the active tab and attach Gerrit to it so that people can easily test.
(In reply to Lars Vogel from comment #49) > Please open bug for using this in the dark theme or the active tab and > attach Gerrit to it so that people can easily test. See bug 563496.
Gerrit change https://git.eclipse.org/r/161627 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0a888cdd6fa58453059e2de30cfc121e419347e3
Thanks Andrew for finishing this. Thanks Simon for the initial contribution. Thanks Piere-Yves and Mike for testing. Looking forward in using this in the next release in the dark theme. Andrew, please add to the N&N.
(In reply to Lars Vogel from comment #52) > Thanks Andrew for finishing this. Thanks Simon for the initial contribution. > Thanks Piere-Yves and Mike for testing. Looking forward in using this in the > next release in the dark theme. Thanks Lars, and also Simon, Pierre-Yves and Mike :D > Andrew, please add to the N&N. For sure, have this on my TODO list for the week.
New Gerrit change created: https://git.eclipse.org/r/163869
Gerrit change https://git.eclipse.org/r/163869 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=5eee911b360f86c8bddabd66db9d50307ab58ed8
New Gerrit change created: https://git.eclipse.org/r/164276
Gerrit change https://git.eclipse.org/r/164276 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=aa826d04b6b7dda81c00af937fb349a4e8b0c1b7
(In reply to Pierre-Yves B. from comment #45) > * theme creators (Andrew, possibly myself) will be able to use these in > their custom themes, which will roadtest the implementation and allow to > start a conversation on whether we want to enable these in the built-in > themes or not. Here we go, both Andrew's and my themes use this new feature, I'm glad we managed to get it merged in 4.16! :) * https://github.com/AObuchow/Eclipse-Spectrum-Theme * https://github.com/PyvesB/eclipse-planet-themes
(In reply to Pierre-Yves B. from comment #58) > (In reply to Pierre-Yves B. from comment #45) > > * theme creators (Andrew, possibly myself) will be able to use these in > > their custom themes, which will roadtest the implementation and allow to > > start a conversation on whether we want to enable these in the built-in > > themes or not. > > Here we go, both Andrew's and my themes use this new feature, I'm glad we > managed to get it merged in 4.16! :) > * https://github.com/AObuchow/Eclipse-Spectrum-Theme > * https://github.com/PyvesB/eclipse-planet-themes Great to hear. It is also live for the dark theme in 4.17 see Bug 563496 and might become standard for the light theme if I get more feedback in Bug 564380 .
