Patrick M wrote: ↑
Sat 08 Dec 2018, 14:56
it was just the normal one with the colours inverted
I tried that, but it didn't cut it. One issue was gamma (or the logarithmic response of the eye if you prefer): in the normal colour scheme the toolbar's background colour (RGB 240,240,240) is very obviously different from the editing pane's background colour (RGB 255,255,255) which is what you want. But if you invert them RGB 15,15,15 and RGB 0,0,0 look identical to me: both totally black. To make the toolbar (and other related GUI elements) noticeably lighter than the editing pane I found I needed to set them to RGB 64,64,64 or thereabouts (which is what I used for that screenshot) and that necessitated a new toolbar BMP.
The other, less technical, issue was simply that the colours of the toolbar buttons were not chosen randomly, for example the 'Run' button is green (for 'go') and the 'Debug' button is red (for 'caution' or something). Simply inverting the colours gives a magenta Run button and a cyan Debug button which just don't look right to me! That sort of thing is OK for a hack, but I wouldn't be happy with it in a properly engineered solution.
I'm also finding that there's quite a lot of work involved in making 'dlglib.bbc' (which is used for all SDLIDE's dialogue boxes) behave nicely in the Dark Mode. Even passing the flag to the library routines needed considerable thought (it's not generally acceptable, nor good practice, for libraries to access global variables). It's working now, I think, but it shows how a relatively minor change can escalate in complexity.
I'm not going to bother to make the List Variables, Profiler and Compiler utilities adhere to the Dark Mode setting because they run as separate processes and it really would be a pain to have to find a way to pass the flag to them. I hope that doesn't upset anybody too much, but there are limits to the amount of effort I'm prepared to put in for a feature I will probably never use myself.