|
|
Scintilla Component Design |
Scintilla consists of three major layers of C++ code
The primary purpose of this structure is to separate the platform dependent code from the platform independent core code. This makes it easier to port Scintilla to a new platform and ensures that most readers of the code do not have to deal with platform details. To minimise portability problems and avoid code bloat, a conservative subset of C++ is used in Scintilla with no exception handling, run time type information or use of the standard C++ library and with limited use of templates.
The currently supported platforms, Windows, GTK/Linux, Cocoa and wxWidgets are fairly similar in many ways. Each has windows, menus and bitmaps. These features generally work in similar ways so each has a way to move a window or draw a red line. Sometimes one platform requires a sequence of calls rather than a single call. At other times, the differences are more profound. Reading the Windows clipboard occurs synchronously but reading the GTK clipboard requires a request call that will be asynchronously answered with a message containing the clipboard data. The wxWidgets platform is available from the wxWidgets site
This is a fairly small and thin layer over the platform's native capabilities.
The portability library is defined in Geometry.h and Platform.h and is implemented once for each platform. PlatWin.cxx defines the Windows variants of the methods and PlatGTK.cxx the GTK variants.
Several of the classes here hold platform specific object identifiers and act as proxies to these platform objects. Most client code can thus manipulate the platform objects without caring which is the current platform. Sometimes client code needs access to the underlying object identifiers and this is provided by the GetID method. The underlying types of the platform specific identifiers are typedefed to common names to allow them to be transferred around in client code where needed.
These are simple classes provided to hold the commonly used geometric primitives. A PRectangle follows the Mac / Windows convention of not including its bottom and right sides instead of including all its sides as is normal in GTK. It is not called Rectangle as this may be the name of a macro on Windows.
This is a simple class holding an expected colour. It is internally represented as a single 32 bit integer in BGR format with 8 bits per colour, but also provides a convenient API to fetch each component separately. As a platform might not be able to represent the exact desired colour if it doesn't have 24 bit depth available, it might not actually represent the exact desired colour but select a best fit that it can actually render.
Font holds a platform specific font identifier - HFONT for Windows, PangoFontDescription* for GTK. It does not own the identifier and so will not delete the platform font object in its destructor. Client code should call Destroy at appropriate times.
Surface is an abstraction over each platform's concept of somewhere that graphical drawing operations can be done. It may wrap an already created drawing place such as a window or be used to create a bitmap that can be drawn into and later copied onto another surface. On Windows it wraps a HDC and possibly a HBITMAP. On GTK it wraps a cairo_surface_t*. Other platform specific objects are created (and correctly destroyed) whenever required to perform drawing actions.
Drawing operations provided include drawing filled and unfilled polygons, lines, rectangles, ellipses and text. The height and width of text as well as other details can be measured. Operations can be clipped to a rectangle. Most of the calls are stateless with all parameters being passed at each call. The exception to this is line drawing which is performed by calling MoveTo and then LineTo.
Window acts as a proxy to a platform window allowing operations such as showing, moving, redrawing, and destroying to be performed. It contains a platform specific window identifier - HWND for Windows, GtkWidget* for GTK.
ListBox is a subclass of Window and acts as a proxy to a platform listbox adding methods for operations such as adding, retrieving, and selecting items.
Menu is a small helper class for constructing popup menus. It contains the platform specific menu identifier - HMENU for Windows, GtkMenu* for GTK. Most of the work in constructing menus requires access to platform events and so is done in the Platform Events and API layer.
The Platform class is used to access the facilities of the platform. System wide parameters such as double click speed and chrome colour are available from Platform. Utility functions such as DebugPrintf are also available from Platform.
The bulk of Scintilla's code is platform independent. This is made up of the CellBuffer, ContractionState, Document, Editor, Indicator, LineMarker, Style, ViewStyle, KeyMap, ScintillaBase, CallTip, and AutoComplete primary classes.
A CellBuffer holds text and styling information, the undo stack, the assignment of line markers to lines, and the fold structure.
A cell contains a character byte and its associated style byte. The current state of the cell buffer is the sequence of cells that make up the text and a sequence of line information containing the starting position of each line and any markers assigned to each line.
The undo stack holds a sequence of actions on the cell buffer. Each action is one of a text insertion, a text deletion or an undo start action. The start actions are used to group sequences of text insertions and deletions together so they can be undone together. To perform an undo operation, each insertion or deletion is undone in reverse sequence. Similarly, redo reapplies each action to the buffer in sequence. Whenever a character is inserted in the bufHTTP/1.1 200 OK Connection: keep-alive Connection: keep-alive Content-Disposition: inline; filename="Design.html" Content-Disposition: inline; filename="Design.html" Content-Length: 11157 Content-Length: 11157 Content-Security-Policy: default-src 'none' Content-Security-Policy: default-src 'none' Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 Oct 2025 02:05:23 UTC ETag: "cc99946786230fa1ad6e8048ef811ce7f1cda54a" ETag: "cc99946786230fa1ad6e8048ef811ce7f1cda54a" Expires: Thu, 18 Oct 2035 02:05:23 GMT Expires: Thu, 18 Oct 2035 02:05:23 GMT Last-Modified: Mon, 20 Oct 2025 02:05:23 GMT Last-Modified: Mon, 20 Oct 2025 02:05:23 GMT Server: OpenBSD httpd Server: OpenBSD httpd X-Content-Type-Options: nosniff X-Content-Type-Options: nosniff
|
|
Scintilla Component Design |
Scintilla consists of three major layers of C++ code
The primary purpose of this structure is to separate the platform dependent code from the platform independent core code. This makes it easier to port Scintilla to a new platform and ensures that most readers of the code do not have to deal with platform details. To minimise portability problems and avoid code bloat, a conservative subset of C++ is used in Scintilla with no exception handling, run time type information or use of the standard C++ library and with limited use of templates.
The currently supported platforms, Windows, GTK/Linux, Cocoa and wxWidgets are fairly similar in many ways. Each has windows, menus and bitmaps. These features generally work in similar ways so each has a way to move a window or draw a red line. Sometimes one platform requires a sequence of calls rather