Add a Ctrl+Shift+T shortcut to toggle the widgets direction,
to give the user control in the rare cases where a different
direction is appropriate.
This is a backport of 0b33abe44b4f42cba (without the context
menu item, since that needs new strings).
Now that we are no longer relying on keyboard direction to
determine the direction of empty entries, there's no need
for a direction-changed signal handler.
Instead of trying to derive a direction from content and
keyboard layout, just let the widgets direction prevail.
This avoids irritating jumping text on focus in, in situations
where the directions are mixed.
See discussion in !7971
This is a backport of d0bfed5195be99c21e.
It is at least theoretically possible that gtk_entry_get_pixel_ranges
will return no ranges, and we should handle that without an
out-of-bounds access or segfault.
Doing reset() on the text widgets after commit and delete_surrounding
is still too eager for some IMs (e.g. those that expect being able
to commit text while keeping a preedit buffer shown).
However, reset() is more of a "synchronize state" action on Wayland,
and it is still desirable to do that after changes that do come from
the IM (e.g. requesting the new surrounding text and cursor/anchor
positions). Notably here, the text_input protocol may still come up
with a preedit string after this state synchronization happens.
Shuffle the code so that the text widgets do not reset() the IM
context after text is deleted or committed, but the Wayland IM does
apply its practical effects after these actions happen. This keeps
the Wayland IM fully up-to-date wrt text widget state, while not
altering the ::commit and ::delete-surrounding-text behavior for
other IM context implementations.
When the IM commands the GtkText to delete text, the cursor position
would change, and so would the surrounding text. Reset the IM context
so that these updates are properly picked up by the IM.
Fixes backspace key behavior in the GNOME Shell OSK, since that relies
on the surrounding text being properly updated for the next iteration.
Resetting the IM on IM updates is too eager and indeed the simple
IM context doesn't like that this happens in the middle of dead
key handling.
We however want to reset the IM after actual text buffer changes
(say, a committed string) moved the cursor position, altered the
surrounding text, etc. So that the IM implementation does know to
update its state.
Since there is going to be an actual IM reset anyways, it does
no longer make sense to try to preserve the old priv->need_im_reset
status during commit handling.
Resetting the IM on IM updates is too eager and indeed the simple
IM context doesn't like that this happens in the middle of dead
key handling.
We however want to reset the IM after actual text buffer changes
(say, a committed string) moved the cursor position, altered the
surrounding text, etc. So that the IM implementation does know to
update its state.
During entry widget manipulation (inserting or deleting text via keyboard)
the IM context is reset somewhat early, before the actual change took place.
This makes IM lag behind in terms of surrounding text and cursor position.
Shuffle these IM reset calls so that they happen after the changes, and
ensure that the IM is actually reset, since that is currently toggled on
a pretty narrow set of circumstances.
This is not only a GdkEventButton but can also be a GdkEventTouch.
Having this annotation wrong causes bindings code to fail whenever a
wrongly typed event comes through.
On touch, the popup shown shall contain the 'select-all' button
only if a selection is in progress and if the entry is editable.
Let the button be shown always if selectable so that it’s more helpful.
It's currently used only to not include the insert emoji option in the
context menu, but it's still possible to show the emoji chooser in both
GtkEntry and GtkTextView using the key bindings.
See also https://bugs.webkit.org/show_bug.cgi?id=205609.
We need to take the device scale into account, like it is done in
gdkwindow.c.
This fixes wrongly placed DnD surfaces in scaled contexts on X11
as well as Wayland.
gtk_entry_event's goal is to detect if a specific event concerns one of the two
entry icons. It can happen that this function is called during initialization
and/or before the entry is realized. In this case the entry icons (and the
event) will not yet have an associated window. The code should consider the
aforementioned situation and avoid matching a icon and an event with no
associated windows.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1366
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
This was comparing the input position, which is documented as being
relative to the top-left of the Entry allocation, to icon allocations
that were not adjusted accordingly. This could result in tooltips for
icons not being shown in various conditions, since the ::query-tooltip
handler uses get_icon_at_pos() to check whether to show an icon tooltip.
The fix is to compare to the icon border box, not border allocation, as
CssGadget::get_border_box() adjusts relative to the widget. Better yet:
we can just make CssGadget::border_box_contains_point() compare for us.
Delegating to Entry::get_icon_area(), which manually reimplements
CssGadget::get_border_box(), would also work, but this is simpler.
https://bugzilla.gnome.org/show_bug.cgi?id=780938
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().
https://bugzilla.gnome.org/show_bug.cgi?id=785255
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
