This builds upon the GtkTextHistory helper to provide undo and redo support
for the GtkTextView widget and GtkTextBuffer object.
You can undo/redo using familiar shortcuts such as Primary+Z,
Primary+Shift+Z, ad Primary+Y.
Developers that wish to disable undo, should set the
GtkTextBuffer:enable-undo property to FALSE.
You can wrap irreversible actions
gtk_text_buffer_begin_irreversible_action() and
gtk_text_buffer_end_irreversible_action(). This will cause the undo stack
to drop all undo/redo actions and the changes made between them will be
the "initial state" of the buffer.
Calling gtk_text_buffer_set_text() will do this automatically for you.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
This API allows specifying a GType and va_args of a value of that type
to set the clipboard contents. This massively simplifies setting weird
object types into the clipboard.
2 example patches included in this patch are the GtkTextBuffer and the
file list in the file chooser.
Using gobject-introspection, this should work without specifying the
type, so that you can literlally say
clipboard.set ("Hello World")
or
clipboard.set (pixbuf)
which is why I've also marked all other setters as (skip). They just
exist in C as wrappers for type safety reasons.
Instead of using GtkClipboard and handling everything ourselves, we now
put GtkTextBuffer into the GdkClipboard and register (de)serializers for
text/plain.
This affects a few apis, such as gtk_text_iter_get_pixbuf,
gtk_text_buffer_insert_pixbuf and GtkTextBuffer::insert-pixbuf,
which have all been replaced by texture equivalents.
Update all callers.
It's unused. Plain text is not using that framework, neither is
in-process same-display transmission.
So it was only useful for sharing text with custom tags across
applications, and nobody is doing that.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A first attempt added boolean return values to know if @iter has been set to
the exact location, but it breaks Python and JS bindings because the out
parameter is already a return value in those languages.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
This reverts commit a9a1c00cc9.
Unfortunately, adding the boolean return broke both the python
and javascript bindings, since they now return a tuple consisting
of the boolean and the out argument.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A boolean is returned to know if @iter has been set to the exact
location.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
This commit adds the GtkTextTag:underline-rgba and :strikethrough-rgba
properties and the necessary plumbing to apply these colors in GtkTextLayout.
With this change, you can alter the color of underlines including those
of type PANGO_UNDERLINE_ERROR.
You might want to alter the underline color to differentiate between
spelling and grammer mistakes. In code editors, it is convenient to
differentiate between errors and warnings.
Note that the GtkTextAppearance struct is public ABI and has no spare
room for new fields, so we are resorting to some tricky packing to store
the colors in the unused pixel field of the fg_color and bg_color structs.
This packing is accomplished by the macros in gtktextattributesprivate.h.
Signed-off-by: Christian Hergert <christian@hergert.me>
https://bugzilla.gnome.org/show_bug.cgi?id=402168
NULL was returned in case of an empty last line. Every users needed to
special-case this. Now it will return the expected result: char_len of 0
with one PangoLogAttr.
In compute_log_attrs(), 'paragraph' will be the empty string "" with
'char_len' == 0.
pango_get_log_attrs() works fine with an empty string, it will return
one correct PangoLogAttr (because there is one text position for the
empty string).
It fixes the unit tests for gtk_text_iter_is_cursor_position().
https://bugzilla.gnome.org/show_bug.cgi?id=156164
- only one blank line is enough to separate code sections.
- the 'signals' variable was in the middle of function prototypes.
- compare pointers to NULL in some conditions ("if(blah) should be used
only if blah is a boolean variable). It makes the code clearer.
- various other things.
Although there is the "changed" signal, it is more correct to notify the
"text" property too. It can be useful for a small text view, where the
text is saved e.g. to gsettings with a binding to the text property.
The "text" property includes only the text, not child widgets or images,
so the notify signal is sent too many times (also for child widgets and
images), but it's not a big problem.
https://bugzilla.gnome.org/show_bug.cgi?id=624791
This is expected to happen on wayland and other platforms with no primary selection,
and just leads to the selected text being cleared after any attempt to change the
text selection itself through either mouse/keyboard.
Returns NULL in case of a duplicated tag name in the tag table. It is
still a programmer error to duplicate a name, but if it happens the
behavior is a little nicer (and hopefully doesn't crash).
https://bugzilla.gnome.org/show_bug.cgi?id=614717
