Community
Participate
Working Groups
I suggest to use png files instead of the custom drawings in CTabFolderRenderer for the minimize and maximize icons. IMHO the icons looks strange in Eclipse especially if you scale the icons up. Currently the calculation is done in drawMaximize and drawMinimize.
Relevant methods: CTabFolderRenderer#drawMinimize and CTabFolderRenderer#drawMaximize. Both methods provide three icons, one for the normal state, one for the hot (mouse over) state and a selected state.
Looks like we need only one icon for maximize, re-maximize and minimized. At least in my testing the SWT.HOT code path is not used. Test code: void drawMaximize(GC gc, Rectangle maxRect, int maxImageState) { .... switch (maxImageState & (SWT.HOT | SWT.SELECTED)) { case SWT.NONE: if (!parent.getMaximized()) { // testing Image systemImage = new Image(Display.getDefault(), "D:/dev/icons/full/elcl16/tempmaximized.png"); gc.drawImage(systemImage, x, y); systemImage.dispose(); } else { // testing Image systemImage = new Image(Display.getDefault(), "D:/dev/icons/full/elcl16/temprestore.png"); gc.drawImage(systemImage, x, y); systemImage.dispose(); } break; }
But aren't the colors for fill an lines that are set via: gc.setForeground(display.getSystemColor(BUTTON_BORDER)); gc.setBackground(display.getSystemColor(BUTTON_FILL)); platform dependent? Don't they change automatically from platform to platform? We cannot do this as PNGs. I set some breakpoints but only reach the "case SWT.NONE" branch. How can the other be reached?
(In reply to Matthias Becker from comment #3) > But aren't the colors for fill an lines that are set via: > platform dependent? Don't they change automatically from platform to > platform? We cannot do this as PNGs. I think that is a "feature loss", if we switch to png files, but the "feature gain" is that the button will better on HDPI and dark background. Also on Mac the drawing looks really bad IMHO and this will improve with png files. > I set some breakpoints but only reach the "case SWT.NONE" branch. > How can the other be reached? I also was not able to reach that part of the coding. I did send a question about SWT.HOT to the swt mailing list for that. http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg08016.html
in which repo can I find the source code of CTabFolderRenderer? eclipse.platform.swt.binaries only contains the binaries
(In reply to Matthias Becker from comment #5) > in which repo can I find the source code of CTabFolderRenderer? > eclipse.platform.swt.binaries only contains the binaries https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.swt
Created attachment 264143 [details] Screenshots of the maximize, minimize and restore I was a bit confused about the SWT-Coordinate system especially about the fact that the end points are included in lines. ( Found "The end points are included in the line, and if they are the same then a single pixel dot will be drawn." on https://www.eclipse.org/articles/Article-SWT-graphics/SWT_graphics.html ) So I hope it counted the pixels in the right way. The attachment shows a screenshot of out of Inkscape where you see the SVG with a light gray background (so see the white fill of the shapes) and the 1x1 pixels document grid. Do the look right?
Retargetting to 4.7
(In reply to Matthias Becker from comment #5) > in which repo can I find the source code of CTabFolderRenderer? > eclipse.platform.swt.binaries only contains the binaries See https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.swt
(In reply to Lars Vogel from comment #9) > (In reply to Matthias Becker from comment #5) > > in which repo can I find the source code of CTabFolderRenderer? > > eclipse.platform.swt.binaries only contains the binaries > > See https://git.eclipse.org/r/#/admin/projects/platform/eclipse.platform.swt http://git.eclipse.org/c/platform/eclipse.platform.swt.git/plain/bundles/org.eclipse.swt/Eclipse%20SWT%20Custom%20Widgets/common/org/eclipse/swt/custom/CTabFolderRenderer.java
This would require changes in CTabFolder code as well. Moving to 4.8.
New Gerrit change created: https://git.eclipse.org/r/120357
Matthias, can you upload a change for SWT so that I can test this?
(In reply to Lars Vogel from comment #13) > Matthias, can you upload a change for SWT so that I can test this? Up to now I only have the SVGs and PNGs. We should first decide if we go for the black lines with the white fill or not.
Moving out of M7, please re-target this bug as required.
Moving to 4.9, please re-target as required.
I just updated the SVGs and PNGs with the colors we aggreed on in bug 466511. As I don't have a SWT dev environment at hand: Can someone of the SWT dev replace the custom drawings in CTabFolderRenderer#drawMinimize and CTabFolderRenderer#drawMaximize with the provided PNGs?
Resetting target. Please re-target as required.
(In reply to Matthias Becker from comment #17) > I just updated the SVGs and PNGs with the colors we aggreed on in bug 466511. > As I don't have a SWT dev environment at hand: Can someone of the SWT dev > replace the custom drawings in CTabFolderRenderer#drawMinimize and > CTabFolderRenderer#drawMaximize with the provided PNGs? Lets do this together while I'm Walldorf.
Is it still in plan for 4.10? If not please re-target as required.
Remove the target as M3 is done. Please set target when planning to merge it.
As we now use png files for the view menu, I suggest we finish this one too.
Thomas, are you aware of good unicode characters to replace min / max? Similar to the close icon it would be nice if we could replace the custom drawings.
(In reply to Lars Vogel from comment #23) > Thomas, are you aware of good unicode characters to replace min / max? > Similar to the close icon it would be nice if we could replace the custom > drawings. From emojipedia: 🗖 and 🗕, which are very "raw" but maybe good enough.
(In reply to Mickael Istria from comment #24) > (In reply to Lars Vogel from comment #23) > > Thomas, are you aware of good unicode characters to replace min / max? > > Similar to the close icon it would be nice if we could replace the custom > > drawings. > > From emojipedia: 🗖 and 🗕, which are very "raw" but maybe good enough. The above icons look the same to me on latest Ubuntu.
(In reply to Lars Vogel from comment #23) > Thomas, are you aware of good unicode characters to replace min / max? Not really. Maybe ⊡ (\u22a1) and ⊟ (\u229f) for "minimize" and "maximize", but that doesn't really convey the idea. Or ⊹ (\u22b9) for "miminize". There's also ▫(\u25ab) and ◻ (\u25fb) and ◰ (\u25f0) and ◳ (\u25f3). On an unrelated note, there's also ⋮ (\u22ee) or ⁝ (\u205d). How's the view menu "hamburger" done? Not sure all fonts have all these. 20xx is Unicode "General Punctuation", 22xx is "Mathematical Operators", 25ax and 25fx are "Geometric Shapes".
Thanks, Thomas. > How's the view menu "hamburger" done? Current the view menu is an icon. Would be nice to replace that with unicode.
(In reply to Lars Vogel from comment #27) > Thanks, Thomas. > > > How's the view menu "hamburger" done? > > Current the view menu is an icon. Would be nice to replace that with unicode. If Unicode, there's also ▿ (\u25bf). I liked the old triangle better than the three dots.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/171799
(In reply to Thomas Wolf from comment #26) > (In reply to Lars Vogel from comment #23) > > Thomas, are you aware of good unicode characters to replace min / max? > > Not really. Maybe ⊡ (\u22a1) and ⊟ (\u229f) for "minimize" and "maximize", > but that doesn't really convey the idea. Or ⊹ (\u22b9) for "miminize". > There's also ▫(\u25ab) and ◻ (\u25fb) and ◰ (\u25f0) and ◳ (\u25f3). > > On an unrelated note, there's also ⋮ (\u22ee) or ⁝ (\u205d). How's the view > menu "hamburger" done? > > Not sure all fonts have all these. 20xx is Unicode "General Punctuation", > 22xx is "Mathematical Operators", 25ax and 25fx are "Geometric Shapes". Hi Thomas, thanks again. I created https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/171799 to make it easier for others to play with the potential unicode characters. Issue, currently the icons are really "fat" due to the font size. But if I decrease the font size the icons get really small. Suggestion how to improve this are very welcome.
(In reply to Lars Vogel from comment #30) > Hi Thomas, thanks again. I created > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/171799 to make > it easier for others to play with the potential unicode characters. Issue, > currently the icons are really "fat" due to the font size. But if I decrease > the font size the icons get really small. Suggestion how to improve this are > very welcome. I've commented on the patch, but here again - I have concerns regarding such change. This is not cross-platform. "Arial" is not something we can hard-code here and expect that it will be available on all platforms. *If* SWT would embed some font that has the right characters, it could be OK. But without it, every installation of Eclipse would look different and we couldn't be even sure we would have the right characters available and if, with which font characteristics.
(In reply to Lars Vogel from comment #30) > Hi Thomas, thanks again. I created > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/171799 to make > it easier for others to play with the potential unicode characters. Issue, > currently the icons are really "fat" due to the font size. But if I decrease > the font size the icons get really small. Suggestion how to improve this are > very welcome. I'm not convinced using fonts like this is a good way to go. You'd always depend on how exactly a particular glyph is defined in a standard font (like the "Arial" you used), and on the font and the glyph in the font being present at all. I'd rather investigate using SVG icons directly, or if it's got to be a font, use a dedicated icon font. Check out how "icon fonts" work in HTML 5. Basically you could define your own font containing the glyphs you want, at the character codes you want. There's tools out there that can create such fonts for a set of SVG icons. Don't know if gc.drawString() can work directly with such web fonts, or if they'd have to be converted into something else first -- if so, it should also be possible, as long as it's all vector formats.
(In reply to Andrey Loskutov from comment #31) > *If* SWT would embed some font that has the right characters, it could be > OK. But without it, every installation of Eclipse would look different and > we couldn't be even sure we would have the right characters available and > if, with which font characteristics. Exactly. We both made the same point.
(In reply to Andrey Loskutov from comment #31) > But without it, every installation of Eclipse would look different and > we couldn't be even sure we would have the right characters available and > if, with which font characteristics. The fact that the IDE looks different according to the system is the expectation with SWT. It's not something we need to fight against, we instead it to navigate it smoothly to get better results than other IDEs can achieve. The suggested characters are using Unicode. Isn't it safe to assume that the fonts used by the Eclipse IDE, the OS by default are expected to be Unicode-compliant and just drop the ball to the OS if something is wrong? (In reply to Lars Vogel from comment #25) > > From emojipedia: 🗖 and 🗕, which are very "raw" but maybe good enough. > > The above icons look the same to me on latest Ubuntu. Really? I suggest reporting a bug to Ubuntu then.
As the font is only required to define the sizing, it should be save to use the parent font. I update the patch.
(In reply to Lars Vogel from comment #4) > I think that is a "feature loss", if we switch to png files, but the > "feature gain" is that the button will better on HDPI and dark background. > Also on Mac the drawing looks really bad IMHO and this will improve with png > files. I really wonder why the "custom drawing" should look bad compared to a PNG file? It should scale to every size, use platform.dependent colors, varying line-with and so on, so it should be superior to any rastered image anyways. Maybe its more HOW it is drawn that makes it look ugly (e.g. not using Antialising, missing shaddoweffects, not using transforms/line properties where necessary and so on...?)
Now that we draw a nicer close icon we should also try to draw a nicer min and max icon.
(In reply to Lars Vogel from comment #37) > Now that we draw a nicer close icon we should also try to draw a nicer min > and max icon. What's wrong with the existing ones? And have you thought about how these types of changes affect downstream RCP apps?
(In reply to Phil Beauvoir from comment #38) > (In reply to Lars Vogel from comment #37) > > Now that we draw a nicer close icon we should also try to draw a nicer min > > and max icon. > > What's wrong with the existing ones? And have you thought about how these > types of changes affect downstream RCP apps? I think the min / max icons in general look fine, but the drawn background does IMHO not look good on light and dark background. Multiple RCP clients I support complained in the past about the tab icons (mostly about the close icon), one of them implemented a custom tab renderer to be able to use updated icons.
(In reply to Lars Vogel from comment #39) > (In reply to Phil Beauvoir from comment #38) > > (In reply to Lars Vogel from comment #37) > > > Now that we draw a nicer close icon we should also try to draw a nicer min > > > and max icon. > > > > What's wrong with the existing ones? And have you thought about how these > > types of changes affect downstream RCP apps? > > I think the min / max icons in general look fine, but the drawn background > does IMHO not look good on light and dark background. > > Multiple RCP clients I support complained in the past about the tab icons > (mostly about the close icon), one of them implemented a custom tab renderer > to be able to use updated icons. Fair comments, Lars. I mention the RCP aspect because some of our app (Archi) users have complained when something changes in this regard. ;-)
(In reply to Phil Beauvoir from comment #40) > I mention the RCP aspect because some of our app (Archi) users have > complained when something changes in this regard. ;-) I don't understand this. How can they complain about something we have not yet done? Or do you already know from past experience that your users dislike any UI change?
(In reply to Lars Vogel from comment #41) > (In reply to Phil Beauvoir from comment #40) > > > I mention the RCP aspect because some of our app (Archi) users have > > complained when something changes in this regard. ;-) > > I don't understand this. How can they complain about something we have not > yet done? Or do you already know from past experience that your users > dislike any UI change? I didn't mean this particular change. I mean generally things they have no control over such as the local context menu icon changing to three vertical dots from a triangle.
(In reply to Phil Beauvoir from comment #42) > I didn't mean this particular change. I mean generally things they have no > control over such as the local context menu icon changing to three vertical > dots from a triangle. There are some discussions here and there about themable icons that would allow RCP providers to ship a static set of icons that doesn't depend on Platform. Bug 562174 is probably the most advanced one. This is the direction you should investigate for such users, if you think their complaints are worth addressing.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/184518
Created attachment 287329 [details] Screenshot Linux before / after
Created attachment 287330 [details] Screenshot light Linux before / after
(In reply to Lars Vogel from comment #46) > Created attachment 287330 [details] > Screenshot light Linux before / after There is now an inconsistency with "three dots" button (icon with circles filled with white) and the updated min/max "not filled with white" buttons. Shouldn't this "three dots" be drawn now in same way other two are drawn?
(In reply to Andrey Loskutov from comment #47) > (In reply to Lars Vogel from comment #46) > > Created attachment 287330 [details] > > Screenshot light Linux before / after > > There is now an inconsistency with "three dots" button (icon with circles > filled with white) and the updated min/max "not filled with white" buttons. > Shouldn't this "three dots" be drawn now in same way other two are drawn? That is an png file. Please open a new bug for that.
(In reply to Lars Vogel from comment #48) > > There is now an inconsistency with "three dots" button (icon with circles > > filled with white) and the updated min/max "not filled with white" buttons. > > Shouldn't this "three dots" be drawn now in same way other two are drawn? > > That is an png file. Please open a new bug for that. Why should I? I'm fine with *current* state. But if we are going to change two from three similar looking icons, we should make sure all three are changed in a consistent way. So that belongs to this issue.
(In reply to Andrey Loskutov from comment #49) > So that belongs > to this issue. The png file is in a different repo. I opened Bug 576700 for updating the png file in platform.ui.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/184518 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ae55d602c3a85d7c78c919d820e5658155536e1b
