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
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
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
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
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 31c05771e9)
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 8e85f55240)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
We've already set ->use_es correctly at context creation time, all this
can possibly do is change our mind about what kind of GL we're using.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773180
xdg_shell v6 allows grabless popups, whose behavior is not that
different from override redirect windows with no grab to take
keyboard input (and pointer events outside).
This means we can relax the requirement to have a grab before
creating an xdg_popup. The warning is still useful to have so
people stop relying on gdk_window_show();gdk_device_grab() being
an ok pattern to popup a window, it's been moved to wayland
implementation of gdk_device_grab() instead, so we warn if trying
to grab a GDK_WINDOW_TEMP window that's already visible.
https://bugzilla.gnome.org/show_bug.cgi?id=771694
ClutterEmbed on Wayland uses a subsurface and relocates it on configure
events, but when placed within a scrolled window, no configure event is
emitted and the ClutterEmbed subsurface remains static.
Emit a configure event for native windows in GdkWindow's internal
move_native_children() so that custom widgets relying on configure
events such as ClutterEmbed can relocate their stuff.
Similarly, when switching to/from normal/maximized/fullscreen states
which change the shadows' size and possibly shows/hides a header bar,
we need to emit a configure event even if the abs_x/abs_y haven't
changed to make sure the subsurface is size appropriately.
https://bugzilla.gnome.org/show_bug.cgi?id=771320https://bugzilla.gnome.org/show_bug.cgi?id=767713
Calling eglGetDisplay forces libEGL to guess what kind of pointer you
passed it. Different EGL libraries will do different things here, and in
particular glvnd will do something different than Mesa. Since we do have
an API that allows us to explicitly type the display, use it.
The explicit call to eglGetProcAddress is working around a bug in
libepoxy 1.3, which does not understand the EGL concept of client
extensions. Since it does not, the normal epoxy resolver for
eglGetPlatformDisplayEXT would not find any provider for that entry
point, and crash when you attempted to call it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
EGLDisplays are already opaque pointers, and eglGetDisplay returns an
EGLDisplay not a pointer to one.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
Opaque region, margin and input region were only being synced when a cairo
paint happened. That caused GL paints to sometimes end up with bad state.
Move calls to sync state to gdk_window_impl_wayland_end_paint.
https://bugzilla.gnome.org/show_bug.cgi?id=771553
Setting the shadow width earlier as done with commit 4cb1b96 to address
bug 771561 proved to cause unexpected side effects on size_allocate
signal propagation.
As the window is sized correctly earlier, the size_allocate signal is
not emitted again in gtk_widget_size_allocate_with_baseline() which
prevents clutter-gtk from relocating its child widget correctly.
To avoid this issue, revert commit 4cb1b96 but make sure the values
passed as min and max size is never negative in Wayland as this is a
protocol error.
With this, the min/max size will be wrong for a short amount of time,
during the state transition, until the shadow width is updated from
gdk_window_set_shadow_width().
This approach is much safer and less intrusive than changing the
size_allocate logic in gtk.
This reverts commit 4cb1b9645e.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
The scroll motion values are subject of batching and scaling. Either
through scaling or by using a touchpad smooth scroll motion changes
below 0.5 are possible.
https://bugzilla.gnome.org/show_bug.cgi?id=769554
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
A popup may have moved and resized when configured. Make sure every
layer knows about this and call gdk_window_move_resize() with the
configured dimension and position. This won't actually move the
window, but might resize it.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
The result of move_to_rect, received from the xdg_popup.configure
event, needs to be translated to the correct coordinate space; that is
from real parent window geometry to coordinates relative to the gdk
window set as transient-for.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Use a helper to translate a coordinate from non-real GdkWindow parent
to window geometry coordinate space of the real GdkWindow parent,
meaning the coordinate space of the GdkWindow of the parent used as a
xdg_popup parent where (0, 0) is inside of the shadow margin.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
When using the dynamic positioner (i.e. positioning from move_to_rect)
we can always rely on having a proper transient-for to position
relative to, so lets drop the ignored parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Move the code used for calculating the result of move_to_rect
(final_rect, flipped_rect etc) closer to the other move_to_rect
functions (i.e. next to create_dynamic_positioner), and let the
xdg_popup configure handler just call the calculation function.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
If an application umaps the toplevel from its popup callback, this can
lead to a protocol error.
Make sure we mark popup parent and use that to check if their parent is
the toplevel being unmapped in which case we shall unmap the popup first
to avoid the protocol error.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770906
RandR 1.5 is enabled on VirtualBox guest of Fedora 25 but
XRROutputInfo->name is "default". If init_randr15() does not
return TRUE, the monitor size sets 0 because gdk_screen_get_width()
returns 0.
This problem causes GtkStatusIcon not to show the activate menu.
https://bugzilla.gnome.org/show_bug.cgi?id=771033
