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.
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
The emoji chooser gets disposed already, because it is attached
to the toplevel as a popover. Doing it again when the object data
is cleared is leading to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=787103
Since the move from button-press to gesture events, Shift-clicking did
not work to start a selection (from none) or truncate an existing one.
This was due to the code being copy-pasted around and some logic being
broken in the process. This makes both of those work as they should, by
shuffling it again so the end result is the same as before. Highlights:
(1) ::button-press if extending due to a single press would call
set_positions(tmp_pos, tmp_pos), which is what made the Shift+click to
create a selection work. That was lost. Add it back to make that work.
(2) ::button-press in the “Truncate current selection” branch would not
execute all the stuff around “extend_to_left”, as that was the else
case. So, set extend_selection = FALSE so we skip over that later on.
(3) BUT! This Truncate case never fired because it was in the else
branch of if (in_selection())! Of course, it must be in the true branch.
(4) The IM context was not reset if the Shift-click occurred within an
existing selection, only if it did not. In ::button-press this was the
first thing done if extending a selection, regardless. Make it so again.
https://bugzilla.gnome.org/show_bug.cgi?id=780750
Add an "Insert Emoji" item to the context menu in entries.
We also add a show-emoji-icon property, which when set to
TRUE, will add an icon that can be clicked to bring up
the Emoji chooser.
Our ::query-tooltip handler first checks whether the pointer is over any
of the icons, returning their tooltip if so, and if not chains up to
Widget::query-tooltip in order to show the text for the widget overall.
But ensure_has_tooltip(), which exists to update :has-tooltip based on
whether ::query-tooltip is needed, only set :has-tooltip to TRUE if any
icon had a tooltip, without caring whether the widget as a whole does.
That is asymmetrical and meant that if the Entry had a tooltip, but
subsequently all icons had their tooltips unset, :has-tooltip would be
set to FALSE, and hence the tooltip for the widget would become lost.
The fix is to set :has-tooltip to TRUE if the widget has a tooltip of
its own, and we only need to check the icons if that is not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=785672
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
And refurbish cursor management to be set on the GtkWidget. The
input window is not needed anymore to receive events either.
This is no longer set through the GdkWindow, so use the private
GtkWidget API.
We can e.g. get the entry dispose()d and a focus_out event after that
(because the toplevel unsets the focus which previously was the entry).
We then later use priv->current_pos in a call to pango API which makes
sure the given index is valid for the given layout. Since we lazily
create a GtkEntryBuffer in get_buffer() and a PangoLayout lazily in
gtk_entry_create_layout, these 2 are always valid but don't match
priv->current_pos in this situation.
Fix this by resetting priv->current-pos in dispose().
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Ori Avtalion <ori@avtalion.name>
Date: Tue Apr 20 08:06:23 2010 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
See the implementation of gtk_entry_create_layout():
pango_attr_list_splice() is used to add the PangoAttrList of the preedit
string. And that is done *after* applying the PangoAttrList of the
"attributes" property.
https://bugzilla.gnome.org/show_bug.cgi?id=776868
