[khelpcenter] [Bug 521122] Enable dark mode

https://bugs.kde.org/show_bug.cgi?id=3D521122

skaffi <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skaffi.secluded835@slmails.
                   |                            |com

--- Comment #6 from skaffi <[email protected]> ---
This is lovely news! I was about to open an issue for this as well, but dec=
ided
to check for duplicates first. Happy to find that the issue is already solv=
ed.
:)

Reading the conversation on Invent, however, it seems that you've decided
against giving the user an explicit choice in whether the content should be
light or dark, and instead letting it come down to an automatic interpretat=
ion
of their selected system colour scheme as either light or dark, and followi=
ng
that?

I find that very unfortunate to hear. Not all colour schemes fall neatly in=
to a
"light or dark" dichotomy, nor should they have to. I personally use of what
can best be described as more of a "medium" colour scheme, in terms of
lightness. Because of that, automatic detection systems will sometimes
interpret it as light, sometimes as dark, and will frequently decide on the
opposite of what I would prefer, if I had to choose. That's why I hugely
appreciate when a manual override is still made available.

As good and as reasonable as automatic detection can be, you are always goi=
ng
to have trouble with edge cases that don't sort so neatly into the defined
sorting categories - especially the case when you're sorting something that=
 is
literally a spectrum into just a binary, two categories - the world isn't t=
hat
black and white, or, dark and light, if you will.

But so what? One might say it's an issue of user error, the user having pic=
ked
a "bad" colour scheme, and they can fix the issue simply by picking a colour
scheme that conforms more neatly with the light/dark dichotomy. I suppose
that's fair. Speaking for myself, though, my choice of colour scheme is not=
 so
much a matter of taste or fashion or style, as it is a matter of simply usi=
ng
the option that is most accommodating to me. Using such "medium" schemes ma=
kes
a huge difference for me, in avoiding both eye strain and brain strain.=20

You don't have to design your systems to also be able to accommodate outlie=
rs
and edge cases, if you don't want to. But something isn't necessarily "brok=
en",
for not fitting into a simple dichotomy. My colour scheme is certainly not
"broken" - my eyes and my brain might be, yes, but my colour scheme is work=
ing
*very* well, as an enabling piece of assistance for me. :)

According to the merge request on Invent, the new dark mode for Help Center=
 is
something that will be automatically generated for users, if they have a co=
lour
scheme that gets considered to be "dark". Well, if you are generating the
recoloured pages on the end user's computer, rather than simply distributin=
g a
dark variant together with the light, then wouldn't it be possible to gener=
ate
those pages with colours read directly from the user's active colour scheme=
? To
me, that seems like the most ideal solution possible. Besides accomodating =
the
people using "medium" type colour schemes, you'll also achieve a much great=
er
level of polish and coherence for everyone who is using a clearly light or =
dark
theme that *isn't* Breeze. But if that is too much work (it might be, I
wouldn't know), then a simple user override (light/dark/system) would still=
 be
hugely appreciated.

In case I've misunderstood the conversation on Invent, and the new system is
already designed to pull the user's custom colour scheme, rather than just
using a stock light/dark Breeze scheme, then I apologise!

--=20
You are receiving this mail because:
You are the assignee for the bug.=