Re: dark theme

Sorry, more succinctly: ColourRGB() and ColourRGBA() perform a very simple 
clear job. ColourFromString and ColourAlphaFromString are not necessarily 
so generic, eg. they could be name ColourFromProperties and they could 
interpret text from properties circumspectly. All of the colours read by 
them should sooner or later be transformed when invertBrightness is true, 
it seems fitting to do it straight away. 
I could make the inversion function return a single INT and call it 
InvertedColourRGBA() and have ColourFromString and ColourAlphaFromString 
use InvertedColourRGBA() instead of ColourRGBA() when dark mode is set.
Andrew
On Thursday, 4 May 2023 at 14:49:00 UTC+1 andrew strain wrote:

> 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/a6aa4c19-afd1-47c7-ba3f-d57ace43fb6dn%40googlegroups.com.