Bug 325736 - Disabling "Apply colors to non-KDE4 applications" does not work
Summary: Disabling "Apply colors to non-KDE4 applications" does not work
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: krdb (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-07 10:44 UTC by Martin Sandsmark
Modified: 2019-08-19 10:56 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Attachments
patch (474 bytes, patch)
2014-06-05 11:49 UTC, Martin Sandsmark 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Sandsmark 2013-10-07 10:44:19 UTC 
By default KDE synchronises its color scheme with Xresources, leading to for example uxterm getting the default white background.

Unchecking that checkbox does not disable this (even after a reboot).

Reproducible: Always
Comment 1 Kenny D 2013-10-07 11:15:36 UTC 
i have the same results with kubuntu raring and 4.11.2 packages
Comment 2 Oscar Fuentes 2014-05-19 17:56:28 UTC 
I'm seeing the bug in Kubuntu 14.04 (KDE 4.13.0) Renders some non-KDE applications unusable.
Comment 3 Martin Sandsmark 2014-06-05 11:49:56 UTC 
Created attachment 87024 [details]
patch

if someone could test the attached patch it would be great.
Comment 4 Franz Trischberger 2015-02-10 21:14:29 UTC 
I had this issue, but with plasma-5.2.0.
Turned out to be a shortcoming in the way kde handles .Xresources.
I seperated out my color settings into an own file (to be able to easily change them) and simply #include one in .Xresources. krdb does not like that as it looks.
I think a way to fix this might be to not read the file .Xresources but to get the settings by running xrdb -query. That way xrdb does the work of correctly parsing its own config, and KDE user get what they configured ;)
Comment 5 Björn Feber 2019-08-19 10:56:44 UTC 
Looks like this is fixed.