Bugzilla – Full Text Bug Listing
| Summary: | Dehardcode Adwaita CSS theme fixes | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Simeon Andreev <simeon.danailov.andreev> | ||||||
| Component: | SWT | Assignee: | Leo Ufimtsev <lufimtse> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | akurtakov, ericwill, Lars.Vogel, loskutov, lufimtse, platform-swt-inbox | ||||||
| Version: | 4.8 | Keywords: | triaged | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| See Also: |
https://git.eclipse.org/r/#/c/117868/ https://bugs.eclipse.org/bugs/show_bug.cgi?id=531573 https://git.eclipse.org/r/#/c/120811/ https://bugs.eclipse.org/bugs/show_bug.cgi?id=534007 https://git.eclipse.org/r/121751 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=886e6c5bac16f14c66405e5d72874a39c632835e |
||||||||
| Whiteboard: | Category:theme | ||||||||
| Attachments: |
|
||||||||
Alexander, this one would be great to fix for 4.8. The problem we have is that we would like to avoid customization via "vmargs" / SWT CSS files because they do not allow the GTK theme to provide the "right" look and feel, because the theme can't override styles set via this code/priority: OS.gtk_style_context_add_provider_for_screen (screen, provider, OS.GTK_STYLE_PROVIDER_PRIORITY_APPLICATION); I'm not sure what is the right way to fix it, but for system integrators would be easier to enhance Eclipse installation to have some extra SWT fragment as to try to explain every user to extend the command line by -vmargs -Dorg.eclipse.swt.internal.gtk.cssFile=/path/to/custom/css. My idea is that we could patch SWT and check in the org.eclipse.swt.graphics.Device.init() code if some fragment provides a "custom" CSS file. If not, then we can proceed as before. If yes, we will load this CSS instead of the one provided with SWT. The fragment itself (on our side) can be written in the way that it consumes theme/platform specific CSS files adopted and compatible with desired theme. WDYT? (In reply to Simeon Andreev from comment #0) > Created attachment 271630 [details] > Eclipse under GTK 3.22 with non-Adwaita theme > > While moving from RHEL 7.2 (gtk3-3.14) to RHEL 7.4 (gtk3-3.22) we observed > that the IDE looks rather unpleasant. This is too polite. The IDE looked like unfinished unusable piece of ... written by small children in North Korea and I was really shocked to see that. We can't let our customers/developers to work with that. (In reply to Simeon Andreev from comment #0) > Created attachment 271630 [details] > Eclipse under GTK 3.22 with non-Adwaita theme > > While moving from RHEL 7.2 (gtk3-3.14) to RHEL 7.4 (gtk3-3.22) we observed > that the IDE looks rather unpleasant. Did you make sure your theme supports GTK3.22? Some themes are still stuck in GTK3.14/16/18 land, and in GTK3.20 they changed a lot of the CSS selectors. This would result in lots of ugliness if your theme isn't GTK3.20+ compatible. I know clearlooks upsteam has a GTK3.20 version, but is this the version used in RHEL? > > See the attached screenshot "clearlooks-phenix-7-theme.png". > > The issues are as follows. > > 1. Text fields are HUGE. This seems to be due to Adwaita defining a minimum > height for even more huge text fields. The min height is set to 26px in > org.eclipse.swt.graphics.Device via a css file. This is unnecessarily > punishing to users with normal, non-elephantine themes. This should actually be fixed with Photon M3/Oxygen.2, as there was a bug fix for this recently. See bug 487522 (comment 10 onwards). > 2. Padding for toolbar buttons is set to 0, resulting in cramped toolbars. > Again due to Adwaita, where setting the padding to 0 seems to yield OK > results. > > Large text boxes and small toolbars combined make the IDE feel awkward. > > > For the toolbar buttons, we were able to set a min-width. While this is > questionable, we can live with it. For the text boxes, we can only set the > variable org.eclipse.swt.internal.gtk.cssFile to a css file which overwrites > what Eclipse sets. This is definitely better than nothing, but far from > ideal. > I would continue with this approach for the toolbars for now, as the padding and different spacing variations across different themes make it hard to pin down a good value to use. As for the text boxes, see my comment above. > It would be great if one of the following could be provided: > > 1. Adjust the custom css for gtk 3.20+ in a less invasive way to other > themes. SWT doesn't ship with its own GTK theme, we only set a few values at load time to make things look consistent (i.e. toolbar padding). The issue is that there are too many themes trying to do different things, it would be impossible to keep up with all of them. Instead we ensure that things are the proper size on the GTK3 Adwaita theme, and we try to scrape colors/sizes/values from other themes dynamically, where possible. That said, see below: (In reply to Andrey Loskutov from comment #1) > My idea is that we could patch SWT and check in the > org.eclipse.swt.graphics.Device.init() code if some fragment provides a > "custom" CSS file. If not, then we can proceed as before. If yes, we will > load this CSS instead of the one provided with SWT. I would be okay with this and I think it's doable. Thoughts, Alex? btw, on the side. Does anyone know what is the standard theme on RHEL7.4 gtk3.22? Is it Adwaita? (In reply to Leo Ufimtsev from comment #4) > btw, on the side. Does anyone know what is the standard theme on RHEL7.4 > gtk3.22? Is it Adwaita? Yes. (In reply to Eric Williams from comment #3) > (In reply to Simeon Andreev from comment #0) > > Created attachment 271630 [details] > > Eclipse under GTK 3.22 with non-Adwaita theme > > > > While moving from RHEL 7.2 (gtk3-3.14) to RHEL 7.4 (gtk3-3.22) we observed > > that the IDE looks rather unpleasant. > > Did you make sure your theme supports GTK3.22? Sure not, we are working right now on porting the theme to GTK 3.22. The screenshot you see is on the midway of fixing the theme. > Some themes are still stuck > in GTK3.14/16/18 land, and in GTK3.20 they changed a lot of the CSS > selectors. Yep. Eclipse was literally not usable, not just the widget sizes, NOTHING working at all. > This would result in lots of ugliness if your theme isn't > GTK3.20+ compatible. I know clearlooks upsteam has a GTK3.20 version, but is > this the version used in RHEL? The clearlooks-phoenix theme is not a part of RHEL anyway, but because RHEL does not provide a professional theme for GTK3 (no, Adwaita is not), we have to install additional theme rpm's. (In reply to Andrey Loskutov from comment #6) > The clearlooks-phoenix theme is not a part of RHEL anyway, but because RHEL > does not provide a professional theme for GTK3 (no, Adwaita is not), we have > to install additional theme rpm's. /side discussion: Why do you think Adwaita is not a professional theme? (In reply to Leo Ufimtsev from comment #7) > (In reply to Andrey Loskutov from comment #6) > > The clearlooks-phoenix theme is not a part of RHEL anyway, but because RHEL > > does not provide a professional theme for GTK3 (no, Adwaita is not), we have > > to install additional theme rpm's. > > /side discussion: > Why do you think Adwaita is not a professional theme? Scrollbars are tiny, but the rest is huge (buttons/combos). Why?!? Tabs aren't looking as tabs, scrollbars aren't looking as scrollbars ?!? If I would have time I would write a blog entry why the Adwaita is an excellent example of the product missed target audience and full of broken UI paradigms. I also have a feel that Adwaita (or Gnome desktop in its latest reincarnations) is written by blind people working with touchscreens for blind people working with touchscreens. Our customers and our developers do not use touchscreens and they aren't blind (we have some blind people, but they aren't using GTK/Eclipse anyway). (In reply to Andrey Loskutov from comment #2) > (In reply to Simeon Andreev from comment #0) > > Created attachment 271630 [details] > > Eclipse under GTK 3.22 with non-Adwaita theme > > > > While moving from RHEL 7.2 (gtk3-3.14) to RHEL 7.4 (gtk3-3.22) we observed > > that the IDE looks rather unpleasant. > > This is too polite. The IDE looked like unfinished unusable piece of ... > written by small children in North Korea and I was really shocked to see > that. We can't let our customers/developers to work with that. Andrey, I wonder how much support one would get for UI issues running with non-standard theme on Windows or MacOS. Proper theming is really hard thing to do, it's like building on floathing sands and comments like that are not motivating, quite the opposite rather provoking people to just say we don't support 3rd party themes (esp a non-finished one) at all and hardcode adwaita to prevent people blaming swt for their theme breakage. With that said - proper bug reports (aka not insulting) like the one Eric pointed too are showing the time spend in dealing with these details. But getting this things proper demand people willing to distribute and use their own themes to be cooperative and constructive and admit that whoever needs smth is the one that initiates the work and asks others for help in case they can offer it, otherwise being ready to do it on his own, that's how FOSS work. (In reply to Andrey Loskutov from comment #8) > (In reply to Leo Ufimtsev from comment #7) > > (In reply to Andrey Loskutov from comment #6) > > > The clearlooks-phoenix theme is not a part of RHEL anyway, but because RHEL > > > does not provide a professional theme for GTK3 (no, Adwaita is not), we have > > > to install additional theme rpm's. > > > > /side discussion: > > Why do you think Adwaita is not a professional theme? > > Scrollbars are tiny, but the rest is huge (buttons/combos). Why?!? Tabs > aren't looking as tabs, scrollbars aren't looking as scrollbars ?!? If I > would have time I would write a blog entry why the Adwaita is an excellent > example of the product missed target audience and full of broken UI > paradigms. I also have a feel that Adwaita (or Gnome desktop in its latest > reincarnations) is written by blind people working with touchscreens for > blind people working with touchscreens. Our customers and our developers do > not use touchscreens and they aren't blind (we have some blind people, but > they aren't using GTK/Eclipse anyway). Another not constructive reply. If there is anything that's for sure is that Gnome and Adwaita are not written for touchscreens but if discussion is to continue that way I would rather just ignore it from now on. (In reply to Andrey Loskutov from comment #8) > Scrollbars are tiny, but the rest is huge (buttons/combos). Why?!? Tabs > aren't looking as tabs, scrollbars aren't looking as scrollbars ?!? If I > would have time I would write a blog entry why the Adwaita is an excellent > example of the product missed target audience and full of broken UI > paradigms. I also have a feel that Adwaita (or Gnome desktop in its latest > reincarnations) is written by blind people working with touchscreens for > blind people working with touchscreens. Our customers and our developers do > not use touchscreens and they aren't blind (we have some blind people, but > they aren't using GTK/Eclipse anyway). I don't have a touch screen, but I quite like the small/hidden scrollbars :-). I scroll via scroll wheel or my touch pad, I don't usually 'grab' the scrollbar. I guess it's a matter of personal taste. I can for a fact say that the gnome developers are not blind people and they generally don't use touch screens as I've met them in person last year ^_^. (just fyi). But I can see the benefit of having a more 'traditional' looking theme for folks that like it that way. (In reply to Leo Ufimtsev from comment #11) > (In reply to Andrey Loskutov from comment #8) > > Scrollbars are tiny, but the rest is huge (buttons/combos). Why?!? Tabs > > aren't looking as tabs, scrollbars aren't looking as scrollbars ?!? If I > > would have time I would write a blog entry why the Adwaita is an excellent > > example of the product missed target audience and full of broken UI > > paradigms. I also have a feel that Adwaita (or Gnome desktop in its latest > > reincarnations) is written by blind people working with touchscreens for > > blind people working with touchscreens. Our customers and our developers do > > not use touchscreens and they aren't blind (we have some blind people, but > > they aren't using GTK/Eclipse anyway). > > I don't have a touch screen, but I quite like the small/hidden scrollbars > :-). I scroll via scroll wheel or my touch pad, I don't usually 'grab' the > scrollbar. I guess it's a matter of personal taste. > I can for a fact say that the gnome developers are not blind people and they > generally don't use touch screens as I've met them in person last year ^_^. > (just fyi). > > But I can see the benefit of having a more 'traditional' looking theme for > folks that like it that way. Again, having a traditional theme means someone steps in and doing the work needed not just blaming others. (In reply to Alexander Kurtakov from comment #12) .. > > But I can see the benefit of having a more 'traditional' looking theme for > > folks that like it that way. > > Again, having a traditional theme means someone steps in and doing the work > needed not just blaming others. That's a good point. As a side note, a lot of the gnome developers do the work in their own time and are quite welcoming of contributions :-). (In reply to Alexander Kurtakov from comment #9) > Andrey, I wonder how much support one would get for UI issues running with > non-standard theme on Windows or MacOS. This is a different story, but the number of if(GTK3.10) else if (GTK3.14) else if(GTK3.20) else ... speaks not for GTK as a platform. I don't think we have similar number of switches for Windows or Mac. And for sure having themes adds a bunch of issues on top of that. > Proper theming is really hard thing > to do, it's like building on floathing sands and comments like that are not > motivating, I'm sorry for that, it was not my intention to de-motivate anyone but rather an attempt explain what bugs me after a week trying RHEL 7.4. > quite the opposite rather provoking people to just say we don't > support 3rd party themes (esp a non-finished one) at all and hardcode > adwaita to prevent people blaming swt for their theme breakage. I'm not blaming SWT for this bug. It is clearly the GTK / Adwaita issue, which SWT tried to fix with patches for Adwaita, and some of the patches have even negative side effects for other themes. Hard-coding Adwaita in SWT would be a solution, sure, but this would lead to extremely unhappy users. "Flat pack" thing would be a better idea, if we would ship GTK themes adjusted to work fine with Eclipse. I could imagine such flat pack could then include not only Adwaita themes. (In reply to Alexander Kurtakov from comment #10) > Another not constructive reply. It is just reply from extremely frustrated IDE maintainer. You can't believe how hard it is to make (some kind of) professionally looking Eclipse IDE on Linux, if almost all users know what is possible thanks to Apple/Windows and they do not lower they expectations for Linux. The constructive part was in comment 2. WDYT about that? (In reply to Andrey Loskutov from comment #14) > (In reply to Alexander Kurtakov from comment #9) > > Andrey, I wonder how much support one would get for UI issues running with > > non-standard theme on Windows or MacOS. > > This is a different story, but the number of if(GTK3.10) else if (GTK3.14) > else if(GTK3.20) else ... speaks not for GTK as a platform. I don't think we > have similar number of switches for Windows or Mac. And for sure having > themes adds a bunch of issues on top of that. Yes, we should just stop supporting anything prior to 3.22. That would make people happier. And most of these switches are for theming exactly, which IMHO we should stop supporting too. > > > Proper theming is really hard thing > > to do, it's like building on floathing sands and comments like that are not > > motivating, > > I'm sorry for that, it was not my intention to de-motivate anyone but rather > an attempt explain what bugs me after a week trying RHEL 7.4. > > > quite the opposite rather provoking people to just say we don't > > support 3rd party themes (esp a non-finished one) at all and hardcode > > adwaita to prevent people blaming swt for their theme breakage. > > I'm not blaming SWT for this bug. It is clearly the GTK / Adwaita issue, > which SWT tried to fix with patches for Adwaita, and some of the patches > have even negative side effects for other themes. Yeah, we should have sticked to GTK defaults and tell people, this is your OS theme defaults - live with it. > > Hard-coding Adwaita in SWT would be a solution, sure, but this would lead to > extremely unhappy users. "Flat pack" thing would be a better idea, if we > would ship GTK themes adjusted to work fine with Eclipse. I could imagine > such flat pack could then include not only Adwaita themes. If at anytime additional themes are shipped with such a flatpak that would happen only when someone steps in and is ready to fix issues with the given theme not before that. > > (In reply to Alexander Kurtakov from comment #10) > > Another not constructive reply. > > It is just reply from extremely frustrated IDE maintainer. You can't believe > how hard it is to make (some kind of) professionally looking Eclipse IDE on > Linux, if almost all users know what is possible thanks to Apple/Windows and > they do not lower they expectations for Linux. > > The constructive part was in comment 2. WDYT about that? Do you really find this constructive? (In reply to Alexander Kurtakov from comment #15) > > > > The constructive part was in comment 2. WDYT about that? > > Do you really find this constructive? Sorry, I meant "in the second comment", but for bugzilla this means comment 1. Long story short, if we release our product with Adwaita look and feel, our user base will tell us to roll-back or to fix it. And they will be at least as vocal as Andrey.
Why I agree with our user base:
I am now working with Eclipse on both Windows 10, on RHEL 7.2 and on RHEL 7.4 due to my workplace conditions. And I really agree with Andrey here.
I've worked with Eclipse on Windows XP, Windows 7, Windows 10, MacOS, Ubuntu, Open Suse and RHEL. I've never seen anything like Adwaita in any OS other than RHEL. To me, this alone is reason to dislike the RHEL+Adwaita constellation.
Look and feel in anything but RHEL+Adwaita is simply consistent with how Eclipse looked during all my work with Eclipse (about 13 years now). RHEL 7.x, with Adwaita, on the other hand, is not. Having a VNC session on RHEL and a Windows 10 session next to each other on two displays, I must say that Adwaita simply looks embarrassing in comparison. IMHO it looks like an odd mix of a SmartPhone application and a normal desktop application.
I find the lack of consistency between RHEL and *every other OS I've used* to be very unfortunate. With a custom theme, its definitely possibly to attain the "classic" look that I am used to. This is however very time consuming.
I'm sure cursing is not the right way to proceed here, but currently I'm working on tasks such as:
> See the attached screenshot.
> 1. The space between box and text in the check box widget is too narrow
> 2. Ste space between box and the text in the table is too wide
> 3. Zero space between group border and outer widget
> 4. May be more of them ...
I.e. I basically have to go through each preference page and menu, and each view. Then I have to find out, what was patched so that Adwaita doesn't look *that* bad, and then figure out how to deal with this in our product.
From my POV, it would be great if the discussion goes into direction "What can be done to make customizing easier?" and away from:
* "Everything is fine"
* "Everything is bad"
* "We need more feedback to justify customization"
As can be seen in e.g. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/gtk/org/eclipse/swt/internal/gtk/swtgtk_320.css there was significant effort to get to such "consistent" look. And whenever a good case is identified it will be treated as such. Unfortunately most custom themes I have seen are in so poor state that whatever works for one of them breaks another one entirely. Thus improving SWT on custom GTK themes usually requires work on both sides fixing SWT and fixing the theme and this needs to be done by the one wanting to use the given Gtk theme as the number of combinations is simply endless. With all that said - dedicated bugs/patches/descriptions are more than welcome with the clear understanding that if there is a bug in custom Gtk theme there isn't much SWT should or could do. (In reply to Simeon Andreev from comment #17) > From my POV, it would be great if the discussion goes into direction "What > can be done to make customizing easier?" My 2 cents: if you and your customers are really hung up on the look and feel of GTK3.22's Adwaita theme, then I'd advise you to create and maintain your own GTK theme that you can ship with your application. This might sound like a huge burden at first but it will allow you a lot more control and save you lots of trouble down the road. As Alex pointed out, it's not really SWT's place to allow theme customization as this defeats the purpose of SWT: to mimic the look of the OS as closely as possible. There are lots of resources to help you out, as custom GTK themes are a pretty common thing. You can even grab a relatively popular theme and tweak it to support your use cases. Yes it will be lots of work at first, but it's a one time cost as GTK3.22 API is now stable and not under development. IMO the burden to create the theme to begin with will be worth the troubles saved when debugging future issues. (In reply to Eric Williams from comment #19) > > My 2 cents: if you and your customers are really hung up on the look and > feel of GTK3.22's Adwaita theme, then I'd advise you to create and maintain > your own GTK theme that you can ship with your application. This is already what we do. The point of this ticket is that Eclipse will do a number of things which hinder custom themes. We then need to find out what this is, and work against it. Examples of this are: 1. Setting a minimum height for text fields on application level. 2. Setting height limit on toolbars. I even can't find where this is done. As far as I can tell, those are done to prevent Adwaita from looking like Adwaita. This is inconsiderate for other themes. (In reply to Simeon Andreev from comment #20) > (In reply to Eric Williams from comment #19) > > > > My 2 cents: if you and your customers are really hung up on the look and > > feel of GTK3.22's Adwaita theme, then I'd advise you to create and maintain > > your own GTK theme that you can ship with your application. > > This is already what we do. > > The point of this ticket is that Eclipse will do a number of things which > hinder custom themes. We then need to find out what this is, and work > against it. > > Examples of this are: > > 1. Setting a minimum height for text fields on application level. > 2. Setting height limit on toolbars. I even can't find where this is done. We have a little bit of gtk css in: "/org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/swtgtk_320.css" (for gtk3.20+) We then inject it into gtk in Device.java:init() { ~ gtk_css_provider_load_from_data(...read(swtgtk_320.css)); ~730. However, the css there is not intended to be a 'theme' of sort. It's a bit special, in that it resolves gtk specific problems like arrow-key navigation in trees. It does also trim the toolbar. But as a note thou, the css file is pretty minimal. The rest of the eclipse UI is constructed via gtk themes. It's intended to be as minimal as possible to make it easier to maintain. > As far as I can tell, those are done to prevent Adwaita from looking like Adwaita. > This is inconsiderate for other themes. Currently swt only shrinks the toolbar a little bit (basically ~7 properties are overridden), other than that everything else is left to the native theme. For a non-adwaita theme, these changes would also be applied, be it adwaita or Theme X (I think), so all themes are treated equal afaik. The point being is that SWT's CSS involvement is intended to be minimal and specific themes should be set by the OS theme. I.e, swt doesn't discriminate adwaita vs non adwaita themes, it just happens to work OK on adwaita. Do you still experience issues in your custom theme? Let me know if we can help further. btw, I wonder if this is the offending css:
swtgtk_320.css
entry {
min-height: 26px;
}
Do you have access to SWT development environment? are you able to make changes to the swtgtk_320.css and see those differences?
If not, let me know and I can make jar that you could inject into nightly eclipse and test it with your theme.
(In reply to Simeon Andreev from comment #20) > 1. Setting a minimum height for text fields on application level. This is done to prevent text entries from shrinking smaller than the cursor within them and clipping the text. The fact that this is done with CSS is due to GTK3.20+ allowing to use CSS for sizing, and this is the easiest way to go about it. It's not related to theming, and from my point of view removing this would be a bad idea. (In reply to Eric Williams from comment #23) > (In reply to Simeon Andreev from comment #20) > > 1. Setting a minimum height for text fields on application level. > > This is done to prevent text entries from shrinking smaller than the cursor > within them and clipping the text. The fact that this is done with CSS is > due to GTK3.20+ allowing to use CSS for sizing, and this is the easiest way > to go about it. It's not related to theming, and from my point of view > removing this would be a bad idea. imho we should test. @Simeon, are you able to make changes to SWT code and test them? I.e, I could make a little change and then see if that would improve your theme. Let me know. Btw, I'm around on irc freenode#swt (In reply to Leo Ufimtsev from comment #24) > @Simeon, are you able to make changes to SWT code and test them? > I.e, I could make a little change and then see if that would improve your > theme. > > Let me know. > > Btw, I'm around on irc freenode#swt Yes, I am able to change SWT sources. Unfortunately I don't have IRC. In a month I could install one, for now my work place does not permit one. (In reply to Eric Williams from comment #23) > (In reply to Simeon Andreev from comment #20) > > 1. Setting a minimum height for text fields on application level. > > This is done to prevent text entries from shrinking smaller than the cursor > within them and clipping the text. The fact that this is done with CSS is > due to GTK3.20+ allowing to use CSS for sizing, and this is the easiest way > to go about it. It's not related to theming, and from my point of view > removing this would be a bad idea. What you do *is* related to themes, since you set the css on application level (GTK_STYLE_PROVIDER_PRIORITY_APPLICATION). This overrides the theme (GTK_STYLE_PROVIDER_PRIORITY_THEME), hindering theme customizations (https://developer.gnome.org/gtk3/stable/GtkStyleProvider.html). Please check Comment #1. We don't want to remove what Eclipse does, we want to have an easier time when changing its behaviour. We use -Dorg.eclipse.swt.internal.gtk.cssFile to override contents of swtgtk_320.css. So since its possible to change the behaviour, this is not dramatic. However we must revert the contents of swtgtk_320.css with our own entries. In addition, often it takes time to understand whether a problem is coming from GTK, the theme, or Eclipse's swtgtk_320.css. I.e. it feels like we are fighting against Eclipse when changing the theme. In our case I believe it would be best to let the theme handle everything. I'm not sure how this fits with the existing code though. Another switch via an env variable is probably not the best way to go about it. I've whipped together a proof of concept that loads the swtcss_320 only if Adwaita theme is loaded: https://git.eclipse.org/r/#/c/117868/ I tried it with clearlooks-phenix & Ambiance (Ubuntu theme) on Gtk3.22/Gnome. Without the swtcss_320, these two themes have (slightly bubbly) but reasonably sized and quite usable toolbars. On the other hand without the fix, with the forced swtcss_320 clearlooks-phenix & Ambiance have tiny-toolbar icons making it hard to click on them (as seen in original screenshot). The conclusion that I draw based on tests is that swtcss_320 negatively affects non Adwaita themes on Gtk3.22. However, I observe that swtcss_* has functional fixes, e.g Tree-arrow navigation: @binding-set SWTTreeViewBinding { bind "Left" { "expand-collapse-cursor-row" (0,0,0)}; bind "Right" { "expand-collapse-cursor-row" (0,1,0)}; } As such, we do need to load **some** swtcss elements. I propose that moving forward we do as following: 1) Load swtgtk_css_core.css that contains fixes required for all themes. 2) Load swtgtk_css_THEME-NAME.css from /org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/.... (and we'd move Adwaita specific fixes into swtgtk_css_Adwaita.css) (maybe use same one for dark variant). 3) Merge css from 1 & 2 and apply them with gtk_css_provider_load_from_data() with GTK_STYLE_PROVIDER_PRIORITY_APPLICATION. For sake of maintainability, I suggest we only do this for Gtk3.20 and above. Leave pre-3.20 code as is because pre 3.20 CSS is different than 3.20 and above. The above would allow us to maintain functional Eclipse on Adwaita but allow custom themes to do their own thing. @Simeon/SWT folks, please provide feedback/thoughts. Created attachment 272787 [details]
LEO: Phonnix-clear looks. Left: without swtcss (normal toolbars), right: with swtcss (tiny toolbars issue).
(In reply to Leo Ufimtsev from comment #27) > The above would allow us to maintain functional Eclipse on Adwaita but allow > custom themes to do their own thing. I'm fine with this approach provided we only explicitly support Adwaita. I.e. I'm cool with logic like "if (Adwaita) load this file", but I do not think we should extend this logic to support custom themes (i.e. "if (custom theme) do y"). SWT should support the default GTK theme : if clients want to use a custom theme that's fine, but they are on their own from SWT's point of view. @Simeon, thoughts? (In reply to Leo Ufimtsev from comment #27) > 1) Load swtgtk_css_core.css that contains fixes required for all themes. > 2) Load swtgtk_css_THEME-NAME.css from /org.eclipse.swt/Eclipse SWT > PI/gtk/org/eclipse/swt/internal/gtk/.... > (and we'd move Adwaita specific fixes into swtgtk_css_Adwaita.css) > (maybe use same one for dark variant). > > 3) Merge css from 1 & 2 and apply them with > gtk_css_provider_load_from_data() with > GTK_STYLE_PROVIDER_PRIORITY_APPLICATION. > > For sake of maintainability, I suggest we only do this for Gtk3.20 and > above. Leave pre-3.20 code as is because pre 3.20 CSS is different than 3.20 > and above. (In reply to Leo Ufimtsev from comment #30) > @Simeon, thoughts? This sounds great! In the mean time I'm done with our theme for GTK 3.22. So I'm confident that the above is what we need. Let me know when you have a tentative patch with the above, I'll try it out. Hello Simeon, I've written a patch that only loads Adwaita fixes if underlying system theme is Adwaita: https://git.eclipse.org/r/#/c/120811/ Please kindly review & test and let me know if it addresses your issue. @ Other folks, if you're not using Adwaita, you should test this patch to make sure it doesn't break your theme. (e.g if you run a theme based off of Adwaita, it might impact you) (The fix can be adjusted to load adwaita fixes on non-adwaita themes too.) Thank you. Hi Leo, I'm checking the patch out, there are some unexpected CTabFolder / toolbar item sizes (they are too big). Must be coming from our side, I'll let you know once I have this out of the way. Best regards, Simeon All right, looks good.
I had to change some too-generous toolbar button paddings (set from ClearlooksPhenix theme). So far those paddings were overwritten by swtgtk_320.css.
Other than that, I am able to remove the -Dorg.eclipse.swt.internal.gtk.cssFile argument and all is still well.
I'm guessing the patch still needs to load the following:
@binding-set SWTTreeViewBinding {
bind "Left" { "expand-collapse-cursor-row" (0,0,0)};
bind "Right" { "expand-collapse-cursor-row" (0,1,0)};
}
treeview {
-gtk-key-bindings: SWTTreeViewBinding;
}
Thanks for the change, it makes the theme maintaining much easier!
(In reply to Simeon Andreev from comment #34) > All right, looks good. > > I had to change some too-generous toolbar button paddings (set from > ClearlooksPhenix theme). So far those paddings were overwritten by > swtgtk_320.css. I was having similar thoughts. I could move some of the toolbar fixes into the common css as it seems to apply to all themes on gtk. If this is the case, could you point out which CSS you think would benefit from moving into common? Btw, which fixes did you have to apply to your ClerLooksPhenix theme? > > Other than that, I am able to remove the > -Dorg.eclipse.swt.internal.gtk.cssFile argument and all is still well. > > I'm guessing the patch still needs to load the following: > > @binding-set SWTTreeViewBinding { > bind "Left" { "expand-collapse-cursor-row" (0,0,0)}; > bind "Right" { "expand-collapse-cursor-row" (0,1,0)}; > } > > treeview { > -gtk-key-bindings: SWTTreeViewBinding; > } > > Thanks for the change, it makes the theme maintaining much easier! Btw, the bot didn't link the patch properly. It was pointing to the P.O.C. The patch in question is this guy: https://git.eclipse.org/r/#/c/120811/ Please feel free to +1 it if you like. (In reply to Leo Ufimtsev from comment #35) > I could move some of the toolbar fixes into the common css as it seems to > apply to all themes on gtk. > If this is the case, could you point out which CSS you think would benefit > from moving into common? I'll check and will let you know tomorrow, for our theme I simply took its own entries and overwrote them with values that retain the current Eclipse look. > Btw, the bot didn't link the patch properly. It was pointing to the P.O.C. > The patch in question is this guy: > https://git.eclipse.org/r/#/c/120811/ I'll check this as well, didn't realize I was using the wrong patch. > Btw, which fixes did you have to apply to your ClerLooksPhenix theme? For the toolbar buttons being huge: toolbar.inline-toolbar button, toolbar.primary-toolbar button, toolbar.primary-toolbar button:active, toolbar.horizontal button, toolbar.horizontal button:active, toolbar toolbutton button, .titlebar .linked.raised button, .titlebar .linked.raised button:active { padding: 1px; } toolbar button, toolbar.primary-toolbar button, toolbar.horizontal button:hover, toolbar.horizontal button:active { padding: 1px; } For the rest of the patches, you can examine: https://github.com/iloveeclipse/clearlooks-phenix/tree/eclipse-patches/gtk-3.0/eclipse-patches We apply a second .css, theme-patches.css, on top of the theme. Otherwise it becomes difficult to keep track of our patches / keep the theme in sync with its authors repository. The above toolbar button entries will go in this file. The application-patches.css will become obsolete after this ticket is closed. It contains what we had to set with org.eclipse.swt.internal.gtk.cssFile. (In reply to Simeon Andreev from comment #37) > > Btw, the bot didn't link the patch properly. It was pointing to the P.O.C. > > The patch in question is this guy: > > https://git.eclipse.org/r/#/c/120811/ > > I'll check this as well, didn't realize I was using the wrong patch. Ok, let me know how it goes. Let me know if there is some CSS that you'd like to have in the 'common' css file. If it applies to Adwaita as well, we could potentially include them. (In reply to Leo Ufimtsev from comment #38) > Ok, let me know how it goes. Checked with https://git.eclipse.org/r/#/c/120811/, unsurprisingly same as Comment 34. Everything is well with a few additional toolbar button size restrictions. Note that if I take the Adwaita css contents to our theme, the toolbar is still huge. I don't really know how overriding with this .css on application level achieves more than adding the entries after the theme entries. Its also not very important, since changing the theme is straightforward. > Let me know if there is some CSS that you'd like to have in the 'common' css > file. If it applies to Adwaita as well, we could potentially include them. Personally I would omit any such entries: 1. The current patch still allows overriding theme settings on application level. I guess this could be more platform friendly (as Andrey requested), but it definitely works. If users (and not platform maintainers) are not happy with how Eclipse looks under their theme, they can e.g. use the Adwaita css as an example to override toolbar paddings. Its definitely not a fault in Eclipse when a theme is too ham-handed with padding/sizes (see Adwaita, to name one such theme). 2. If one GTK3 application does not look appropriate with the users theme of choice, my guess is all GTK3 applications would not look appropriate. Its not difficult to adjust the theme and e.g. for maintainers to provide the theme with the product environment. (In reply to Simeon Andreev from comment #39) > (In reply to Leo Ufimtsev from comment #38) > > Ok, let me know how it goes. > > Checked with https://git.eclipse.org/r/#/c/120811/, unsurprisingly same as > Comment 34. Everything is well with a few additional toolbar button size > restrictions. Ok. Sounds good. Awaiting for Eric to review the patch and then we can merge. Pending for review by community till Friday/next week. *** Bug 528862 has been marked as a duplicate of this bug. *** Fixed/merged. We appreciate that you took the time to point out this issue. I now hope that the IDE will look pleasant for you. Let me know if there's anything else we can do to make your eclipse experience even more pleasant. Thank you! Leo Please backport to Oxygen (4.7) if possible. (In reply to Alien Huker from comment #44) > Please backport to Oxygen (4.7) if possible. The last 4.7 release 4.7.3a is already done and there will be no future releases or build from this branch so backporting it is pointless. Please use Photon if you need this functionality. > The last 4.7 release 4.7.3a is already done and there will be no future releases or build from this branch so backporting it is pointless. Please use Photon if you need this functionality.
It's bad.
Maybe i better use version 4.6.
I don't have time every half a year to change platform.
Thanks for all.
(In reply to Alien Huker from comment #46) > > The last 4.7 release 4.7.3a is already done and there will be no future releases or build from this branch so backporting it is pointless. Please use Photon if you need this functionality. > > It's bad. > > Maybe i better use version 4.6. > I don't have time every half a year to change platform. > > Thanks for all. Please read https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15401.html . The release train is moving to single stream after Photon with release every 3 months. (In reply to Alien Huker from comment #46) > > The last 4.7 release 4.7.3a is already done and there will be no future releases or build from this branch so backporting it is pointless. Please use Photon if you need this functionality. > > It's bad. > > Maybe i better use version 4.6. > I don't have time every half a year to change platform. > > Thanks for all. Hello Alien, Yea, I understand it's time consuming to upgrade & migrate to a new platform. I've been there. I understand that the problem with such large upgrades is that workflow can break and it takes time to get everything to work again. To resolve the problem we are moving towards a 3 month cycle, that would focus on introducing many smaller changes, thus making it easier to to migrate and maintain an up-to date environment. I hope this will make it easier to keep up to date in the future! I need just stable version. http://download.eclipse.org/eclipse/downloads/ You “Stable Builds” sounds like beta. In “Latest Release” i see just 6 releases for 4.7 branch. And this version still "beta". It's very little for stable release. I have more than 52 projects in workspace and i don't wont to broke something. I spent a significant amount of time learning version 4.7, but I could not get a stable version for myself. I need working, not learning what broken and what not. And there is no long-term support version. For me it's not convenient:( P.S.: Sorry for off topic. (In reply to Alien Huker from comment #49) > I need just stable version. > > http://download.eclipse.org/eclipse/downloads/ > > You “Stable Builds” sounds like beta. > In “Latest Release” i see just 6 releases for 4.7 branch. > And this version still "beta". > It's very little for stable release. > > I have more than 52 projects in workspace and i don't wont to broke > something. > > I spent a significant amount of time learning version 4.7, > but I could not get a stable version for myself. > > I need working, not learning what broken and what not. > > And there is no long-term support version. > > For me it's not convenient:( > > P.S.: Sorry for off topic. Yea, the Gtk3 port was a bit of a roller coaster as Gtk3.0-Gtk3.20 had many breaking changes. But now Gtk3.22 is stable and gtk won't have any api breaking realeases in gtk3.* series anymore. But we've gone a long way. Eclipse works quite well with Gtk3.22 and now Webkit2 port is complete so there are no more crashes caused by webkit1. ~Life is good. My personal recommendation: I would suggest to wait until Eclipse 4.8 is released. It contains a lot of improvements. Then update your system to Gtk3.22 (as it's the stable Gtk3.* release) and upgrade to Eclipse 4.8. After that upgrade, you should be ok for a very long time and then from time to time just make little upgrades here and there. Please let us know if we can help further and thank you for sharing the issues that you experienced. We're trying our best to make it a more pleasant experience :-). I'm also around on IRC freenode#swt if you have some swt issues that you're experiencing or feel free to submit SWT bug reports with your issue and we can take a look. Thank you. Thank you very much for the change here! My 2 cents on the most recent topic: It took about an employee-year (mixed between my time and Andrey's) to upgrade from 3.8 to 4.7. I would say that roughly 2/3 of this time went into GTK3 induced problems (if not more). At some point we'll be filing a complaint at RHEL support due to this (though what RHEL can do is another matter). We really see no point in the API breakage between minor GTK releases; from a developer perspective, this is an absolute nightmare. Strictly speaking there are zero API breakages in 3.xx versions. Many of the issues came from SWT mixing concepts of GTK 2 and 3, in quite some cases even unnoticed. Another group of issues came from using css styling before it was really defined API (GTK 3.20) but it allowed to fix (workaround) a whole group of bugs. And there are genuine bugs in GTK of course. We would have been lucky if Eclipse moves at the pace of RHEL in terms of GTK support - the only supported GTK 3 version on RHEL now is 3.22 but in SWT there is still GTK 2.24 support and as much as it's ifdefed it doubles (at least) the time to investigate an issue as I end up in branches that are simply dead on the version I run while trying to map the code in my mind. The only way to have better SWT imho is actively reduce GTK versions supported - post Photon we should aim at 3.14 or even 3.18 as min. (In reply to Simeon Andreev from comment #51) > Thank you very much for the change here! > > > My 2 cents on the most recent topic: > > It took about an employee-year (mixed between my time and Andrey's) to > upgrade from 3.8 to 4.7. > > I would say that roughly 2/3 of this time went into GTK3 induced problems > (if not more). At some point we'll be filing a complaint at RHEL support due > to this (though what RHEL can do is another matter). We really see no point > in the API breakage between minor GTK releases; from a developer > perspective, this is an absolute nightmare. Yea, it's been a roller coaster. But it was important to go through these tricky things. If we wouldn't have, we'd face bigger issues down the road. For example webkit1 is now deprecated and isn't even being shipped with newer OS's anymore. But webkit2 is only available with Gtk3. So if we wouldn't have started with the Gtk3 port when we did (and only started when gtk3.22 was released), then we'd be in a place where we'd be without a Browser widget and we wouldn't have had enough time to do gtk3 port + webkit port in one go. I.e, in an ideal world, we would only develop on stable versions. In real life, we have to work with upstream and maintain current otherwise we fall behind the band wagon. I guess this change make the dark theme under Ubuntu worse. Selected buttons are now very light. See https://ibb.co/cq6Mgn. And if I open a dialog I have very big light buttons. https://ibb.co/c8UeZ7 Both bugs were present before (a little bit light) but Build id: I20180419-2000 were are very much amplified. Leo, could you have a look and restore the old state (or even better not making these button light at all). (In reply to Lars Vogel from comment #54) > I guess this change make the dark theme under Ubuntu worse. Selected buttons > are now very light. See https://ibb.co/cq6Mgn. > > And if I open a dialog I have very big light buttons. https://ibb.co/c8UeZ7 > > Both bugs were present before (a little bit light) but Build id: > I20180419-2000 were are very much amplified. > > Leo, could you have a look and restore the old state (or even better not > making these button light at all). Could you attach a screenshot of what it used to look like before? I haven't investigated too deeply yet, but one option would be - to a few fixes to Ambiance theme (as we do for Adwaita) - or the other see if these fixes are common to all themes and apply them there. (In reply to Leo Ufimtsev from comment #55) > I haven't investigated too deeply yet, but one option would be > - to a few fixes to Ambiance theme (as we do for Adwaita) > - or the other see if these fixes are common to all themes and apply them > there. Or maybe just provide an "A-to-Z maintainer flag" instead of using the theme name as a switch. I.e. let platform maintainers decide if they want the theme patched by Eclipse or not; per default patch it. Should be minimal change from current state and is sufficient for us. (In reply to Leo Ufimtsev from comment #55) > (In reply to Lars Vogel from comment #54) > > I guess this change make the dark theme under Ubuntu worse. Selected buttons > > are now very light. See https://ibb.co/cq6Mgn. > > > > And if I open a dialog I have very big light buttons. https://ibb.co/c8UeZ7 > > > > Both bugs were present before (a little bit light) but Build id: > > I20180419-2000 were are very much amplified. > > > > Leo, could you have a look and restore the old state (or even better not > > making these button light at all). > > Could you attach a screenshot of what it used to look like before? > > I haven't investigated too deeply yet, but one option would be > - to a few fixes to Ambiance theme (as we do for Adwaita) > - or the other see if these fixes are common to all themes and apply them > there. (In reply to Lars Vogel from comment #54) > I guess this change make the dark theme under Ubuntu worse. Selected buttons > are now very light. See https://ibb.co/cq6Mgn. > > And if I open a dialog I have very big light buttons. https://ibb.co/c8UeZ7 > > Both bugs were present before (a little bit light) but Build id: > I20180419-2000 were are very much amplified. > > Leo, could you have a look and restore the old state (or even better not > making these button light at all). Is the issue the size or the color of the buttons? If it's the color then I don't think this ticket is responsible, as none of the changes involved colors -- only sizing. (In reply to Simeon Andreev from comment #56) > (In reply to Leo Ufimtsev from comment #55) > > I haven't investigated too deeply yet, but one option would be > > - to a few fixes to Ambiance theme (as we do for Adwaita) > > - or the other see if these fixes are common to all themes and apply them > > there. > > Or maybe just provide an "A-to-Z maintainer flag" instead of using the theme > name as a switch. I.e. let platform maintainers decide if they want the > theme patched by Eclipse or not; per default patch it. > > Should be minimal change from current state and is sufficient for us. +1 from me. Doing checks for theme names and such is going to get very messy very quickly. The only maintainable solution in the long term is to have a binary yes/no system, i.e.: supporting only two themes (the default Adwaita, and disabling SWT theme support all together). (In reply to Eric Williams from comment #57) > Is the issue the size or the color of the buttons? If it's the color then I > don't think this ticket is responsible, as none of the changes involved > colors -- only sizing. The button used to turn white but the white area was very small. So while annoying I was able to visually ignore them which is not possible anymore with the new large white buttons. Leo/Eric: See https://ibb.co/dbqycS for the old look. While annoyong it was not unsuable (for me) like it it now. (In reply to Lars Vogel from comment #58) > (In reply to Eric Williams from comment #57) > > > Is the issue the size or the color of the buttons? If it's the color then I > > don't think this ticket is responsible, as none of the changes involved > > colors -- only sizing. > > The button used to turn white but the white area was very small. So while > annoying I was able to visually ignore them which is not possible anymore > with the new large white buttons. > > Leo/Eric: See https://ibb.co/dbqycS for the old look. While annoyong it was > not unsuable (for me) like it it now. Okay, so the buttons were white before but now they have padding, which is white as well. So overall the buttons are bigger and whiter. In this case I am still in favour of Simeon's proposal. (In reply to Eric Williams from comment #59) > Okay, so the buttons were white before but now they have padding, which is > white as well. So overall the buttons are bigger and whiter. Correct, see Comment 54 ----------- I guess this change make the dark theme under Ubuntu worse. Selected buttons are now very light.[SNIP] Both bugs were present before (a little bit light) but [SNIP] they are very much amplified. ----------- (In reply to Eric Williams from comment #59) > In this case I am still in favour of Simeon's proposal. +1, in general the buttons look to big now on Ubuntu. Would be nice, if that fix would be an opt-in. (In reply to Lars Vogel from comment #61) > (In reply to Eric Williams from comment #59) > > In this case I am still in favour of Simeon's proposal. > > +1, in general the buttons look to big now on Ubuntu. Would be nice, if that > fix would be an opt-in. Ok, if I understand correctly Simon/Eric/Lars agree to have theme fixes enabled by default, but permit a platform flag to disable them. I'll whip together a patch for this in a bit. I think it should be vice versa, platform specific fixes should be deactivated by default. (In reply to Lars Vogel from comment #63) > I think it should be vice versa, platform specific fixes should be > deactivated by default. That would break SWT on Adwaita/gnome for most users unless they specify the fix, including your ubuntu setup unless you specify the flag. (In reply to Leo Ufimtsev from comment #64) > That would break SWT on Adwaita/gnome for most users unless they specify the > fix, including your ubuntu setup unless you specify the flag. Can you clarifiy why Ubuntu would break by this change? After the changes of this bug Ubuntu buttons looks IMHO worse then before (unnecessary big in light and dark theme plus the now extremly visible white artifacts in the dark theme). (In reply to Lars Vogel from comment #65) > (In reply to Leo Ufimtsev from comment #64) > > > That would break SWT on Adwaita/gnome for most users unless they specify the > > fix, including your ubuntu setup unless you specify the flag. > > Can you clarifiy why Ubuntu would break by this change? After the changes of > this bug Ubuntu buttons looks IMHO worse then before (unnecessary big in > light and dark theme plus the now extremly visible white artifacts in the > dark theme). I think there's some confusing going on. But I understand what you're looking for. I think it's easier if I just whip together a quick patch and have you guys test/veriy it. Code can speak for itself :-). But first I need to get my coffee. New Gerrit change created: https://git.eclipse.org/r/121751 Dear fellow and respected citizens of the great Eclipse civilization, Please review and leave your feedback on this patch: https://git.eclipse.org/r/#/c/121751/ Please +1/-1 the patch and let us know if this resolves your problem(s). (from technical point of view, it's very easy to update the patch to match people's requirements, just let me know what works for you). Thank you Will check the patch latest tomorrow, thanks! OK, I checked behaviour with the patch, its as expected: 1. Using -Dorg.eclipse.swt.internal.gtk.cssFile=..., no new flag, everything is well. 2. Not using -Dorg.eclipse.swt.internal.gtk.cssFile, no new flag, combo editors are bloated, main toolbar is somewhat longer. 3. Not using -Dorg.eclipse.swt.internal.gtk.cssFile, using new flag -Dorg.eclipse.swt.internal.gtk.noThemingFixes, everything is well. I checked only on RHEL 7.4 (GTK 3.22.10), since on RHEL 7.2 (GTK 3.14.13) SWT had no invasive theme changes on application level. (In reply to Simeon Andreev from comment #70) > OK, I checked behaviour with the patch, its as expected: > > 1. Using -Dorg.eclipse.swt.internal.gtk.cssFile=..., no new flag, everything > is well. > 2. Not using -Dorg.eclipse.swt.internal.gtk.cssFile, no new flag, combo > editors are bloated, main toolbar is somewhat longer. > 3. Not using -Dorg.eclipse.swt.internal.gtk.cssFile, using new flag > -Dorg.eclipse.swt.internal.gtk.noThemingFixes, everything is well. > > I checked only on RHEL 7.4 (GTK 3.22.10), since on RHEL 7.2 (GTK 3.14.13) > SWT had no invasive theme changes on application level. Thank you for feedback. Awaiting feedback from Lars & Eric. Gerrit change https://git.eclipse.org/r/121751 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=886e6c5bac16f14c66405e5d72874a39c632835e Merged. @Lars, for all practical purposes, the theming now behaves similar to the way it did before (loaded by default), except now you can disable theming fixes with special flag: -Dorg.eclipse.swt.internal.gtk.noThemingFixes So your Ubuntu should work as before now. If there are still issues with Monday's IBuild, then please re-open the bug. Thank you. Thanks Leo, sorry for not being able to test it before the merge but this week Im working for a customer. I test next week. (In reply to Lars Vogel from comment #74) > Thanks Leo, sorry for not being able to test it before the merge but this > week Im working for a customer. I test next week. Sorry for breaking things ^_^. Thanks for finding & reporting issue, much appreciated. (In reply to Lars Vogel from comment #74) > Thanks Leo, sorry for not being able to test it before the merge but this > week Im working for a customer. I test next week. Looks good now. Thanks |
Created attachment 271630 [details] Eclipse under GTK 3.22 with non-Adwaita theme While moving from RHEL 7.2 (gtk3-3.14) to RHEL 7.4 (gtk3-3.22) we observed that the IDE looks rather unpleasant. See the attached screenshot "clearlooks-phenix-7-theme.png". The issues are as follows. 1. Text fields are HUGE. This seems to be due to Adwaita defining a minimum height for even more huge text fields. The min height is set to 26px in org.eclipse.swt.graphics.Device via a css file. This is unnecessarily punishing to users with normal, non-elephantine themes. 2. Padding for toolbar buttons is set to 0, resulting in cramped toolbars. Again due to Adwaita, where setting the padding to 0 seems to yield OK results. Large text boxes and small toolbars combined make the IDE feel awkward. For the toolbar buttons, we were able to set a min-width. While this is questionable, we can live with it. For the text boxes, we can only set the variable org.eclipse.swt.internal.gtk.cssFile to a css file which overwrites what Eclipse sets. This is definitely better than nothing, but far from ideal. It would be great if one of the following could be provided: 1. Adjust the custom css for gtk 3.20+ in a less invasive way to other themes. 2. Provide a platform-developer-friendly way of adjusting said css. E.g. a fragment that we could contribute to, to patch said adjustments in our application. Theme: Clearlook-Phenix 7.0.1 (with some adjustments) OS: Red Hat Enterprise Linux Workstation release 7.4 (Maipo) gtk3-3.22.10-4.el7.x86_64 Eclipse: Eclipse SDK Version: Photon (4.8) Build id: I20170802-2000 Can also be seen on 4.7: Eclipse SDK Version: Oxygen (4.7) Build id: I20170612-0950