User Drawn Markers
Paul Selormey
Thanks for the great work you are still doing with this library.
I am trying to use the ScintillaNET as an alternative editor in
SharpDevelop, and wanted a little more control over the marker
rendering.
I took the Scintilla source added a callback method in addition to the
XPM and "standard" systems. Defined a new constant #define
SC_MARK_CALLBACK 30
typedef bool (__stdcall* MarkerDrawCallback)(SurfaceID hdc, PRectangle
rc);
had to add GetID() to the Surface class to retrieve the SurfaceID etc
and exported a function to set the callback to the LineMarker.
Finally in the LineMarker::Draw, I added
if ((markType == SC_MARK_CALLBACK) && (callback)) {
callback(surface->GetID(), rcWhole);
return;
}
The result is good and what I wanted (tested it in the ScintillaNET
from a C# application), but I do not know if you wish to do or accept
anything like this. I do not work with Linux/Mac right now but it
should be similar for all platforms. Does this fit in your design plan
for the Scintilla?
Best regards,
Paul.
Neil Hodgson
> I took the Scintilla source added a callback method in addition to the
> XPM and "standard" systems. Defined a new constant #define
> SC_MARK_CALLBACK 30
>
> typedef bool (__stdcall* MarkerDrawCallback)(SurfaceID hdc, PRectangle
> rc);
>
> had to add GetID() to the Surface class to retrieve the SurfaceID etc
> and exported a function to set the callback to the LineMarker.
There are many issues with adding reasonable customizable drawing
to the API. Depending on the platform, multiple entities may be needed
to allow drawing including a measurement object, object to draw on,
window object, and screen object. Passing just a SurfaceID will not be
sufficient on all platforms.
The set of things needed for drawing is hidden behind the Scintilla
platform layer concept of a drawing surface. One approach to
customizable drawing is to pass in a Surface* and provide an API for
working on the Surface. This would require more work and is likely to
drag in other platform layer entities like Font and Window. It would
expose the current implementation and so require future versions to
maintain that interface.
Some resource allocation issues are better handled by Scintilla.
Scintilla can currently work on paletted displays which requires both
allocation of palette entries and following the platform protocol to
ensure that palettes are 'realized' when needed. Now, paletted
displays have decreased in use greatly although there may still be
some use in remote displays. Possibly its time to drop palette support
from Scintilla. This would require examining each platform layer and
is made more difficult by some platforms like GTK+ trying to make
palettes easy by requiring explicit allocation in almost all cases - a
GdkColor can only be drawn after calling an allocation function (or
working out some way to fill in the pixel field in your own code).
> The result is good and what I wanted (tested it in the ScintillaNET
> from a C# application), but I do not know if you wish to do or accept
> anything like this. I do not work with Linux/Mac right now but it
> should be similar for all platforms. Does this fit in your design plan
> for the Scintilla?
There are pros and cons. A really good implementation could allow
for better drawing and new features but would add to maintenance load.
If someone were to provide an implementation for all current platforms
and commit to maintaining it then maybe. Otherwise I don't think so.
Neil
Paul Selormey
ScintillaNET is currently trying its own custom drawing of the
indicators, but
when I monitored the effects, it does not work nicely with the
optimized rendering
of the Scintilla.
The solution I am working on is to implement a similar callback for
the indicators.
But as you rightly said, it would lead to maintenance problems since I
have not
done any Mac/Linux developement. I could easily take on the Linux too,
but I do
not even have a Mac box.
What I will do now is to create a .NET build with the extensions using
the C++/CLR,
which the ScintillaNET can used. I got here because ScintillaNET has
another major issue
I have being trying to address; design mode. Unless you have
SciLexer.dll in the global
search path, it does not work in the design mode, and the only
solution I found is to create
a C++/CLR assembly which uses the static library of the Scintilla.
For now, I will maintain it there until I find someone who will help
with the Mac version, then
we can propose the extensions to you.
Best regards,
Paul.