Win32 does not have alpha channel currently ; fix the check
for this, so trying to enable CSDs on this platform will
not "succeed" and crash the app anymore.
Partially fixes gtk3-widget-factory.
Since commit 7c2a5072 the gtkdbusgenerated.[c|h] are not included in the
dist tarball and thus have to be generated, which broke the Visual C++
builds.
This patch adds property sheets and custom build rules for the Visual C++
projects so that gtkdbusgenerated.[c|h] will be generated upon building the
GTK+ DLL sources.
This also tells people building GTK+ from the projects that they need to
have Python 2/3 installed and the Python interpretor needs to be in their
PATH before building GTK+ from the projects.
-Improve optimization a bit for broadwayd, by enabling link time code
generation
-Add PlatformToolset tag for the Visual C++ 2010 projects, to ease
transition to Visual C++ 2012/2013
Ignore the "show-desktop" property on GtkPlacesSidebar for the
defaultvalue test.
Currently, "make check" is passing because it runs the test under a xvfb
with no XSETTINGS provider, so we see the Gtk default value. No matter
what we set the default value to in Gtk, however, there will be some
desktop environment in which someone running the installed test outside
of an xvfb will get the wrong result. Best to ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
Change the GtkSettings default for "shell-shows-desktop" back to TRUE
and also change the default value of the "show-desktop" property on
GtkPlacesSidebar so that the defaultvalue test passes.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
This is so we always have the latest information given by XRandR (or other), and not
rely on Core protocol information that might not have been updated yet.
This is specially visible when a monitor is connected (less frequent) or disconnected
(much more frequent), callbacks on GdkScreen::monitors-changed that call
gdk_screen_get_width/height() could get the screen size previous to the monitor
rearrangement.
So in order to fix this, keep track of the latest monitors information, and calculate
the bounding box in order to know the screen size.
https://bugzilla.gnome.org/show_bug.cgi?id=715029
Return values of g_variant_get_child_value() were not unreffed
correctly together with one value returned by g_variant_get().
Use g_variant_get_data() instead of copying each byte separately.
https://bugzilla.gnome.org/show_bug.cgi?id=712799
Instead, use the monitor's work area.
This might have unforseen side effects that warrant a later revert, such
as:
- Apparently some WMs assume maximizing when a window is maximum screen
size.
- WMs might not shrink the window by the decorations' size when it tries
to be fullscreen.
- Applications might have buggy size request code that causes weirdly
sized windows.
Scroll valuators were being just appended again and again, leading
to 1) a growing memory issue anytime a device changed 2) the first
scroll valuators to stay permanent on the application lifetime, as
the first stored valuators would always match.
https://bugzilla.gnome.org/show_bug.cgi?id=705203
Use info available in Avahi TXT records for creation of gtk printer
and request details when needed (through gtk_printer_request_details()).
If there is a printer advertised on Avahi by a remote CUPS server
try to get its PPD file at first or get its capabilities through an IPP
request if it fails.
https://bugzilla.gnome.org/show_bug.cgi?id=712751
When downscaling images, Cairo apparently uses algorithms different
enough to make this test trip over. So add the downscaled image as the
reference instead of downscaling the previous reference image.
Fixes the border-image reftest. For real now.
The new downscaling code in Cairo doesn't allow this test, so we remove
the CSS that made the border downscaled.
So the test does test less now, but it still tests the repeat modes of
border images.
Passive grabs may take pointer focus out of the application, even though
the pointer didn't leave the window, but those events still trigger resetting
of the scroll axes. This is most visible with compiz, and possibly other
reparenting WMs, where passive grabs happen on the WM-managed window that
is a parent of the application toplevel.
As it is not possible to have scrolling happening on the timespan a passive
grab takes action, it is entirely safe for GTK+ to assume none happened if
it gets a crossing event of that nature.
https://bugzilla.gnome.org/show_bug.cgi?id=699574#c33
