The method used for getting the current logical monitor (the monitor
where the pointer cursor is currently at) depends on the backend type,
so move that logic to the corresponding backends.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of keeping around array indexes, keep track of them by storing
a pointer instead. This also changes from using an array (imitating the
X11 behaviour) to more explicit storing.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In that case, the MetaWindow is created, but it should also be unminimized
to satisfy the MapRequest triggered by the client, otherwise these would
stay minimized until they're shown explicitly by the user.
https://bugzilla.gnome.org/show_bug.cgi?id=774333
Some applications like Wine may choose to juggle the same user time
window across different toplevels, in that case we receive warnings
when trying to register the window a second time, leading to wrong
accounting.
If the window was already used as the user time window for another
toplevel, unset it from the previous MetaWindow owner, and unregister
so the registration with the new MetaWindow is successful.
https://bugzilla.gnome.org/show_bug.cgi?id=774330
In order to kill a window, on both X11 and wayland we first try to
kill(3) the corresponding process, so we can add the newly added
get_client_pid() method to share that code.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
Windows from Xwayland still needs to use the Wayland path, but is
represented an MetaWindowX11, thus the abstraction introduced in
"window: Make meta_window_has_pointer() per protocol implemented"
is wrong. Lets turn back time, and reconsider how this can be
abstracted more correctly in the future.
This reverts commit 9fb891d216.
gjs throws exceptions on non UTF-8 strings which, in some cases, crash
gnome-shell. ICCCM string properties are defined to be Latin-1 encoded
so we can try to convert them to avoid it.
Note that _NET_WM_NAME is defined to be UTF-8 and we already validate
it in utf8_string_from_results() .
https://bugzilla.gnome.org/show_bug.cgi?id=752788
To support invoking the system bell on Wayland we shouldn't have paths
that fallback to X11. Let the X11 caller deal with the absence of
libcanberra, and change API to not take any X events.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
This is kind of in a middle ground at the moment. Even though it
handles sequences not coming from libsn, they're added nowhere at
the moment, we'll rely on the app launch context being in the x11
side at the moment.
Also, even though we do create internal sequence objects, we keep
exposing SnStartupSequences to make gnome-shell happy, we could
consider making this object "public" (and the sequence objects with
it), things stay private at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=762268
Some of the mutter code using these properties expects them to be
null-terminated whereas xcb does not use null-terminated strings:
http://xcb.freedesktop.org/XcbRationale/
This was in some cases resulting in the WM_CLASS property containing
garbage data which broke application matching, caused the hot-corner and
window-switcher to stop working, or was exposed as text in the UI.
https://bugzilla.gnome.org/show_bug.cgi?id=759658
Some applications, like Chromium, explicitly set their bounding region
to the client area when full-screen. Detect this case, and allow us to
fullscreen when this happens.
When managing a non-OR window we're required by the ICCCM to behave as
if we received a ConfigureRequest which means that we must generate a
synthetic ConfigureNotify even if the window isn't moved or resized
from its current (initial) geometry.
During MetaWindow's x11/wayland split a slight behavior change for x11
windows crept in. Before the code split, MetaWindow->rect was
initialized with the X window's geometry, but now we're not
initializing MetaWindowX11Private->client_rect which causes the checks
for whether it's necessary to move/resize the window in
meta_window_x11_move_resize_internal() to tell us that we do need to
move/resize which means we do an XConfigureWindow() call and don't
send the sythetic ConfigureNotify. But since the X window isn't really
moving, the XConfigureWindow() call doesn't cause the X server to
generate a ConfigureNotify which breaks some clients such as Java's
AWT.
We can fix this by setting MetaWindowX11Privatew->client_rect for both
OR and non-OR windows. We can set buffer_rect for non-OR windows as
well to simplify the code since it will be assigned the correct value
in meta_window_x11_move_resize_internal() .
https://bugzilla.gnome.org/show_bug.cgi?id=759492
Wine removes the minimize func from its Motif hints on full-screen
windows, because, as the Win32 API literally says, the minimize button
is indeed not visible on full-screen windows.
Given that this code was added to prevent minimizing a panel by
accident, I don't necessarily think that it's relevant anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=758186
If a client only ever sets the hint on window creation we'd never pick
the value. Also, include override redirect windows since the hint is
relevant to them too.
https://bugzilla.gnome.org/show_bug.cgi?id=758544
In a HiDPI environment, all gtk+ apps will report a 2 x 2 size
increment to avoid odd size. But that does not mean they are
resizing in cells like terminals, so they resize popup should
not be shown.
Ideally, we should ignore <= scale x scale increments, but in
practice scale is 1 or 2, and even in a lo-dpi setting a 2 x 2
increment makes little sense so let's keep the patch simple.
https://bugzilla.gnome.org/show_bug.cgi?id=746420
Both Window and XSyncCounter are XIDs which on 64 bit X clients are 8
bytes wide. But the values on the wire are 32 bit so, for these types,
we always copy 4 bytes into results->prop. As such copying them out
with a cast such as *(Window *) means that we are actually reading 8
bytes which depending on whether the higher addressed 4 bytes are zero
means that sometimes this works while others it gives us a bogus
value.
https://bugzilla.gnome.org/show_bug.cgi?id=756074
This was introduced in commit c6793d477a
to prevent window self-maximisation. It turns out that that bug seems
to have been fixed meanwhile in a different way since the reproducer
in https://bugzilla.gnome.org/show_bug.cgi?id=461927#c37 now works
fine with this special handling removed.
In fact, failing to set window->fullscreen immediately when loading
the initial set of X properties causes us to create a UI frame for a
window that sets _NET_WM_STATE_FULLSCREEN.
This, in turn, might cause the fullscreen constrain code to fail if
the window also sets min_width/min_height size hints to be the monitor
size since the UI frame size added to those makes the rectangle too
big to fit the monitor. If the window doesn't set these hints, we
fullscreen it but the window will get sized such that the UI frame is
taken into account while it really shouldn't (see the reproducer
above).
https://bugzilla.gnome.org/show_bug.cgi?id=753020
Since we scale surface actors given what main output their toplevel
window is on, also scale the window geometry coordinates and sizes
(window->rect size and window->custom_frame_extents.top/left) in order
to make the window geometry represent what is being rendered on the
stage.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Since we're using xcb now, not Xlib, it doesn't have the stupid silly
thing where it copies all 32-bit data to 64-bit data to match the
long-y-ness of it.
It seems the largest possible value is to be passed, so actually pass
that instead. Note that even though the name of the xcb_get_property
parameter is called 'long_length' its actually a uint32_t.
https://bugzilla.gnome.org/show_bug.cgi?id=751136
This piece of code hooks in both wl_data_device and the relevant X
selection events, an X11 Window is set up so it can act as the clipboard
owner when any wayland client owns the selection, reacting to
SelectionRequest events, and returning the data from the wayland client
FD to any X11 requestor through X properties.
In the opposite direction, SelectionNotify messages are received,
which results in the property contents being converted then written
into the wayland requestor's FD.
This code also takes care of the handling incremental transfers through
the INCR property type, reading/writing data chunk by chunk.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
