Final effect:
1. 2 alpha can be set separately: whitespace.fore.alpha=<alpha> and whitespace.fore=#rrggbbaa.
2. whitespace.fore.alpha controls all colours including that inherited from grammar settings; whitespace.fore controls the colour specified manually.
3. whitespace.fore.alpha > whitespace.fore, if both exist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's more that SCI_SETWHITESPACEFORE should forward to vs.elementColours[SC_ELEMENT_WHITE_SPACE] as there should be a single representation of this value. ViewStyle::whitespaceColours gets broken up so that the background can remain a ColourOptional (for now) and all the code that used whitespaceColours.fore moves to elementColours[SC_ELEMENT_WHITE_SPACE]. Something like the attached patch.
Then SciTE can be updated to only use OptionalSetColour. All the old applications still using SCI_SETWHITESPACEFORE stay the same until SCI_SETWHITESPACEFORE is removed after a period of deprecation.
I thought it would be in 2 commits. Thanks for your detailed description and codes. Here is the updates.
Known issues with legacy GDI:
1. SurfaceGDI::LineDraw and SurfaceGDI::PolyLine for DrawTabArrow don't work well with alpha drawing. Maybe also others.
2. SurfaceGDI::AlphaRectangle is not efficiency enough for "many" tasks.
Here's another patch to match the change from ColourOptional to std::optional<ColourAlpha> in [72d5f9] .
SurfaceGDI::LineDraw and SurfaceGDI::PolyLine ... don't work well with alpha drawing
Yes. Applications can check SCI_SUPPORTSFEATURE(SC_SUPPORTS_TRANSLUCENT_STROKE) and change their drawing settings if they need to. It would be possible to alpha enable tab drawing on GDI for the simplified SCI_SETTABDRAWMODE(SCTD_STRIKEOUT) appearance but that may be more work than its worth.
2: SurfaceGDI::AlphaRectangle is not efficiency enough for "many" tasks.
Its slower but its not unusably slow for common cases. Each Scintilla feature has different costs in different scenarios and its up to applications and users to decide where to trade off between features and speed. Its reasonable to turn off higher cost features on slower machine or for huge documents.
Isn't atomic commits preferred?
This is beyond my knowledge for so many changes, especially during this big-change stage.
If there is any contribute from me, it's just the idea. Others are all your efforts. Please commit it at the proper time by your schedule.
Many thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have more of a preference for atomic commits than most and will often write a preparatory revision that restructures the code with no change in behaviour before a functional change but this patch seems pretty atomic to me. There are two elements being modified, the foreground and background and they could be treated separately but they are initially in a single whitespaceColours field so I think that including both in a change set is better.
There could be two change sets: splitting the variable into ViewStyle::whitespaceFore and ViewStyle::whitespaceBack then another change set moving whitespaceFore to vs.elementColours[SC_ELEMENT_WHITE_SPACE] but that introduces an extra field that is only there for a single revision.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a side effect of this change, the appearance for wrap symbol may not be the desired when white space alpha is used. A quick for wrap symbol color is change ViewStyle::WrapColour() to returns Opaque(), but it seems better to define a new element color for wrap symbol.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Final effect:
1. 2 alpha can be set separately:
whitespace.fore.alpha=<alpha>andwhitespace.fore=#rrggbbaa.2.
whitespace.fore.alphacontrols all colours including that inherited from grammar settings;whitespace.forecontrols the colour specified manually.3.
whitespace.fore.alpha>whitespace.fore, if both exist.OK, to make it simple: no
whitespace.fore.alpha, just makewhitespace.foreaccept also rgba besides rgb.Update
scite_5599_Make-whitespace.fore-accept-rgba.patch, asSetWhitespaceForecalling shouldn't be removed currently.It's more that SCI_SETWHITESPACEFORE should forward to vs.elementColours[SC_ELEMENT_WHITE_SPACE] as there should be a single representation of this value. ViewStyle::whitespaceColours gets broken up so that the background can remain a ColourOptional (for now) and all the code that used whitespaceColours.fore moves to elementColours[SC_ELEMENT_WHITE_SPACE]. Something like the attached patch.
Then SciTE can be updated to only use OptionalSetColour. All the old applications still using SCI_SETWHITESPACEFORE stay the same until SCI_SETWHITESPACEFORE is removed after a period of deprecation.
I thought it would be in 2 commits. Thanks for your detailed description and codes. Here is the updates.
Known issues with legacy GDI:
1.
SurfaceGDI::LineDrawandSurfaceGDI::PolyLineforDrawTabArrowdon't work well with alpha drawing. Maybe also others.2.
SurfaceGDI::AlphaRectangleis not efficiency enough for "many" tasks.Here's another patch to match the change from
ColourOptionaltostd::optional<ColourAlpha>in [72d5f9] .Yes. Applications can check
SCI_SUPPORTSFEATURE(SC_SUPPORTS_TRANSLUCENT_STROKE)and change their drawing settings if they need to. It would be possible to alpha enable tab drawing on GDI for the simplifiedSCI_SETTABDRAWMODE(SCTD_STRIKEOUT)appearance but that may be more work than its worth.Its slower but its not unusably slow for common cases. Each Scintilla feature has different costs in different scenarios and its up to applications and users to decide where to trade off between features and speed. Its reasonable to turn off higher cost features on slower machine or for huge documents.
Related
Commit: [72d5f9]
Isn't atomic commits preferred?
This is beyond my knowledge for so many changes, especially during this big-change stage.
If there is any contribute from me, it's just the idea. Others are all your efforts. Please commit it at the proper time by your schedule.
Many thanks!
I have more of a preference for atomic commits than most and will often write a preparatory revision that restructures the code with no change in behaviour before a functional change but this patch seems pretty atomic to me. There are two elements being modified, the foreground and background and they could be treated separately but they are initially in a single whitespaceColours field so I think that including both in a change set is better.
There could be two change sets: splitting the variable into ViewStyle::whitespaceFore and ViewStyle::whitespaceBack then another change set moving whitespaceFore to vs.elementColours[SC_ELEMENT_WHITE_SPACE] but that introduces an extra field that is only there for a single revision.
SC_ELEMENT_WHITE_SPACE allowing a translucent value was committed as [572e28] .
Related
Commit: [572e28]
As a side effect of this change, the appearance for wrap symbol may not be the desired when white space alpha is used. A quick for wrap symbol color is change ViewStyle::WrapColour() to returns Opaque(), but it seems better to define a new element color for wrap symbol.
Wrap symbol colour has been tied to whitespace colour for years and its not unreasonable to include alpha in that.
A more specific setting for the wrap markers may be reasonable but that is a separate issue.