Bug 157126 - katepart saves colors when no changes made, no way to reset to system colors
Summary: katepart saves colors when no changes made, no way to reset to system colors
Status: RESOLVED DUPLICATE of bug 219795
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-02 16:04 UTC by Nick Shaforostoff
Modified: 2012-02-27 13:28 UTC (History)
0 users

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Shaforostoff 2008-02-02 16:04:21 UTC 
Version:            (using Devel)
Installed from:    Compiled sources

1. KTextEdit a; a.setReadOnly(true);
2. change color scheme in systemsettings
3. background color is still the same

and btw katepart doesnt react on colorchanges either, even after kwrite restart
Comment 1 Matthew Woehlke 2008-02-05 02:12:16 UTC 
katepart has an annoying habit of remembering what the colors are, even if you haven't changed them. Fixing this should already be on the TODO somewhere.

Note that katepart will, and should, remember the total color scheme as soon as you *do* make a change.

We could also really use a 'reset to system colors' button (or else, a not-modifiable 'system colors' scheme)...

(Please reassign back to kdelibs if I'm wrong in guessing that the KTextEdit you are using is indeed katepart...)
Comment 2 Bruno Massa 2008-04-07 22:21:26 UTC 
I confirm the bug.

New info: for syntaxes that mix/add other syntaxes (like PHP that adds Doxygen), it wont change the PHP color if i change only the Doxygen color palette. It seems that Kate merge the them before and the relationship gets lost.
Comment 3 Dominik Haumann 2012-02-27 13:28:14 UTC 

*** This bug has been marked as a duplicate of bug 219795 ***