Neil Hodgson wrote:
...
http://scintilla.sourceforge.net/AlphaMarks.png
The SciTE caret.line.back can now have either 6 or 8 digits with
the first two digits of an 8 digit number setting the alpha (01 is
almost transparent, FF is opaque) so the picture uses
caret.line.back=#20AFFF00. Best merging occurs with strong colours and
low alphas. A new (Windows only) SciTE property, find.mark, turns on
and sets the colour of boxes used to show each match when the Mark All
command is used from the Find dialog. The boxes disappear when the
text is edited or Clear All Bookmarks performed.
My main problem with this code is how to integrate alpha into the
system. Should every colour variable contain an alpha component that
may be ignored in many situations? The current code uses explicit
alpha for the caret line and hard coded alphas for the boxes. I'm
worried that platform layers will require significant work to ignore
alphas if ColourDesired and ColourAllocated include alpha. Some
platforms may not be able to easily support alpha drawing: the
AlphaRectangle code just draws an outline on GTK+ 1.x.
The picture looks nice, but alpha on a caret that is usually one pixel
wide? It (just talking about the caret) seems like a pretty subtle
effect. ;)
I would favor leaving "general" RGB specifications alone and add API
calls when alpha makes sense, e.g.,
SCI_MARKERSETALPHA(int markerNumber, int opacity)
or
SCI_INDICSETALPHA(int indicatorNumber, int opacity)
if one thinks this feature might be beneficial to indicators.
For SciTE, this just becomes ",alpha:#27," etc where applicable.
While it probably doesn't matter to everybody, I also like leaving
colors at "24 bits" because in OCaml, normal integers are only 31
bits; if colors become full 32-bit values, then ALL colors become full
32-bit values which must be allocated on heaps and garbage-collected
etc... right now the only places my OCaml wrapper for Scintilla has to
do this is with margin and marker "mask" values. :)
BTW, this could add "interesting" semantics to, say, markers - when
displaying multiple markers for a line, instead of higher-numbered
ones obscuring lower-numbered ones, they could now be "blended" (with
weighting [possibly] coming from their alpha values)...
This presumably only makes sense if all of the markers you want to
blend have alphas - or maybe if even one marker has an alpha, then any
markers without it get assigned a default alpha value.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
