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
