| Summary: | standard colors for code highlighting change with kde color theme | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | Robert Riemann <robert> |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | mwoehlke.floss, niburu1 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | screenshot of kate with ruby syntax highlighting | ||
|
Description
Robert Riemann
2009-07-17 00:10:03 UTC
Created attachment 35405 [details]
screenshot of kate with ruby syntax highlighting
the kde color theme is: opensuse.org (from kde-look.org)
Try the following: Configure -> Fonts & Colors There create a _new_ schema (top of dialog). Save that under e.g. "opensuse". Set it as default scheme (bottom of dialog). This works for me with most color schemes. Though indeed, I think the handling of changed kde color schemes and the color scheme generation is somewhat supoptimal in kwrite right now. I'd like to see at least a dialog popup: "Hey, you changed your KDE color scheme. If the current Kate scheme doesn't work for you anymore, take a look in the config and create a new one!" This is by design. If you do not change kate's color scheme, the default is to use the system color scheme. The scheme you refer to is broken; just from looking at their screenshot[1] you can tell that the PositiveText color is not legible against the view background. You should report this to the color scheme's author. 1: http://www.kde-look.org/content/preview.php?preview=1&id=91651&file1=91651-1.png&file2=&file3=&name=openSUSE.org+KDE4+Color+Scheme > I think the handling of changed kde color schemes and the color > scheme generation is somewhat supoptimal in kwrite right now. It works well for me (assuming your system color scheme isn't broken to begin with), except for highlighters that hard-code colors (those are broken). Can you be more specific what you think is suboptimal? I've notified the creator of this theme via kde-look.org: http://kde-look.org/content/show.php/openSUSE.org+KDE4+Color+Scheme?content=91651 @Matthew Wohlke: Why does it work for pretty much every color scheme I used so far, if I create a new scheme? See my "workaround" above. That one seems to be very solid. But it's not used when changing the KDE color scheme it seems... That's why I think kates behaviour is suboptimal! > @Matthew Wohlke:
^e ;-)
If you explicitly save (or make changes to) a kate scheme, it will use that instead of the system colors (by design). Is that what you mean? (Including changing something that started out as system colors; it saves what those were, and subsequently doesn't change when the system color scheme changes.)
I think I would prefer if kate didn't let you change the default scheme (i.e. default = always use system colors), however that is a different bug/RFE :-).
As for your suggestion, I don't think I want kate to nag when the system color scheme changes if you are using the system color scheme for kate. (Besides, I don't think it is even possible to do that, short of always saving everything and comparing it to what is in the system scheme at every startup...)
I prefer to get people in the habit of not creating broken color schemes ;-).
What I encountered that even with aparrently broken color schemes (most if not all darker ones) at least some parts were highlighted bad. To fix it all I had to do was create a new color scheme. And I really mean just "create". I.e. hitting the "new" button in the settings. The then created scheme was every time superior to the other auto-adapted default one as far as I could see. Of course, it could be that I did a change sometime to default or anything else and hence the adaption didn't work as expected... To reproduce I did the following: - Remove anything about schema / highlighting in kwriterc - Remove anything related to kwrite in katehighlightingrc - set color scheme to KDE default - open Kwrite, highlighting is fine, crips and has good contrast - all is good. - change color scheme to e.g. obsidian coast => first problem: higlighting / editor view is not adapted (i.e. nothing happens) at least everything is still readable, but the contrast is far too high (i.e. white editor component in contrast to all other dark windows and widgets) - close kwrite and reopen it with the same file - some things will be adapted, but the background color will stay (maybe the main problem?) Screenshot: http://milianw.de/files/bugs/kate_color_adaption.png As you can see the default text color is a light shade of grey (possibly the default for Obisdian coast). Background is not adapted... Now the same document after going to kwrite settings, and creating a new scheme (_just_ "new", no other changes!): http://milianw.de/files/bugs/kate_color_adaption_newscheme.png Granted, the doc comments and the black for html in them is unreadable. But afaik these are hardcoded in the .xml file... What I would like to see: - a immutable "default" color scheme, i.e. which cannot be changed - when the user changes his color scheme, that scheme is adapted to the color scheme. You can look at e.g. kdevelop where I made the custom highlighter generate proper colors from a given one and the scheme colors - all open views get rehighlighted accordingly I hope this shows that the current situation is suboptimal and the bug gets reopened. > - a immutable "default" color scheme, i.e. which cannot be changed Yes, what I just said :-). > - all open views get rehighlighted accordingly Hmm, yes, I believe right now there is no (dynamic) response to the system scheme changing, i.e. you need to close and re-open. > I hope this shows that the current situation is suboptimal and the bug gets > reopened. I never said it was perfect :-), just different from the original report. Would you mind opening a *new* bug for replacing the current 'default' with an immutable 'always use system colors' scheme? (And add a note that said scheme should respond to the system-scheme-changed notification.) I wasn't able to reproduce the background color not changing with the system scheme. When you nuked things, did you also get kateschemarc? (It would be nice if kate didn't store colors in three different places :-(.) I changed from the system Oxygen color scheme to Obsidian Coast (which is dark). I may have mucked around with the "default" color schemas of Kate but it never told me that the changes would be *saved*! Now when I go back to Oxygen, my Kate color schema is still optimized for the dark Obsidian Coast scheme, and there's no way to reset it back to the *real* default. This is extremely surprising and horrifying behavior! I removed the kateschemarc file from ~/.kde/share/config which helped a bit but not totally. Is there any way to get system defaults back? Create a new scheme and use that instead, as I said above that helps most of the time to get a scheme that works with the current global color settings. Also reopening since there is still lots of space for improvements, I might work on that for KDE 4.5. > I changed from the system Oxygen color scheme to Obsidian Coast (which is > dark). I may have mucked around with the "default" color schemas of Kate but it > never told me that the changes would be *saved*. Sorry, but... did you really expect kate to *forget* your changes? :-) I know it could be more obvious, but I don't think it's "extremely surprising and horrifying". Milian: as stated, this is still invalid. I'm merging with bug 219027; yes it's newer, but states the problem more succinctly. If you don't think what is described in that bug is the/a solution, please create a *new* bug, or at least change the description when reopening to state the actual problem that needs to be addressed. Thanks. *** This bug has been marked as a duplicate of bug 219027 *** |
