Created attachment 686209 [details] that's how it looks Description of problem: when debugging a C++ program, one can inspect variables in the source view by hovering the cursor over the var name, and a window pops up. the text in this window is now mostly black-on-black and unreadable in Fedora 18, while it was readable last week in Fedora 17. maybe some Gnome theme changed or something. Version-Release number of selected component (if applicable): eclipse-ptp-rdt-sync-6.0.0-0.2.junom6.fc18.noarch eclipse-pde-4.2.2-0.1.git20121217.fc18.x86_64 icu4j-eclipse-4.4.2.2-12.fc18.noarch eclipse-dtp-1.10-2.fc18.noarch eclipse-ptp-6.0.0-0.2.junom6.fc18.noarch eclipse-ptp-rdt-xlc-6.0.0-0.2.junom6.fc18.noarch eclipse-birt-chart-4.2.1-1.fc18.noarch eclipse-jdt-4.2.2-0.1.git20121217.fc18.x86_64 eclipse-ptp-rdt-6.0.0-0.2.junom6.fc18.noarch eclipse-jgit-2.2.0-1.fc18.noarch eclipse-swt-4.2.2-0.1.git20121217.fc18.x86_64 eclipse-emf-core-2.8.1-6.fc18.noarch eclipse-cdt-parsers-8.1.1-1.fc18.x86_64 eclipse-cdt-8.1.1-1.fc18.x86_64 eclipse-valgrind-1.2.0-1.fc18.noarch eclipse-equinox-osgi-4.2.2-0.1.git20121217.fc18.x86_64 eclipse-platform-4.2.2-0.1.git20121217.fc18.x86_64 eclipse-rse-3.4-3.fc18.noarch eclipse-linuxtools-1.2.0-1.fc18.noarch eclipse-gef-3.8.0-2.fc18.noarch eclipse-ecf-core-3.5.6-3.fc18.noarch eclipse-emf-2.8.1-6.fc18.noarch gtk2-engines-2.20.2-5.fc18.x86_64 adwaita-gtk2-theme-3.6.2-1.fc18.x86_64 gtk2-2.24.13-1.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. debug some program 2. inspect some variable in the source view 3. window pops up that is mostly unreadable with black-on-almost-black text Additional info: i believe i've reproduced this with empty $HOME so it's not some user setting (machine was upgraded from F17)
(In reply to comment #0) > Created attachment 686209 [details] > that's how it looks > > Description of problem: > > when debugging a C++ program, one can inspect variables in > the source view by hovering the cursor over the var name, > and a window pops up. > the text in this window is now mostly black-on-black and > unreadable in Fedora 18, while it was readable last week in > Fedora 17. > > > How reproducible: > always > > Steps to Reproduce: > 1. debug some program > 2. inspect some variable in the source view > 3. window pops up that is mostly unreadable with black-on-almost-black text > > Additional info: > i believe i've reproduced this with empty $HOME so it's not some user setting > (machine was upgraded from F17) Reproduced both with F18 Eclipse and upstream Eclipse on F18 so it isn't a Fedora build issue. Still looking into it.
it was suggested to me to ask Cosimo about changes done to GTK+/Gnome themes which could have caused this bug; does this look like a bug in Eclipse or in themes?
(In reply to comment #2) > it was suggested to me to ask Cosimo about changes done to GTK+/Gnome themes > which could have caused this bug; does this look like a bug in Eclipse or in > themes? It would appear to be themes as the same upstream Eclipse works fine in F17. The background is supposed to be shades of blue.
I recently pushed some fixes to the GTK2 theme specifically to address some issues with Eclipse, but they haven't been backported to F18 yet. I'll test if those also fix this issue and report back.
(In reply to comment #4) > I recently pushed some fixes to the GTK2 theme specifically to address some > issues with Eclipse, but they haven't been backported to F18 yet. > I'll test if those also fix this issue and report back. I believe I have tracked the problem. The actual issue is that the SWT Tree widget can't handle a dark bg, light fg. The CDT, for example, uses hover help to display class info in the Debugger view and uses a Tree to display the class elements. It properly tells the SWT Tree the foreground and background colours which it gets from the system, however, the Tree appears to use individual TreeItems to get the colour of the text displayed. Since they are defaulted to black text, the text is unreadable unless an item is selected whereby the Tree sets up special colouring. In theory, one could fix this by setting the element colours as they are added to the Tree from the parent. A better alternative would be to have the Tree somehow handle this automatically for its elements since such a fix could be pervasive over many components. Yet another alternative would be for Eclipse to have preference settings for this that can override the system settings. I am opening a bug upstream to see what can be done about it. Regardless, the GA for Juno SR2 is Feb 22nd and it is already shipped an RC2. While it can be fixed any time in Fedora Eclipse, this won't solve the problem for end-users who choose to download Eclipse from upstream. In addition, there are some colour defaults such as purple hyper-links that are next to impossible to read as well. It would be much easier if the default f18 Adwaita settings did not attempt to make such a drastic change to tooltip colours. This would give time to handle this properly within Eclipse.
I have added a dependency on bug: https://bugzilla.redhat.com/show_bug.cgi?id=906556 Thanks to Cosimo who has replied that a fix to the themes is forth-coming and has verified the hover shows up readable.
Is this bug still reproducible ?
cannot reproduce the bug any more on current Fedora 19 or Fedora 18.