This reverts commit f15f13a0fb.
This fix applied on master but it makes no sense here (where we have an
actual signal rather than just a property notify).
The signal needs to be emitted after the text insertion as at-spi gets
the text to compute the inserted text due to the AtkText::insert-text
signal not containing it.
Also adjust position to reflect changes to the offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=731429
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
If called when already popped down, warnings would be issued due
to priv->grab_pointer being unexpectedly NULL, this would happen
in regular operation when selecting items in appears-as-list mode.
So both add a NULL check for priv->grab_pointer, and bail out early
if the popup window is already hidden.
The signal handler for the visibility of menu items changing had the
wrong signature, resulting in the GParamSpec from the notify signal
being treated as a boolean (which was always true). This resulted in
items being added over and over and never being removed.
Fix that...
Make the relative_to widget the parent for a GtkPopover's
GtkActionGroup. This, for example, makes the menu model of a
GtkMenuButton find action groups attached to the button.
https://bugzilla.gnome.org/show_bug.cgi?id=729915
When selecting a swatch in a GtkColorChooserWidget the previously
selected swatch and the currently selected swatch are not redrawn. This
can leave the old swatch still marked with a checkbox even though a new
swatch has been selected.
Redraw the swatches after changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=727487
The incremental loading was broken by GtkIconHelper - queuing a
redraw is no longer sufficient to cause GtkImage to redraw with
the new pixbuf contents.
Pointed out by Jasper St. Pierre.
The keynav dialog is transient to the example window; since the
example window is now modal, we need to make the keynav dialog
modal as well, so it can receive input.
Problem pointed out by Jasper St. Pierre.
When the adjustment changes (due to e.g. a mouse wheel scroll) we update
the prelight. The part that un-prelights the previous prelight was
broken by the the pixel cache, as it called update_prelight in the
middle of the scrolling operation, where the windows were moved
but the tree_view->priv->dy was not changed to the new value. This
caused the updates to the pixel cache to go to the wrong place.
We fix this by fully doing the scroll before we update_prelight().
https://bugzilla.gnome.org/show_bug.cgi?id=728284
When activating an item using mnemonics GtkRecentChooserMenu does not select a
item before calling the item-activated signal thus
gtk_recent_chooser_get_current_uri() always return the last selected item
instead of the activated one.
Fixes Bug 495105 "Open recent file keyboard shortcuts do not work correctly"
This is not a great name to use in themes; instead, add the
menuitem class, so themes can use .button.menuitem for styles
that are specific to menuitem-like buttons.
