After building GDK with broadway, we need to copy the GDK DLL from
[Release|Debug]_Broadway\bin to [Release|Debug]\bin, so that the
introspection builds can be done normally with CFG=[Release|Debug]. As we
renamed the projects, we needed to update the property sheets that does
the copying, which was accidently missed. Fix that.
Unlike other container widgets, GtkStack would allocate its children
prior to moving its windows, which might prevent further valid size
allocation signals to be emitted.
Re-order the size allocation of child widgets to be performed after
moving the GtkStack windows.
Thanks to Owen for spotting the real issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=767713
We want to look for the gdk-pixbuf-2.0 package, and we should leave a space
between -ldwmapi and -lzlib1 when we enable Broadway.
Also copy the generated gdk-3.0.pc and gtk+-3.0.pc as gdk-win32-3.0.pc and
gtk+-win32-3.0.pc respectively, to be in-line with the autotools builds.
As in the last commit on gdkdisplay-win32.c, we need to define that to be
0x0600 (Vista) or later so that the items needed in the Windows headers be
activated.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
... to be for Vista (0x0600) or later. This is so that the necessary
items in the Windows headers be activated so that the code will build
properly on mingw-w64, and we already require Vista or later for GTK+.
Thanks Ting-Wei Lan for pointing this out.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
This fixes a DOS where any app can cause all running gtk apps
to use arbitrary amounts of memory.
Originally reported against mate-panel, where running a big slideshow
in eye-of-mate caused increasing RAM usage in mate-panel.
v2: Hardcode the value
Signed-off-by: Lauri Kasanen <curaga@operamail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773587
The monitors are already in scaled pixels, so scaling again when retrieving
the screen size is wrong.
With GDK_SCALE unset, the initial monitor sizes are unscaled, and when the
xsettings client sets a scale > 1, the monitor sizes should be updated.
The end result is that the monitor sizes start out wrong, and get
corrected on the first xrandr event, while the screen size starts out
right and becomes wrong after the event.
This patch fixes Firefox misplacing menus and popovers when the xrandr
configuration changes while it is running.
Fix for the X11 side of
https://bugzilla.gnome.org/show_bug.cgi?id=772202
Making sure the surfaces are using the same scale factor makes it more
likely a fast path will be used when pixman gets involved, as pointed
out by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=772075
We are currently truncating job names to 255 bytes, because that's the
maximum allowed length of job-name attribute in CUPS. This is a CUPS
limitation that GtkPrintOperation shouldn't need to know, and it
shouldn't affect other backends, that might have other limitations or
even no limitation at all. This has another side effect, that what you
set as GtkPrintOperation:job-name could be different to what you get if
the property is truncated, this is not documented in
gtk_print_operation_set_job_name(). So, I think the job name should be
truncated by the CUPS backend, right before setting the job-name
attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=774097
The GApplication platform data may contain a startup ID that on X11
is used to set the startup notification ID when activated. Do the
same on the wayland backend to make startup notifications work for
DBus-activated applications where the DESKTOP_STARTUP_ID environment
variable is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
GtkLevelBar supports adding custom offsets as style classes, and they
are applied whenever the :value property matches. The current code,
however, only updates any CSS nodes when an offset is found, causing
it to not update when a discrete value changes but no custom offset
is added.
Fix that by always updating the CSS nodes.
https://bugzilla.gnome.org/show_bug.cgi?id=773799
This way we can recommend that applications use the
fullscreen_on_monitor() API on both X and Wayland otherwise they'd
have to keep a path for each backend to achieve this functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=773857
