If a window is configured with a fixed size (it's tiled, maximized, or
fullscreen), ignore any resize call that doesn't respect this. The set
size will instead be saved, when appropriate, so that the new size is
used when e.g. unmaximizing.
This makes it possible to call 'gtk_window_resize()' while the window is
maximized, without the window actually changing size until it's
unmaximized. Changing size to a non-maximized size is a violation of the
xdg-shell protocol.
An application may want to set a fallback size of a window while still
mapping maximized. This is done by calling gtk_window_resize() before
gtk_window_maximize() and before gtk_window_show(). When the window is
mapped, it should have a maximized size, and if it eventually is
unmaximized, it should fall back to the size from the earlier
gtk_window_resize() call.
What happens before this commit is that the initial window size ends up
respecting the first gtk_window_resize() dimensions, and not the window
dimension configured by the Wayland display server (i.e. maximized
dimensions).
Fix this by postponing any configure events until we received our
configuration from the display server. If we got one with a fixed size
(e.g. we're maximized, tiled etc), we use that, otherwise we look at the
one that was previously configured by gtk which corresponds to the
"preferred" size when not being maximized.
This fixes Firefox being started in a maximized state when using the
Wayland backend.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2538
If NULL is returned, probably the client shouldn't advertise the
mimetype. Make it sure we forget entirely about the attempt to
cache this mimetype, as it'll be mistaken as pending otherwise.
Dropping this cached selection will in consequence close the fd
of all pending readers, which seems appropriate for NULL content.
https://gitlab.gnome.org/GNOME/gtk/issues/2456
The only way to have G_IO_ERROR_CANCELLED in the write callback
goes through having the array of pending writers already cleared.
It should not access the invalid AsyncWriteData and StoredSelection
in that case.
Cache separately the selection contents for each given window/selection/atom
combination, and keep the requestors separate for each of those.
This allows us to incrementally request multiple mimetypes, and dispatch
the requestors as soon as the data is up. This stored selection content is
cached until the selection owner changes, at which point all pending readers
could get their transfers cancelled, and the stored content for the selection
forgotten.
On Wayland, opening and closing a `GdkDisplay` generates a coupe of
warnings at runtime:
```
GLib-GObject-WARNING **:
invalid cast from 'GdkWindowImplWayland' to 'GdkWindow'
GLib-GObject-WARNING **:
invalid cast from 'GdkWaylandWindow' to 'GdkWindowImplWayland'
```
This is from `gdk_window_impl_wayland_finalize()` which tries to cast
the given GObject to a `GdkWindow` while it's a `GdkWindowImplWayland`.
Use the correct type casting of objects to avoid the warnings.
The sed -i flag is non-standard, and may not be available in all
implementations.
The meson build already requires wayland >= 1.14.91 and uses
private-code, so just do that in the autotools build as well.
We are interested in changing the owner window, so the upper bits know
that it is not this client who owns the selection. We are still not
interested in unsetting the selection desktop-wide though, so only avoid
emitting the relevant events then.
The same reasonings than in commit 7a891eeb6d apply otherwise.
This should just be called by the upper layers (and result in
wl_data_device.set_selection, etc). We should not trigger this within
the backend otherwise.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/878
This should only be explicitly unset (face to the windowing) on
gdk_selection_owner_set() with a NULL window. Other circumstances
(eg. selection being taken over by another client) should just
trigger the SelectionClear event in GDK internally.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/878
The event may end up freed after delivery, ensure to keep the data we need
in order to emit the matching emulated crossed event matching a proximity
event.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
The code managing this accounting mixed seat and tablet output lists,
can't bode well. Fixes invalid reads on list elements, as there are
dangling pointers.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
This reverts commit 6d545b6d03.
Reverting as this broke multi DPI systems, where a client is expected to
render at scale = 1 if it is only visible on a scale = 1 monitor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2129
The xdg_output.done event is deprecated in xdg-output v3, so clients
need to rely on the wl_output.done event instead.
However, applying the changes on the fist wl_output.event when using
xdg-output v3 may lead to an incomplete change, as following xdg-output
updates may follow.
Make sure we apply xdg-output events on wl_output.done events with
xdg-output v3.
https://gitlab.gnome.org/GNOME/gtk/issues/2128
This fixes an issue where stylus proximity in/out events emulate enter/leave events.
The emulated events didn't contain the correct slave device and therefore the
resulting device class was set incorrectly. Crossing event emulation now also
works with slave devices.
Closes#2070Fixes#2070
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2070
The current code only goes through the output associated to the
window's wayland surface enter/leave events. That means that to update
the scale factor the window only looks at the outputs on which it
received enter/leave events. That doesn't include a new monitor
connected to the system on which the window might be display next.
The spirit of the existing logic seems to be to go through all the
scale factor available on the current monitors of the system and pick
the highest. So fix the current behavior by looking at the monitor on
the display.
Fixes#1144.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
xdg-output v3 marks xdg-output.done as deprecated and compositors are
not required to send that event anymore.
So if the xdg-output version is 3 or higher, simply set the initial
value `xdg_output_done` to TRUE so we don't wait/expect that event
from the compositor.
https://gitlab.gnome.org/GNOME/gtk/issues/2053
If a client issues a `move_resize()` request while the window is
maximized or fullscreen, update the saved size for when it will be
unmaximized/unfullscreened
Related: https://gitlab.gnome.org/GNOME/gtk/issues/1044
The xdg_output interface has a `name` property that reflects the output
name coming from the compositor.
This is the closest thing we can get to a connector name.
Fixes: #1961
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
The “xdg-output” protocol provides clients with the outputs size and
position in compositor coordinates, and does not provide the output
scale which is already provided by the core “wl_output” protocol.
So when receiving the wl_output scale event, we should update the scale
regardless of “xdg-output” support, otherwise the scale will remain to
its default value of 1 and the surface will be scaled up by the
compositor to match the actual output scale, which causes blurry fonts
and widgets.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1901
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
And update the surface accordingly (eg. scale on hidpi). The mechanism
that did that for wl_pointer has been made generic so it can be shared
with tablets too.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1675
_gdk_wayland_cursor_get_buffer was not initializing
its out variables in the 'not found' case. This
was showing up in protocol traces as garbage hotspots
being sent to the compositor.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1328
Previously, the GDK backend for Wayland would deduce the logical size
of the monitors from the wl_output size and scale.
With the addition of fractional scaling which advertises a larger scale
value and then scale down the client surface, the computed logical size
of the monitors in GDK would be wrong and confuse applications which
insist on using the monitor size and position (like Firefox).
The xdg-output protocol aims at describing outputs in a way which is more
in line with the concept of an output on desktop oriented systems by
presenting the outputs using their logical size and position appropriately
transformed.
Add support for the optional xdg-output protocol so that the size and
position of the monitors as reported by GDK is correct even when using
fractional scaling.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1828
Add private API to GDK to move these variables from the environment into
static scope. Also move the DESKTOP_STARTUP_ID validation here to reduce
code duplication.
Use constructors to read them as early as possible; however, do not
unset them until first requested. This avoids breaking gnome-shell and
gnome-settings-daemon, which want to use the DESKTOP_AUTOSTART_ID in
their own gnome-session clients.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1761
The event received in `gdk_wayland_window_show_window_menu()` can
come from widgets with a GdkWindow. In those cases the coordinates
are relative to the widget, not the root window.
This results in a misplaced window menu.
Properly calculate the coordinates by iterating to the toplevel
window as suggested by Carlos Garnacho.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/684
The use of the startup ID is now twofold, we reply back with it to end any
corresponding startup notification, but we also use it on
gtk_surface1.request_focus to acknowledge that the activation might raise
the corresponding window.
We should preserve the startup ID for the second to work properly, so avoid
clearing it here. It is inconsequential if the underlying
gtk_shell1.set_startup_id request happens multiple times on no longer existing
startup IDs, so don't bother preventing that from happening.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1754
And notify the shell about it. This is done through the
gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
on the way to the activated application is already in place to transfer
the startup ID, so the other side just has to reply with
gtk_surface1.request_focus.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
