[Development] Dark mode, palettes, styles etc.

[Edward Welbourne]

Shawn Rutledge (6 July 2018 10:50) wrote
> [...] I had the idea a few years ago anyway that there should be an
> easy global switch (always within reach, not having to paw through
> system settings) to toggle quickly between light and dark themes.
[...]
> But now that Apple is finally doing something, I think the copycats
> are inevitable, so I fully expect to see news that an identical or
> better feature is coming soon to KDE and/or Gnome any day now.

Who knows, perhaps some more modern apps will begin supporting the X
Resource I've been using for nearly 3 decades,

*.ReverseVideo:		true

(albeit some apps, e.g. Rxvt, want it spelt "reverseVideo") to achieve
"dark mode" under X.  Older X-Windows apps (emacs, various terminals,
Xephyr, xpdf) support it fine, newer ones (e.g. web-browsers) not so
much.

(... and there's nothing wrong with copycats - "nothing is new that is
under the sun, except for what we have forgotten" ...)

> Another easy thing I think we could add to QPalette is the set of
> (16?) most-common colors.  That way, when an application really wants
> something to be blue, it could use QPalette:Blue, and the theme would
> be able to control the brightness and the exact shade of blue.  (The
> color of blue that is default on a white xterm is nowhere near the one
> you want if your terminal is black.)  So you could easily "solarize"
> your whole desktop, if that’s your thing, even while applications
> retain control over the general hues.  Then terminal applications,
> editors that have syntax highlighting, and such things would be able
> to use those colors.  The settings to define each of those would be
> global, and the need for e.g. Konsole and Creator to have their own
> independent sets of themes for text highlighting would go away.

I like the idea of this sort of abstraction, giving the user better
means to personalise what their eyes spend all day on, but the fiddly
details are tricky to get right, balancing between ease of use for the
vast majority of apps (that only need a few colours and fonts) while
providing enough flexibility for those apps that really do need many.

> (Although, Creator would still need settings to map highlighting
> classes to QPalette colors: e.g. comments are green and keywords are
> blue, or whatever.)  So they too would respond to global theme
> changes.

Indeed.  In emacs, the font-lock system's settings, as shown by M-x
list-faces-display, run to 168 distinct "faces" (i.e. text styles, for
different syntactic uses).  Most apps aren't going to want a system that
takes the abstraction that far, but those that do really do want it.

	Eddy.