Focusing the text entry without selecting all the text is needed in
some places (GtkTreeView, and some uses of GtkSearchEntry) so
create a private helper to avoid replicating the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=700787
We do this by making the ::populate-popup signals a little more
flexible. They used to just accept a GtkMenu as argument, now
they can take a menu or a toolbar. To not break the expectations
of existing callbacks, we only emit ::populate-popup with a toolbar
if the :populate-toolbar property is TRUE.
Don't set handles mode to none if the event has send_event set.
For consistency with GtkEntry, also make GtkTextView keep the
handle mode on buffer changes.
We only draw the main entry on should_draw (widget->window), because
otherwise we also draw it on the GtkTextHandle widgets.
This is necessary due to the recent change for that to not return
TRUE and swallow the rest of the drawing operation.
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
With pango handling changes to the PangoLayout there now is no
style changes that can affect the layout for the entry, so we don't
have to reset the layout whenever the style is updated.
Instead of using gtk_style_context_get_font() in
pango_context_get_metrics(), use pango_context_get_font_description().
The context contains the font description we are about to use after all.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions (This is more
important though on GtkTextView, as inverted handles may
obscure portions of the selected text, good for consistence
though)
This commit moves all the entry completion implementation
into gtkentrycompletion.c. It also gets rid of an unnecessary
completion_device member in GtkEntryPrivate.
Entries don't expand vertically if they are given pixbufs larger
than the calculated height for the current font, resulting in
cropped icons, so force the pixbuf to be rescaled so it fits
on the entry allocated size.
https://bugzilla.gnome.org/show_bug.cgi?id=678087
In gtk_entry_get_icon_pixbuf() we unreference the pixbuf that
_gtk_icon_helper_ensure_pixbuf() gives us back, since the function
doesn't return a reference, and by doing so we're able to return the
reference owned by the cached icon helper.
Since the icon helper method can return NULL though, if no icon
properties have been set on it, guard for != NULL before unreffing the
pixbuf, as that would cause a critical warning.
https://bugzilla.gnome.org/show_bug.cgi?id=679537
When inline-selection is set, and the completion popup is showing,
pressing left abruptly jumps to the beginning of the entry text.
This is not expected, since the cursor is at the end of the text before
the left key is pressed, and this behavior is completely inconsistent
with how an entry would normally behave.
The behavior can be observed in Epiphany by selecting a completion match
and pressing left.
This patch changes the code so that it just runs the default entry key
press keybindings in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=677915
Remove the 'you shall not connect' message from this signal.
While it is a keybinding signal, using it from applications is
fine and, in fact, expected.
Store the device, and unset private fields whenever the device
is shadowed by another GTK+ grab, so popping up menus while
selecting (i.e. press-and-hold) doesn't leave the entry in a
confused state.
No need to subtract focus line width again, since the progressbar is
rendered starting at (0, 0).
This also fixes the entry-progressbar-coloring reftest.
When a subclass of GtkEntry (e.g. GtkSpinButton) resizes the available
text area (by overriding the get_text_area_size vfunc), we need to
ensure we don't draw a possible progressbar over the part that got
removed from the text area.
This fixes drawing a progressbar in GtkSpinButton and in its subclasses,
such as GimpSpinScale, and makes Mitch happy too!
Subclasses of GtkEntry could set a larger height request, so we need to
apply the same calculations to the insertion cursors than we do on the
PangoLayout to render it centered under all circumstances.
The progressbar inside GtkEntry has a progress-border style property,
which is actually the margin of the progressbar inside the GtkEntry
allocation.
Use a CSS margin instead of reading the progress-border property.
Don't assume the padding of the icons is the same padding of the rest of
the entry.
This also allows to set different paddings for left and right icons.
Instead, fall through to the default handler after closing the
completion. This has the advantage of letting the file chooser entry
capture the tab key properly, so one can't accidentally move out of the
entry by pressing tab while the completion is popped up.
I also suspect it fixes bugs with weird tab keys and shift/ctrl
oddities. But who knows...
The new function provides an API that takes the PangoLayout and index
as input params, this way it handles strong and weak cursors internally
factoring out all code duplicated in the widgets that need to render
cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
When multiple pointers are in play, we need to be careful
not to loose track of the device between receiving a button
press and popping up a menu.
https://bugzilla.gnome.org/show_bug.cgi?id=663396
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
which are SHIFT and MOD2 on the Mac, and SHIFT and CONTROL otherwise.
Use the new define all over the place and rename variables and
members to not say "shift" or "control".
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Ensure that text and selection boundaries are in a
consistent state when we emit notifications, that ::insert-text
and ::delete-text are emitted before any changes, and that
::changed is emitted after property notifications when inserting
or deleting text.
We want save, clip, draw1, restore, save, clip, draw2, restore
and not save, save, clip, draw1, restore, clip, draw2, restore
Functionally the same thing, but not as obvious
