Eclipse is suffering from white on white and dark on dark problem with Breeze Dark theme. Are there any better themes for Eclipse to use with Breeze Dark?

Can you file a bug on bugs.kde.org?

einar wrote:Can you file a bug on bugs.kde.org?

Eclipse Juno is a GTK2 application and an older version (curse of enterprise development). Kepler also has the same problem. I can try Luna which is the latest version and I heard it has a black theme. I will file a bug if the problem persists with Luna too.

personal experience: gtk requires dark on bright. esp. gtk+2 is full of widgets w/ hardcoded foreground. and i assume eclipse is java, so even rather awt -> gtk?

luebking wrote:personal experience: gtk requires dark on bright. esp. gtk+2 is full of widgets w/ hardcoded foreground. and i assume eclipse is java, so even rather awt -> gtk?

A lot of Qt/KDE 4 applications are also using their own color settings KMail comes to mind. These applications are yet not ready for Breeze Dark.

Afair the color in kmail are not hardcoded?
(And indeed, they should also include the background color, of course)

luebking wrote:Afair the color in kmail are not hardcoded?
(And indeed, they should also include the background color, of course)

It is not but they don't have a matching color theme to Breeze Dark. When you switch to Breeze Dark you are presented with extreme shades on black, blue and white which hurts your eyes and is not asthetically pleasing. It should become mandatory for each application to think about how its going to look in Breeze Dark.

It should become mandatory for each application to think about how its going to look in Breeze Dark.

Yes, is. In "shouldworld".
You're not telling this is your first encounter of a "bright on dark" failure?
As long as you can choose usable colors, it's no problem if they do not magically adjust to the system color scheme
I mean, what do you expect? If you select a color scheme named "breeze dark" kmail/kate/nameone detects that and *enforces* some internal "breeze dark compatible" theme?
And what if you prefer "my local better dark"? Automagic would be immediately broken.

luebking wrote:

It should become mandatory for each application to think about how its going to look in Breeze Dark.

Yes, is. In "shouldworld".
You're not telling this is your first encounter of a "bright on dark" failure?
As long as you can choose usable colors, it's no problem if they do not magically adjust to the system color scheme
I mean, what do you expect? If you select a color scheme named "breeze dark" kmail/kate/nameone detects that and *enforces* some internal "breeze dark compatible" theme?
And what if you prefer "my local better dark"? Automagic would be immediately broken.

You are unnecessary trying to stir up an argument even though you very well know that applications would have to respond to official dark theme. Just because I wrote a sentence doesn't mean it becomes the 11th commandment that you must obey word by word. It's only meant as we PLEASE need a dark theme for each and every application. A color palette which is very common in KDE 4 apps is not so user friendly.

No, I'm not and you're apparently missing the point.

Applications that require colors beyond the global scheme resp. want to support such need to ensure *internal* integrity, ie. if you selected a dark on bright scheme that has to work despite the global scheme is bright on dark, yes. Absolutely. Kate does, kmail did last time i tried (what's however some time ago)
Also, I'm quite sure kate and kmail will ship with breezyfied schemes once ported to KF5.

But there's no point in trying to adapt your extended scheme to the global scheme, because that would imply that you "know better" than the user.

And overmore, this has nothing to do with the Ecplise situation:
It's not only broken in the area you can likely impact by a local color scheme (text editor, which is simply not integer - it should have a defined background color as well) but even in the "normal" GUI parts, where (unlike in the texteditor) it invokes the schemes foreground color, but (unlike in the texteditor) not the background color.

What I tried to tell you is that you can expect this behavior from many gtk+ applications, esp those which use gtk+ indirectly (java, xul, etc.) - and it won't fix ("in general")
It's a misconception in the gtk widget design, if not even inherent to gobject. The result is that they only work with dark on bright colors (because devs didn't care about anything else)
A "colorscheme" won't fix that.
And there are many for eclipse available (notably bright on dark):
http://eclipsecolorthemes.org/
But they will *only* "fix" the texteditor.

The solution to this is to file a bugreport against eclipse "Doesn't woth with bright on dark colorschemes"