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
gdk_wayland_window_attach_image() is normally called from
gdk_window_end_paint() to notify the compositor of newly staged drawing.
If any of the drawing code inadvertently dispatches the wayland event
loop (for instance with a gdk_flush() call), then it's possible that by
the time gdk_window_end_paint() is called, the staged drawing is already
destroyed.
This commit bypasses the attach_image call in scenarios where the staged
drawing is prematurely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=773274
Update the GDKGL implementation:
-Allow legacy contexts to be created.
-Use finer-grained attributes to ask for a pixel format when possible,
which also adds support for anti-aliasing
In fact the changes here are required for GTKGL to work properly on
Windows for 4.x.
Note that creation of gles contexts are not done here, as the system does
not support such contexts directly on Windows, but only through means such
as ANGLE, which is a totally different issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=773528
For some reason we end up allocating the colorplane widget
before it is realized, and then never initialize the surface.
Fix this by explicitly doing it on realize.
https://bugzilla.gnome.org/show_bug.cgi?id=773474
GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a
legacy profile from the underlying windowing system, the OpenGL version
will be fixed to 3.0. If that happens, we need to set the legacy bit on
the GdkGLContext, since that bit will be used to determine the version
and type of GLSL shaders that will be used by application and toolkit
code alike.
(cherry picked from commit 31c05771e957f2f54fb197a391b63e6ef3394a26)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Now that the use_es field is an int with a possible negative value, we
cannot use it its truth value directly; we need to check if it's a
positive value, instead.
(cherry picked from commit 8e85f55240d4e3a2191c7945c7e76a6f20a4d32d)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
With best-effort, try to use gdk_window_move_to_rect() more often, when
all pieces fit together. For the non-legacy paths to be triggered for
when gtk_menu_popup_for_device() or gtk_menu_popup() were used, the
following conditions must be met:
1) There is no custom positioning function specified
2) The menu is attached to a widget (using gtk_menu_attach_to_widget())
3) There is a associated grab device
https://bugzilla.gnome.org/show_bug.cgi?id=772922
