The reftest is testing "transparent" works as expected by drawing a
purple background once with purple and once with transparent and
expecting the same result. This works fine unless anti-aliasing happens
at rounded corners. The overdraw of the 2nd background changes the
antialiased pixels.
Fix this by explicitly setting the border radius to 0.
Also reindent the file to make it more readable.
The a11y headers are now listed with the main Makefile.am of GTK, and
GDK introduced deprecated headers, so we need to account for them for the
build of the introspection files.
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.
Otherwise, it is pretty hard to keep track of what
classes are missing from the list. As a consequence,
several of the existing classes were missing. Add those
at the same time.
We were applying response based heuristics, even if the button
is explicitly put in the headerbar. That broke button placement
in some epiphany dialogs, such as the Cookies one. Therefore,
restrict the heuristics to action widgets that are added through
gtk_widget_add_action_widget() or <child type="action">, where it
is not possible to specify placement explicitly.
There are plans to add session-dependent defaults to GSettings
(based on the newly standardized XDG_CURRENT_DESKTOP); until
then, the WM uses a different schema for its button-layout
setting in classic mode. So for the time being, do the same
and pick the alternative schema when XDG_CURRENT_DESKTOP
indicates that we are in a classic session.
(It's not pretty, but hopefully won't be with us for too long ...)
https://bugzilla.gnome.org/show_bug.cgi?id=731273
Pick up the setting from the org.gnome.desktop.wm.preferences schema
if available. It is slightly more involved than other settings, as
the actual button names used in the schema differ from the ones we
use, so we need an additional translation step.
https://bugzilla.gnome.org/show_bug.cgi?id=731273
When combining action child type with <action-widgets> to assign
response ids, we were not properly updating buttons that ended up
getting added to the headerbar before they have a response id.
Fix this by reapplying the headerbar button setup after parsing
<action-widgets>, and make sure to also update the suggested-action
style class.
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.
GtkKineticScrolling implements the actual physics laws for friction
and springs. When created, position/velocity/boundaries/constants are
given, so at every gtk_kinetic_scrolling_tick() it returns the current
position, and whether the system is in rest.
https://bugzilla.gnome.org/show_bug.cgi?id=729608
A multipress gesture takes care of link handling, and char/word/all
selection mode on selectable labels. A drag gesture is used for both
text selection and DnD checks on selectable labels.
A multipress gesture takes care of clicks, and where those happened.
If the click is meant to move the slider while pressed, the drag gesture
takes over, dragging the slider while active.
Widgets becoming insensitive won't receive further events, but there
could be chances the controllers don't get properly notified and reset
in those situations.
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...
Since commit 872fbfac the GtkWindowGroup was split out from the GtkWindow
sources, so include gtkwindowgroup.h to avoid C4013 warnings/errors
(implicit declaration of ...) on gtk_window_group_add_window().
