Pavel Sanda <sa...@lyx.org> writes: > while understanding JMarc point about inheriting system-wide colors, i'm more > on Uwe's side to let by default the background as it was.
Note that my original patch allowed to override system colors. But now that there is a 'use system colors checkbox', it cannot be done anymore. > inheritance would make some sense if there was some system system-wide > color called 'background for reading' for which is clear that > ergonomic(=!white) setting is generally used on the system and was > properly thought about. imho the system-wide 'background' is used for > semantically different things, thats why the problems. its absurd to > mimic office behaviour when every dev around acknowledges that > (implicit) white setting for longer sessions impair your eyes. So (1) there is a definite need for a 'background for reading' but (2) no user interface ever implemented it? Weird... Actually, I would be interested to read some research about it. That said, I understand the fuss around background color. What I would like to do (but is not possible right now) is to make everything (text, graphics, maths...) transparent by default so that people can see though the real background. The _I_ would like to set this as the system default, with the knowledge that people would have the possibility to change 1 color to their liking and be done with it. The current situation where changing from "linen" to whatever requires changing 7 or 8 colors is absurd, but nobody seems to want to see it. > which leads me to the second discussed point: please be very gentle > about removing colors just because in _your_ eyes they have only > little meaning. over-abundance of options should be fought when the > feature is introduced, having regression once you get accustomed to > some feature is much more frustrating... You know that nobody steps in until there are talks of removing a feature. As the text I posted outlines, adding features is easy, the real work is to remove features. Should we have kept the caption color just because Lars thought one day it might be a good idea? Don't you know that many things are configurable just because someone thought: "I might as well make it configurable?" > as an example Uwe wants to kill graphics background color because he has > no idea what it does, which is just irresponsible. If you planned to whip Uwe for that, please whip me instead. > in such case you need to associate it with one fixed color, so all my > png images with alpha channel are going to have fixed background. if > it merges with the foreground then what? if you choose the same > background color as i have for text background so i dont see the > border of the image(s) then what? So you have transparent png (so that they melt well with the background), but you do not want them to actually melt with the background, right? Is it mainly because of your grey on black setting? > moreover if you dont use your own styles its hard to imagine all the > consequences of some colors settings. e.g. i'm not able to read branch-inset > 'outdated' in customization manual because - well nobody got the idea that you > can have black-bg grey-fg theme. This is why following UI recommendation makes sense. The windows UI docs recommend to avoid using your own hardcoded colors. I would like something like replacing grey with a color somewhere in the middle between foreground color and background color, for example. And the highlighted color would be the same, but with a bigger push on the background side (so it would be darker on your scheme). I think sever color can be synthesised this way. That would both reduce colors and be nice to themes. > the fg inside branch inset is set on grey and bg of branch inset is > not document setting so all you see is nice grey rectangle :) for > similar reasons i'm forced to keep my own version of stdinset.inc - > some backgrounds can be cutomized and some foregrounds are fixed for > 'foreground' which you again recognize only when custom theme is > used... so please be very careful of the consequences. For collapsable insets, a solution would be to change the color of the button itself to the inset color and typeset the button text in normal foreground color. I agree that useful stuff should not be removed. But "I do not want to change" is not a good enough argument anyway. Of course, the guy who is supposed to enforce this type of changes is the maintainer... JMarc
