https://bugs.documentfoundation.org/show_bug.cgi?id=167511
--- Comment #24 from Michael Weghorn <[email protected]> --- (In reply to Armin Le Grand (collabora) from comment #23) > Not really - what the change does is to react on HighContrast being set, so > in principle the presentation *should* then be in high contrast too, right? > The question is what is the error here... > Of course when it was like that (ignoring HighContrast for presentation > mode) until now that's an argument to stay at that (what also means we have > no way to have presnetation in HighContrast - but never had - but would > maybe need due to accessibility?). Having a setting to also force high contrast in presentation mode might be worth a consideration, but I think using the "actual" colors at least by default makes sense. Similar to what happens for PDF export or printing, high contrast might be seen as a setting to help in the "one-user editing/reading stage", but not what affects the "final output" by default, which is what "everybody" sees. (Maybe using high contrast in the presenter console but not on the presentation screen might be another option, but that'd likely be a new feature and best handled independent of this bug report?) (In the GNOME a11y matrix room discussion, there were also other voices that high contrast shouldn't affect the document at all, only the rest of the UI, which could be another configuration option if we want to introduce more flexibility/complexity.) > In principle we would have to remove those hacks in OutDev and move all that > stuff to where the rendering is defined. Imagine the code to draw a button: > It is hard-coded to some colors and these hacks make e.g. DrawRect in OutDev > ignore that colors and use HighContrast ones. Instead the code to draw a > Button should have a color scheme from where it picks the colors. Then just > use schemes for normal and HighContrast and whatnot. I'm not very familiar with what exactly happens on the rendering stages, but this sounds plausible to me. (I think we have some concept of color schemes/StyleSettings already, but it's very possible that the actual colors are resolved "at the wrong stage" currently instead of being passed to where they should go.) > Problem is that there is never budget for things like this, I guess that's > also the reason it is implemented as it is for now. Understandable, no one > pays for cleanups which make it look as before ignoring the security and > cleanup effect. But also ignoring that the code gets *again* more and more > quirky and ssth like these modes need dozens of dozens of bugfixes - exactly > for that reason. I would not be surprised when costs for that are a multiple > at the end compared to just clean it up once. sigh... You can probably judge best what's the "best" approach/compromise here, taking the different factors that come into play into account ("cleanest" solution vs cost/effort). Thanks for looking into it! -- You are receiving this mail because: You are the assignee for the bug.
