You can now press Ctrl+Shift+Up/Down in a GTextEditor and the currently
selected line(s) will all move together one step up/down.
If there is no selection, we move the line with the cursor on it. :^)
Since on_change handlers can alter the text document we're working on,
we have to make sure they've been run before we try looking at spans.
This fixes some flakiness when a paint happened before HackStudio had
a chance to re-highlight some C++ while editing it.
The design where clients of GTextEditor perform syntax highlighting in
the "arbitrary code execution" on_change callback is not very good.
We should find a way to move highlighting closer to the editor.
With this patch, you can now assign the same GTextDocument to multiple
GTextEditor widgets via GTextEditor::set_document().
The editors have independent cursors and selection, but all changes
are shared, and immediately propagate to all editors.
This is very unoptimized and will do lots of unnecessary invalidation,
especially line re-wrapping and repainting over and over again.
This patch decouples GTextDocument and GTextDocumentLine from the line
wrapping functionality of GTextEditor.
This should basically make it possible to have multiple GTextEditors
editing the same GTextDocument. Of course, that will require a bit more
work since there's no paint invalidation yet.
The idea here is to decouple the document from the editor widget so you
could have multiple editors being views onto the same document.
This doesn't work yet, since the document and editor are coupled in
various ways still (including a per-line back-pointer to the editor.)
It's now possible to give GTextEditor a vector of Span objects.
Spans currently tell the editor which color to use for each character
in the span. This can be used to implement syntax highlighting :^)
There were various little mistakes in the width calculations used by
the line-wrapping layout code.
With this patch, we should no longer see the horizontal scrollbar get
enabled with line-wrapping enabled. I will hide the scrollbar in a
separate patch.
This is not finished, but since the feature is controlled by a runtime
flag, the broken implementation should not affect users of this widget
too much (in theory :^).)
- GTextRange find(const StringView& needle, const GTextPosition& start)
This function searches for the needle in the haystack (the full text)
and returns a GTextRange for the closest match after "start".
If the needle is not found, it returns an invalid GTextRange.
If no "start" position is provided, the search begins at the head of
the text document. :^)
This macro goes at the top of every CObject-derived class like so:
class SomeClass : public CObject {
C_OBJECT(SomeClass)
public:
...
At the moment, all it does is create an override for the class_name() getter
but in the future this will be used to automatically insert member functions
into these classes.
Instead of LibGUI and WindowServer building their own copies of the drawing
and graphics code, let's it in a separate LibDraw library.
This avoids building the code twice, and will encourage better separation
of concerns. :^)
