Bug 315061

Created attachment 77250 [details]
Places panel with color role test color scheme

Created attachment 77251 [details]
Places panel with openSUSE 12.3 colors

Created attachment 77252 [details]
openSUSE 12.3 default color scheme

Adding Will Stephenson to CC who supplied me with the color scheme file.

Actually, this also affects the main file view (at least in icon mode).

The main view also has another problem in List mode: The alternate row color doesn't immediately update with color scheme changes, only after causing a repaint.

Responding to color scheme changes tends to be forgotten sadly ... runner up: responding to icon theme changes.

Thanks for the bug report and for the analysis! If I understand you correctly, all we have to do is use KColorScheme to determine the colors everywhere where painting is done?

KColorScheme's the way to get at the correct colors, but whenever one stores a color derived/taken from the scheme for later use (and calling setPalette() with a modified palette means "storing for later use" in a way) one also has to make sure to react to the KGlobalSettings::appearanceChanged() signal to update the cached color. In the Okular example that wasn't necessary because appearanceChanged() already causes a repaint to happen and the code in question was a list view delegate which takes the colors from the scheme on every paint instead of caching them somewhere, and the same might be true for the affected Dolphin code, haven't checked.

Thanks for the quick reply. So it's mostly clear how to fix this. I can't make any promises regarding a schedule though - I spend hardly any time in front of my development machine nowadays and have a couple of items on the TODO list already. If anyone else reads this and feels like working on it, please go ahead.

Just for the record, Albert remarked that creating a KColorScheme every time paint() is called might be too expensive:

http://lists.kde.org/?l=kde-commits&m=136079574606134&w=2

Yup, and here's a patch pending review that moves KColorScheme instanciation out of the paint path: http://git.reviewboard.kde.org/r/108958/

Note that it is not required to use KColorScheme here. Reacting to Qt's PaletteChanged events is sufficient to fix this.

*** Bug 323917 has been marked as a duplicate of this bug. ***

Created attachment 82481 [details]
before restart

Created attachment 82482 [details]
after restart

having same issue. in attachments - dolphin before its restart and after.

kde 4.11.1, fedora 20

Review-Request: https://git.reviewboard.kde.org/r/115958/

Git commit f40b80a960de8a2db6110b6fa14db2d7182ad6c3 by Emmanuel Pescosta.
Committed on 24/02/2014 at 13:17.
Pushed by emmanuelp into branch 'master'.

Handle font and palette changes in Dolphin list views.

Also update the font of the meta data widget in InformationPanelContent (smallest readable font).
Related: bug 329186
FIXED-IN: 4.13
REVIEW: 115958

M  +37   -4    dolphin/src/kitemviews/kitemlistview.cpp
M  +3    -0    dolphin/src/kitemviews/kitemlistview.h
M  +4    -0    dolphin/src/panels/information/informationpanelcontent.cpp
M  +20   -17   dolphin/src/views/dolphinitemlistview.cpp
M  +2    -1    dolphin/src/views/dolphinitemlistview.h

http://commits.kde.org/kde-baseapps/f40b80a960de8a2db6110b6fa14db2d7182ad6c3

Emmanuel, thanks a lot for your work. I'm already enjoying it. :-)

Hmm, I noticed that the color change only applies successfully until the tab is changed, ie. when you have only one tab open you have to open a new tab.

Can this be improved?

(In reply to comment #20)
> Hmm, I noticed that the color change only applies successfully until the tab
> is changed, ie. when you have only one tab open you have to open a new tab.
> 
> Can this be improved?

I'm not entirely sure if I understand exactly what you mean, but since this seems to be different from the original problem, can you file a new bug report and provide detailed steps to reproduce?

Created attachment 86599 [details]
Screencast of said problem

(In reply to comment #21)
> I'm not entirely sure if I understand exactly what you mean, but since this
> seems to be different from the original problem, can you file a new bug
> report and provide detailed steps to reproduce?
> 
It is the same issue, see attached screencast.

Thanks for the update and the screencast.

(In reply to comment #22)
> Created attachment 86599 [details]
> Screencast of said problem
> 
> (In reply to comment #21)
> > I'm not entirely sure if I understand exactly what you mean, but since this
> > seems to be different from the original problem, can you file a new bug
> > report and provide detailed steps to reproduce?
> > 
> It is the same issue, see attached screencast.

Even though the symptoms look similar to you, it is not exactly the same issue if I'm not mistaken. The original bug report was about Dolphin not updating the colors at all. The problem that you mention is only about the alternating row colors if I understand correctly (might be related to bug 334180 but since that one is about inactive window color effects, the root cause might be different).

I would appreciate it if you could file a new bug report (unless you think that it's the same as bug 334180) - even though recycling "fixed" reports for new problems or different variations of the old problem may look easier at first sight, this approach tends to turn bug reports into a big unreadable mess.

Thanks for your help.

*** Bug 334697 has been marked as a duplicate of this bug. ***

(In reply to comment #22)
> Even though the symptoms look similar to you, it is not exactly the same
> issue if I'm not mistaken. The original bug report was about Dolphin not
> updating the colors at all. The problem that you mention is only about the
> alternating row colors if I understand correctly (might be related to bug
> 334180 but since that one is about inactive window color effects, the root
> cause might be different).
> 
> I would appreciate it if you could file a new bug report (unless you think
> that it's the same as bug 334180) - even though recycling "fixed" reports
> for new problems or different variations of the old problem may look easier
> at first sight, this approach tends to turn bug reports into a big
> unreadable mess.
> 
> Thanks for your help.

Ok, I filled now bug 335175.