Version: (using KDE 4.3.1) Installed from: Ubuntu Packages I experience a visibility problem with inverted color schemes in the transfer details. I think it's best illustrated by the attached screenshot. AFAICS the solution is for KGet to set the foreground color to: App::instance()->palette().windowText().color() But I'll try to explain: A part of the problem is due to the partly inverted color scheme I use. This means I set a dark window background with a light window foreground, however a light view background with a dark view foreground. What now often happens is that apps explicitly set a background color, but use the default foreground color. So e.g. in a view type widget they explicitly use window background (in my case dark), combined with the default view foreground color (in my case dark, too). The result is you can't recognize anything. So if the background is set explicitly, the foreground should be as well. In this particular case the situation is made even worse by the Bespin widget style. With Oxygen and the same color scheme, the transfer details are painted with window background, but heavily shaded with the selection color, which makes it sufficiently light in the end. So the dark view foreground is still readable. However thinking about it... when I use a dark selection color, it's hard to read with Oxygen as well... So a fix is needed in anycase.
Created attachment 37474 [details] Inverted colors problem
Sorry for not answering for so long. I looked at the source and either I overlooked something or I don't really understand what you mean, because at the unreadable parts I don't see us changing any color. So I am not sure, if this is connected to KExtendableItemDelegate that is used here. Unfortunately I don't know which other programs use KExtendableItemDelegate so that you could test those, if they have the same problem.
Is this still valid with version 2.8.0 or later?
Yep, still valid
Created attachment 72026 [details] Inverted color scheme with Oxygen Attached a screenshot with Oxygen theme. Now imagine the selection color to be dark grey instead of blue, and you won't be able to read any of the dark texts (speed, remaining time, etc). Btw. perhaps in this case the text color shouldn't be windowText, but rather selection foreground.
Okay, setting back to NEW... Lukas
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.