Re: dark theme

andrew strain <[email protected]> Thu, 4 May 2023 06:49:00 -0700 (PDT)
Newsgroups gmane.editors.scite.general
Message-ID <[email protected]>
Looking into it a bit more, ColourFromString is called 14 times within 
StyleDefinition and SciteProps and once in SciTEbase. ColourAlphaFromString 
is called 9 times within StyleDefinition and SciTEProps.
These are functions which read text to determine desired colour, they 
happen to only understand hex rgb/a expressions. They each use the 
essentially simple functions ColourRGB() ColourRGBA() defined as inline 
constexpr's in StyleDefinition.h  which simply pack the values into the 
final low level colour word. ColourRGB() & A are used a handful of times 
outside of the two ColourFromString functions, to set default property 
values, those could neatly be changed to the string reading functions.   

Those sort of colour-expression-readers seem to be appropriate places to 
add any desired input transformation, like a transform to colour space, or 
in this case 'luminosity space'. With the transform function beside them 
and they each call it on their internal values if invertBrightness, before 
returning their output (which they use ColourRGB/A to pack). 

If it was done in scintilla, it would seem required to take apart the rgba 
INTs as soon as they are recieved and transform and repack them before they 
are stored. Unlike the dark conversion for printing, they probably shouldnt 
be transformed for each render. And since a practical luminosity 
transformation cant be 'invertable' ( the very bright and dark values can't 
be converted back and forward ) - it cant be undone without a backup. It 
works out much simpler in SciTE with its speedy properties refreshing, to 
do the conversions at the point rgba's are determined from config text 
strings. 

My lua script is evolved to do it very nicely though, its possible.

Im completely bamboozled by cpps scoping ways. Perhaps 
ColourAlphaFromString and Alpha' can be moved or namespace redesignated 
somehow so they can see invertBrightness ? The very simple ColourRGB() 
ColourRGBA() could be untouched.

Andrew
On Thursday, 4 May 2023 at 03:48:03 UTC+1 Neil Hodgson wrote:

> Andrew:
>
> > A bit bamboozled here by cpp's structure. I have `bool invertBrightness` 
> declared in SciTEBase.h and set to false in SciTEBasec.cpp and in 
> SciTEProps.cxx it is set and compiles fine in void 
> SciTEBase::SetPropertiesInitial. But I am trying to patch the transform 
> into the methods in StyleDefinition.cxx SA::Colour ColourFromString( and 
> the RGBA version of that function. But 'invertBrightness' was not declared 
> in this scope.
>
> Changing ColourFromString may appear an attractive way to affect things 
> globally but its bad modularity - ColourFromString performs a very simple 
> job. You could modify callers to ColourFromString which will have access to 
> SciTEBase or modify the output side sending data to scintilla like in 
> SciTEBase::SetOneStyle.
>
> > If I can get the formulas running then I should be able to calibrate 
> them to work reasonably well, I can use a longer version if its required to 
> work on the perl syntax and tricky cases. I have used it alot to switch 
> between daylight and after hours mood. I do not see anywhere else to put 
> the transformation than those string conversion functions in 
> StyleDefinition, perhaps it could go somewhere into Scintilla itself ?
>
> Scintilla works with colours a lot so each ColourRGBA instance would have 
> to be modified which would be a significant amount of work. It's a bit 
> similar to the old palette code which had to use a limited range (16 or 256 
> commonly) of available colours to cover the desired colours. Palette 
> support was difficult to maintain and a source of bugs. A colour transform 
> could be added to drawing surfaces in platform layers but that would need 
> to be implemented for each platform.
>
> Scintilla itself contains an InvertedLight function but it is only for 
> printing in SC_PRINT_INVERTLIGHT mode used when the screen is set to a dark 
> background but the user doesn't want to waste ink. 
>
> Neil
>
>

-- 
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/scite-interest/f6f95f57-5cfc-4280-b070-788c4f0ddd52n%40googlegroups.com.