Tuesday, May 6, 2014

Eclipse and Dark theme shortcomings

Well, last year, after having support to go on with LiClipse, I set out to having a Dark Theme in Eclipse given the new themeing capabilities of e4.

After some work, LiClipse (http://brainwy.github.io/liclipse) was released, and I'm pretty positive that it's currently the best possible experience with a dark theme on Eclipse (i.e.: through some adaptations to Eclipse Color Theme, the same UI is used to change editors as well as views and other decorations -- I went as far as creating new versions of some icons so that they work on the dark theme, added custom painters for trees and tables, etc).


There are some shortcomings when it comes to a dark theme in Eclipse which are not addressable from a plugin:

- It's not possible to style links: they always follow the platform settings (so, they can become unreadable inside Eclipse on a dark theme).

- Scrollbars are not themeable, thus, they stand out too much in a dark theme and things look ugly (IMHO).

- Tooltips can't be themed either (so when hovering the tooltip still has the background color from the OS).

Also, I'm not happy with some hacks I had to do:

- I had to add a custom painter to the tree so that it shows the expand/collapse decorations using a proper foreground color as the one from the system usually is unusable.

- The tree custom painter also erases the selection and redraws it as it's not possible to customize the selection color of the tree.

- For the table I also had to resort to a custom painter, but the situation is a bit worse than with the tree painter as it's not possible to customize the selection color when it doesn't have focus.

Note that those are the nastier I remember (and for which I created bugs in Eclipse itself).

Now, most of these issues only appear if you're using an OS that's not dark-themed, so, in Ubuntu which ships with a default dark theme, things may look nicer than on Windows -- where scrollbars aren't even customizable, so, it's always ugly (and it seems windows 8 trimmed many of its options, so, some things aren't even customizable anymore).

I bet no one will change the OS for that, so, it's either living with ugly scrollbars in a dark theme in Eclipse, choosing a different IDE or using a light theme, which is a bit lame: many UI toolkits such as Qt or JavaFX (and even swing) do a fine work on customizing the application look and feel, which takes me to the next point:

Most things are shortcomings in SWT, but it seems as SWT is not moving forward... Or maybe it is but not in those directions (which is a bit weird since it appeared as that was the most important point of going to e4)?

I saw some work on using SWT on top of JavaFX too (although it's probably a big effort migrating Eclipse to it)...

It seems like the Eclipse community should have decided where it's going at this point, so, can someone shed some light here? It seems like fixing those in SWT wouldn't be that hard -- but then again it needs development time from someone close to SWT...

Per request, I'm adding the issues I created on Eclipse:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=414080 (table selection foreground without focus)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401015 (style links)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434201 (respect foreground for tree item arrows)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=430278 (style scrollbars)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401227 (toolitem foreground)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401015 (style hyperlinks)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434309 (style tree/table selection)


  1. Can you add the bug numbers for these feature requests to this blog entry?

    1. Are all of these issues Windows only? I ask because I monitor ALL/Linux*/Unix all aka generic and GTK specific issues so proper categorization in projects like SWT really matter. If some of them are generic please move them to All to not stay hidden for people like me.

    2. I think that they're all are Linux/Windows related (as they're mostly shortcomings on the SWT api) -- although it's possible that some things affect more one platform than the other (i.e.: scroolbars on windows on dark themes are really hideous, but you can't theme scroolbars on Linux either, although they're usually nicer by default -- but that also probably depends on the window manager you're using).

      I'll double check and categorize the platform properly.

    3. Can you try switching to dark gtk theme on Linux? This should fix the issue with scrollbars(and others) on Linux and I can even think of adding a call to set gtk-application-prefer-dark-theme GSetting so platform theme engine can switch it on/off when changing themes.

  2. With my SWT hat on I do really believe in SWT being a "thin" wrapper around OS UI library. Trying to rewrite system components(like scrollbars on windows) in SWT is impossible with current resources.
    Also as you mentioned proper OS has support for dark themes built-in spending time on such issues for people on such OS is wasting time.
    The whole e4 work haven't ended up in SWT improvements at all as far as I have seen.
    Regarding development time from someone close to SWT the few involved have our hands full for years ahead so new blood is needed - aka I'm waiting for community being proven to exist ;) .

    1. Hi Alex :)

      Regarding the comment on proper OS, I must say I only agree partially with you... the fact that I have to customize the OS to change something in Eclipse even on Linux based systems is also a pain IMHO (and a common one too).

      I get that the design decisions done many years ago on how SWT should work may prove such a burden now that the only possible solution is moving to something different, but I wanted to know if this decision was taken already or not.

      I.e.: Is there some technical group which would take up on this decision? How was e4 decided for instance?

      Sure, I get that we're going nowhere if no one steps in to do the job, but it'd be nice to know if there's something agreed upon in that area so that plugins based on Eclipse know what to expect...

      Personally, I like Toms idea of using JavaFX (although that might need an Eclipse 5), but if that decision will be made, it may need other measures than just waiting for Tom to do the Job in a separate repo... if there was a technical agreement upon core devs that that's what Eclipse 5 will be, it would surely move on forward faster (personally, I wouldn't even start looking at it if I'm not sure it will be integrated -- I've worked on trivial things which take ages to be integrated -- something as big as that has close to zero chance of being integrated if it's not technically agreed upon and there's not at least one Eclipse committer overseeing it).

  3. I could not agree more and like Alex said I think SWT is not supposed to be themeable indefinately - hence if you need themeing you need to reside to something like JavaFX, Swing, Qt - I've been working on SWT on JavaFX since some time and without others helping in the effort I think is going nowhere.

    1. Hi Tom,

      I must say I really like your idea... See the other comment I posted to Alex :)