Consider enabling dark-light by default in eframe

[mwcampbell]

Rationale: For some visually impaired users, using a dark or light color scheme is an accessibility feature, as important as a screen reader is for a totally blind user.

[emilk]

I have gone back and forth on this quite a bit: #1941

[mwcampbell]

Fair enough. And, contrary to what I said above, an application ignoring the system theme isn't as severe a problem as being inaccessible with a screen reader, since the user can use an external tool to invert the colors. But let no one accuse me of ignoring accessibility needs other than screen readers.

[mwcampbell]

That said, of the 3 reasons mentioned in that PR, the only one that is persuasive to me is the one about difficulties on Linux. Where can I read more about this? I wonder if the same issues will come up when AccessKit introduces support for AT-SPI, via zbus.

On the other two reasons, while it's ultimately your call, I think that adapting to the users' needs and preferences, on the assumption that we don't know who our ultimate users are, should take priority over conforming to developers' expectation of a fixed appearance under their control. That is, while the latter should be an option, it should require more work for the developers that want it, just like disabling AccessKit in eframe.

[emilk]

I can't find the build issue right now, but dark-light has a few problems:
frewsxcv/rust-dark-light#17
frewsxcv/rust-dark-light#15

[mwcampbell]

OK, I'll close this one for now, since the latency issue means that dark-light isn't ready for wide deployment by default.