For normal text, the match is commonly a word so the padding on the
indicator doesn't overlap characters of interest. For source code,
however, you are often interested in the operator characters right
next to the match. The indicator can be made translucent but then
there are conflicting demands for either the match or the background
to be visible. Xcode solves this by fading the indicator away after it
has performed the initial animation. The implementation could provide
both to allow for the two cases.
On OS X windows can have animation layers that are mostly
independent of other drawing and that animate using the GPU on
separate threads. I haven't looked at the equivalent Windows APIs but
expect a similar effect could be achieved. For GTK+, I don't know of
any animation APIs that work with the widget system. While the same
effects could be achieved with normal drawing, it would be much more
work and may not be as smooth.
Animation adds new dimensions of choice over static drawing as
different movement, effects and timing can be chosen but I'd prefer to
avoid adding many settings for this.
The API could be something like
SCI_SHOWFINDINDICATOR(position start, position end)
with a SCI_FLASHFINDINDICATOR to fade as well. Setting an empty
range would hide the indicator.
Neil
I think in 10.7 this can be taken care of for you by making the
ScintillaView implementing an NSTextFinder[1] (NSTextFindClient,
NSTextFinderBarContainer protocols). I started to try this with
ScintillaView, but never finished. Just throwing it out there in case
you hadn't seen it yet, since it overlaps a bit with what you're talking
about here.
Cheers,
Matthew Brush
Supporting NSTextFinder would be worthwhile though.
Neil
SCI_FINDINDICATORSHOW(position start, position end)
SCI_FINDINDICATORFLASH(position start, position end)
SCI_FINDINDICATORHIDE
Neil