Community
Participate
Working Groups
Created attachment 282789 [details] TrimBar Please see the screenshot, there can be seen a odd border like space in different color in the trim bars.
Pierre-Yves and Philippe, some blue has survived. Can you please have a look?
New Gerrit change created: https://git.eclipse.org/r/162909
Created attachment 282810 [details] Revised trimbars Any better? :)
Looking good.
Looks way better. Do we have these images also in eclipse.platform.ui.images as svg? In this case they also need update
(In reply to Lars Vogel from comment #5) > Looks way better. Do we have these images also in eclipse.platform.ui.images > as svg? In this case they also need update Not sure, I modified the PNGs directly. I've got the Platform UI project checked out using Oomph, but I cannot see any eclipse.platform.ui.images project inside, and searching for resources names *.svg returns nothing. Am I being thick?
(In reply to Pierre-Yves B. from comment #6) > (In reply to Lars Vogel from comment #5) > > Looks way better. Do we have these images also in eclipse.platform.ui.images > > as svg? In this case they also need update > > Not sure, I modified the PNGs directly. I've got the Platform UI project > checked out using Oomph, but I cannot see any eclipse.platform.ui.images > project inside, and searching for resources names *.svg returns nothing. Am > I being thick? Sorry, quotes wrong from memory, see https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.images for the correct clone URI
(In reply to Lars Vogel from comment #7) > Sorry, quotes wrong from memory, see > https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.images > for the correct clone URI Thanks - will have a look. Though some other time, I've done enough Eclipse stuff for tonight, switching off for now. :)
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/162909 why don't we have @2x versions of the PNGs?
(In reply to Lars Vogel from comment #5) > Looks way better. Do we have these images also in eclipse.platform.ui.images > as svg? In this case they also need update I've had a look and don't think we have any SVG versions for these. There's actually no org.eclipse.ui.themes subfolder at all in the eclipse.platform.images project. (In reply to Matthias Becker from comment #9) > (In reply to Eclipse Genie from comment #2) > > New Gerrit change created: https://git.eclipse.org/r/162909 > > why don't we have @2x versions of the PNGs? No clue, I didn't even know that was a thing! Are they used for higher resolutions or something?
(In reply to Pierre-Yves B. from comment #10) > (In reply to Lars Vogel from comment #5) > > Looks way better. Do we have these images also in eclipse.platform.ui.images > > as svg? In this case they also need update > > I've had a look and don't think we have any SVG versions for these. There's > actually no org.eclipse.ui.themes subfolder at all in the > eclipse.platform.images project. > > (In reply to Matthias Becker from comment #9) > > (In reply to Eclipse Genie from comment #2) > > > New Gerrit change created: https://git.eclipse.org/r/162909 > > > > why don't we have @2x versions of the PNGs? > > No clue, I didn't even know that was a thing! Are they used for higher > resolutions or something? Yes. On high resolution displays SWT automatically takes file with the doubles resolution. If this is not available the low resolution version scalled up (which makes them blurry). Can you tell me, where in the code these icons are used?
(In reply to Matthias Becker from comment #11) > Can you tell me, where in the code these icons are used? If you're referring to the images I've modified in the patch, I think they're used by org.eclipse.e4.ui.widgets.ImageBasedFrame.
Pierre-Yves, can you rebase your patch? Matthias, could you help with providing svg and 2x versions of the icons?
(In reply to Lars Vogel from comment #13) > Pierre-Yves, can you rebase your patch? > > Matthias, could you help with providing svg and 2x versions of the icons? I am currently working on it.
(In reply to Lars Vogel from comment #13) > Pierre-Yves, can you rebase your patch? Done.
(In reply to Matthias Becker from comment #14) > I am currently working on it. Thanks. To reproduce the time pressure, I plan to release Pierre-Yves Gerrit and we can use your update to replace the replaced png files later. I hope that is fine.
(In reply to Lars Vogel from comment #16) > (In reply to Matthias Becker from comment #14) > > > I am currently working on it. > > Thanks. To reproduce the time pressure, I plan to release Pierre-Yves > Gerrit and we can use your update to replace the replaced png files later. I > hope that is fine. sure.
New Gerrit change created: https://git.eclipse.org/r/163125
New Gerrit change created: https://git.eclipse.org/r/163127
Created attachment 282879 [details] New icons in macOS light theme This is how the new icons look in macOS light theme. I adapted the dots of the drag handle to be more visible. Only in the macOS light theme they have been very small. Even in the macOS dark theme they have been same as in other themes. So I changed them to unify this
Created attachment 282880 [details] New icons in macOS dark theme
I created SVGs for all the icons in o.e.ui.themes/icons and created high resolution icons. This makes the rendering much look better (especially on the rounded corners) on high res displays (see my screenshots). The old icons all had a coloured background that matched the background of the OSes widget. As PNGs support transparency, I removed this background. Via this the native widget looks through and we don't need to changes these images again once the native widgets background changes again. Note: After that all the handle images (*Handle*.png”) are identical except of the one used in all dark themes and in e4-light and e4-classic (dragHandle*.png). So this could be cleaned up in a separate commit. Also the *frame*.png icons are very similar only the stroke color is slightly different. I don't know if this is by intention of if we can unify this in addition. I tested this change on macOS in light and dark theme. They should also be tested on windows and linux will all the themes that are available there. Especially check if the transparency works as expected.
Created attachment 282885 [details] Screenshot Linux Dark
Created attachment 282886 [details] Light Linux
(In reply to Matthias Becker from comment #22) > Note: After that all the handle images (*Handle*.png”) are identical except > of the one used in all dark themes and in e4-light and e4-classic > (dragHandle*.png). So this could be cleaned up in a separate commit. > Also the *frame*.png icons are very similar only the stroke color is > slightly different. I don't know if this is by intention of if we can unify > this in addition. +1 for unification of the icons, please open a new bug for that. Also IMHO it would be nice if the element could loose its rounded corners.
+1 for loosing rounded corners :)
Note: Need to restart the runtime Eclipse after a theme switch, otherwise the icons look bad (not related to this patch).
Created attachment 282887 [details] Dark windows
Created attachment 282888 [details] Light windows
Change looks good on Linux & Windows. Thanks, Matthias. Please merge (after fixing the merge markers in the commit)
The dots are not all of equal size, some of them end up being stretched when rendered. This was a problem before any of these patches though.
(In reply to Pierre-Yves B. from comment #31) > The dots are not all of equal size, some of them end up being stretched when > rendered. This was a problem before any of these patches though. Which once get streched?
(In reply to Matthias Becker from comment #32) > (In reply to Pierre-Yves B. from comment #31) > > The dots are not all of equal size, some of them end up being stretched when > > rendered. This was a problem before any of these patches though. > > Which once get streched? I'm specifically talking about the handles (the images with the four dots). For example, on Lars's screenshot for the light theme: * for vertical handles, numbering dots from 1 to 4 from top to bottom, dot 1 is three pixels high, dot 2, 3 and 4 are two pixels high. Dots 1, 2 and 3 are separated by two pixels, dots 3 and 4 are separated by three pixels. * for horizontal handles, numbering dots from 1 to 4 from left to right, dots 1 and 4 are three pixels wide, dots 1 and 3 are two pixels wide. Dots 1, 2 and 3, 4 are separated by two pixels, dots 2 and 2 are separated by three pixels. The white shades of dots 1 and 3 are two pixels wide, the shades of dots 2 and 4 are four pixels wide. There are similar problems on your macOS screenshot, though not as severe. On the Linux screenshot, the dots which initially have a square shape in the version controlled image have become rectangles.
(In reply to Pierre-Yves B. from comment #33) > I'm specifically talking about the handles (the images with the four dots). > For example, on Lars's screenshot for the light theme: > * for vertical handles, numbering dots from 1 to 4 from top to bottom, dot 1 > is three pixels high, dot 2, 3 and 4 are two pixels high. Dots 1, 2 and 3 > are separated by two pixels, dots 3 and 4 are separated by three pixels. > * for horizontal handles, numbering dots from 1 to 4 from left to right, > dots 1 and 4 are three pixels wide, dots 1 and 3 are two pixels wide. Dots > 1, 2 and 3, 4 are separated by two pixels, dots 2 and 2 are separated by > three pixels. The white shades of dots 1 and 3 are two pixels wide, the > shades of dots 2 and 4 are four pixels wide. > > There are similar problems on your macOS screenshot, though not as severe. > > On the Linux screenshot, the dots which initially have a square shape in the > version controlled image have become rectangles. I just checked again. I see what you mean on the screenshot. But maybe this is an artefact of the screenshot. I just looked at my macOS screenshots and don't see the issue here. I also compared e.g. the old and the new version gtkHandle.png files. They both have 5x20 pixels and the dots are 2x2 pixels in both versions. Do you see this issue also in the running eclipse instance?
(In reply to Matthias Becker from comment #34) > Do you see this issue also in the running eclipse instance? On my Windows machine, yes, I can definitely see these issues in the running Eclipse, patch or without patch. Less noticeable on my macOS, but it doesn't seem perfect either (though only tested the non patch version, without the higher scale images).
(In reply to Pierre-Yves B. from comment #35) > On my Windows machine, yes, I can definitely see these issues in the running > Eclipse, patch or without patch. So you are saying that this issue already existed before my patch?
(In reply to Matthias Becker from comment #36) > (In reply to Pierre-Yves B. from comment #35) > > On my Windows machine, yes, I can definitely see these issues in the running > > Eclipse, patch or without patch. > > So you are saying that this issue already existed before my patch? Yes, I also said so here: (In reply to Pierre-Yves B. from comment #31) > This was a problem before any of these patches though.
(In reply to Pierre-Yves B. from comment #37) > (In reply to Matthias Becker from comment #36) > > (In reply to Pierre-Yves B. from comment #35) > > > On my Windows machine, yes, I can definitely see these issues in the running > > > Eclipse, patch or without patch. > > > > So you are saying that this issue already existed before my patch? > > Yes, I also said so here: > > (In reply to Pierre-Yves B. from comment #31) > > This was a problem before any of these patches though. Oh. I missed this. So should we merge this change? What do you think?
(In reply to Matthias Becker from comment #38) > (In reply to Pierre-Yves B. from comment #37) > > (In reply to Matthias Becker from comment #36) > > > (In reply to Pierre-Yves B. from comment #35) > > > > On my Windows machine, yes, I can definitely see these issues in the running > > > > Eclipse, patch or without patch. > > > > > > So you are saying that this issue already existed before my patch? > > > > Yes, I also said so here: > > > > (In reply to Pierre-Yves B. from comment #31) > > > This was a problem before any of these patches though. > > Oh. I missed this. So should we merge this change? What do you think? Yes, I think we should merge current patches. :)
+1 for merge, no new issues are introduced AFAICS
Gerrit change https://git.eclipse.org/r/163125 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a1babf395e71ad35d6b4201ca3ce57b03f11712f
Gerrit change https://git.eclipse.org/r/163127 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.images.git/commit/?id=6a2dcf68c9bf87ace87e0999cdee5995d9e50ac9
I don't think any of the images specified in the CSS files are being used, at least on Windows. For example, values such as "handle-image: url(./dragHandle.png);" are specified, but how could that work given that the images themselves are in different sub-folders? If you put breakpoints in org.eclipse.e4.ui.internal.workbench.swt.CSSRenderingUtils, you'll notice that none of the values specified in CSS are resolved successfully. The class falls back to default images, for examples dragHandle.png in org.eclipse.e4.ui.workbench.swt. This may explain Bug 563497 and why adding the @2x did not seem to improve scaling issues.
(In reply to Pierre-Yves B. from comment #43) > I don't think any of the images specified in the CSS files are being used, > at least on Windows. > > For example, values such as "handle-image: url(./dragHandle.png);" are > specified, but how could that work given that the images themselves are in > different sub-folders? > > If you put breakpoints in > org.eclipse.e4.ui.internal.workbench.swt.CSSRenderingUtils, you'll notice > that none of the values specified in CSS are resolved successfully. The > class falls back to default images, for examples dragHandle.png in > org.eclipse.e4.ui.workbench.swt. > > This may explain Bug 563497 and why adding the @2x did not seem to improve > scaling issues. I don't see this on macOS url(./winTSFrame.png) from the CSS is translated to file:/......./org.eclipse.ui.themes/images/./macHandle.png that is translated to ...org.eclipse.ui.themes/images/macHandle.png which is absolutely correct.
