Commit Graph

333 Commits

Author SHA1 Message Date
Marco Trevisan (Treviño)
6944839ab6 window-props: Read WM_TRANSIENT_FOR for override-redirect windows
As per the Extended Window Manager Hints standard version 1.3 [1] an
override-redirect window can set a transient-for window per compositing and
app-matching purposes.

So just read the WM_TRASIENT_FOR property also for such windows, adapting
the error in case they are transient for another O-R window and adding a
test to check such case.

[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128

https://gitlab.gnome.org/GNOME/mutter/merge_requests/920
2019-11-07 18:43:16 +00:00
Marco Trevisan (Treviño)
bacbbbd628 window-props: Don't set override redirect windows as top-level parent
Java applications might use override-redirect windows as parent windows for
top-level windows, although this is not following the standard [1].

In such case, the first non-override-redirect child window that is created
was marked as being on_all_workspaces since the call to
should_be_on_all_workspaces() returns TRUE for its parent, and this even
though the on_all_workspaces_requested bit is unset.
When a further child of this window was added, it was set as not having a
workspace and not being on_all_workspaces, since the call to
should_be_on_all_workspaces() for its parent would return FALSE (unless if
it is in a different monitor, and the multiple-monitors workspaces are
disabled).

Since per commit 09bab98b we don't recompute the workspace if the
on_all_workspaces bit is unset, we could end up in a case where a window can
be nor in all the workspaces or in a specific workspace.

So let's just ignore the transient_for bit for a window if that points to an
override-redirect, using the x11 root window instead.

Add a stacking test to verify this scenario (was failing before of this
commit).

Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895

[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128
2019-11-07 16:04:19 +00:00
Marco Trevisan (Treviño)
c85fb107c0 window-props: Don't look for parent multiple times
Once we set the transient_for, we look for parent MetaWindow, so instead
of overwriting this value for loops check, just use another function
and avoid to look for the xwindow again when setting the MetaWindow parent.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
2019-11-07 16:04:19 +00:00
Marco Trevisan (Treviño)
ffa0a24848 x11-display: Get next serial just before using it
We ask XLib the next request serial number before performing other actions
triggered by meta_x11_display_set_input_focus_internal() that doesn't use
the request serial anyways. So, just request it before updating the focus
window as that's the operation that needs it.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
2019-11-06 17:32:29 +00:00
Marco Trevisan (Treviño)
efe5bed5b4 x11-display: Don't unset the X11 focused window after setting one
When using DesktopIcons extension and clicking in an icon, gnome-shell
starts an infinite loop caused by the first focus change that may trigger
on X11 a focus in/out event that leads to stage activation/deactivation
which never ends.

This happens because as part of meta_x11_display_set_input_focus_xwindow()
to focus the X11 stage window, we unset the display focus, but this also
causes to request the X11 display to unset the focus since we convolute by
calling meta_x11_display_set_input_focus() with no window, that leads to
focusing the no_focus_window and then a focus-in / focus-out dance that the
shell amplifies in order to give back the focus to the stage.

In order to fix this, mimic what meta_display_set_input_focus() does, but
without updating the X11 display, and so without implicitly calling
meta_x11_display_set_input_focus(), stopping the said convolution and
properly focusing the requested xwindow.
Also ensure that we're not doing this when using an older timestamp, since
this check isn't performed anymore.

Fixes https://gitlab.gnome.org/GNOME/mutter/issues/896
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/899

https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
2019-11-06 17:32:29 +00:00
Hans de Goede
dbb95cbe5f window-xwayland: Add Xwayland fullscreen games workaround
This is a workaround for X11 games which use randr to change the resolution
in combination with NET_WM_STATE_FULLSCREEN when going fullscreen.

Newer versions of Xwayland support the randr part of this by supporting randr
resolution change emulation in combination with using WPviewport to scale the
app's window (at the emulated resolution) to fill the entire monitor.

Apps using randr in combination with NET_WM_STATE_FULLSCREEN expect the
fullscreen window to have the size of the emulated randr resolution since
when running on regular Xorg the resolution will actually be changed and
after that going fullscreen through NET_WM_STATE_FULLSCREEN will size
the window to be equal to the new resolution.

We need to emulate this behavior for these games to work correctly.

Xwayland's emulated resolution is a per X11 client setting and Xwayland
will set a special _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the
toplevel windows of a client (and only those of that client), which has
changed the (emulated) resolution through a randr call.

This commit checks for that property and if it is set adjusts the fullscreen
monitor rect for this window to match the emulated resolution.

Here is a step-by-step of such an app going fullscreen:
1. App changes monitor resolution with randr.
2. Xwayland sets the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on all the
   apps current and future windows. This property contains the origin of the
   monitor for which the emulated resolution is set and the emulated
   resolution.
3. App sets _NET_WM_FULLSCREEN.
4. We check the property and adjust the app's fullscreen size to match
   the emulated resolution.
5. Xwayland sees a Window at monitor origin fully covering the emulated
   monitor resolution. Xwayland sets a viewport making the emulated
   resolution sized window cover the full actual monitor resolution.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
2019-11-01 14:14:21 +01:00
Carlos Garnacho
71c3f4af31 x11: Update X11 focus before updating MetaDisplay focus
In a similar vein to commit 8fd55fef85. This notably failed when setting
the focus on the stage (eg. to redirect key events to Clutter actors).
Deeper in MetaDisplay focus updating machinery, it would check
meta_stage_is_focused() which would still return FALSE at the time it's
called.

This would not typically have side effects, but our "App does not respond"
dialogs see the focus change under their feet, so they try to bring
themselves to focus again. This results in a feedback loop.

Changing the order results in later checks on the X11 POV of the focus
being correct, so focus is not mistakenly stolen from the close dialog,
and it actually succeeds in keeping the key focus.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607

https://gitlab.gnome.org/GNOME/mutter/merge_requests/876
2019-10-22 14:51:36 +02:00
Carlos Garnacho
45a8806e65 x11: Iterate over selections in a safer manner for event handling
It might be the case that handling an event induces the stream to
trigger completion, hence removing itself from the list. In that
case we would operate on the no longer valid list element to fetch
the next one.

Keep a pointer to the next element beforehand, so we can tiptoe
over streams that did remove themselves.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
2019-10-21 13:19:48 +02:00
Carlos Garnacho
e1fa0734a9 x11: Detach selection streams on dispose
The streams were only detached from MetaX11Display (and its event handling)
on completion. This is too much to expect, and those might be in some
circumstances replaced while operating.

Make those streams detach themselves on dispose(), so we don't trip into
freed memory later on when trying to dispatch unrelated X11 selection events.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
2019-10-21 11:47:40 +02:00
Jonas Ådahl
e17d70a592 x11/window-controls: Pass around MetaX11Display directly
Instead of passing around an X11 Display pointer that is retrieved from
the default Gdk backend, then finding the MetaX11Display from said X11
Display, pass the MetaX11Display directly.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
2019-10-15 07:17:29 +00:00
Jonas Ådahl
da213febdc core/core: Rename and move to x11/meta-x11-window-control
The functionality core/core.c and core/core.h provides are helpers for
the window decorations. This was not possible to derive from the name
itself, thus rename it and put it in the right place.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
2019-10-15 07:17:29 +00:00
Jonas Ådahl
c474ad6a53 Stop including core.h where it's not used
It provides glue for window frame controls and internal window
management, and that is only relevant for a couple of places in src/ui/.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
2019-10-15 07:17:29 +00:00
Carlos Garnacho
5c1be2233d x11: Map mimetypes back to selection atoms
This may be seen as the missing half of
https://gitlab.gnome.org/GNOME/mutter/merge_requests/842. Now that we
translate some atoms to better known mimetypes, we should also translate
those mimetypes to the underlying atoms if we might have added them.

Fixes c&p from certain X11 clients.

Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/854
2019-10-12 19:18:19 +02:00
Carlos Garnacho
59a697f773 x11: Translate well known selection atoms to mimetypes
Some antediluvian x11 clients only bother to set atoms like
UTF8_STRING/STRING/TEXT/... and no matching mimetypes. Cover for them
and add the well known mimetypes if they are missing.

Reported at https://bugzilla.redhat.com/show_bug.cgi?id=1758873

https://gitlab.gnome.org/GNOME/mutter/merge_requests/842
2019-10-10 12:13:46 +00:00
Hans de Goede
fa461525ee window-x11: Refactor meta_prop_get_latin1_string() calls
Instead of storing the result of meta_prop_get_latin1_string() into
a temporary string value, g_strdup-ing that temp value storing the
g_strdup result into window->sm_client_id and then g_free-ing the
temporary string, we can pass window->sm_client_id as the place where
meta_prop_get_latin1_string() stores its result, since the result
from meta_prop_get_latin1_string() is itself a g_strdup-ed string,
so there is no need to g_strdup it again.

Note this drops the check to only issue the
"Window %s sets SM_CLIENT_ID on itself ..." warning once. This check is
not necessary as update_sm_hints() is only called once at window
creation time and is never called again.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
8e510a07c4 xprops: Use g_new0 instead of malloc in size_hints_from_results()
Switch the memory allocation in size_hints_from_results from a malloc call
without error-checking to g_new0 and adjust the free path accordingly.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
e153524748 xprops: Use g_strdup in class_hint_from_results()
Use g_strdup instead of malloc + strcpy, this also gets rid of a bunch
of error checking which is no longer necessary, also adjust the free
path accordingly.

Note that there was a malloc + XFree mismatch in the removed error-handling.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
eb8a1f42bc xprops: Use g_new0 instead of calloc in wm_hints_from_results()
Switch the memory allocation in wm_hints_from_results from a calloc call
without error-checking to g_new0 and just the free path accordingly.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
89cd9d382d xprops: Use g_free instead of XFree in text_property_from_results()
results->prop is g_malloc memory so it should be free-ed with g_free not
XFree. The same applies to the return value of text_property_from_results
itself.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
488991b0f6 xprops: Free counter_list_from_results() return value with g_free()
counter_list_from_results directly passes through the results->prop
pointer which is g_malloc memory, so we should free the buffer it
returns with g_free.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
e2330617ac xprops: Free latin1/utf8_string_from_results() return value with g_free()
latin1_string_from_results and utf8_string_from_results use g_strndup,
so the returned string should be freed with g_free, rather then with
free or XFree. This fixes all free-s of buffers returned by these 2
functions to properly use g_free.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
5e6d98e79f xprops: Use g_new0 instead of calloc in meta_prop_get_motif_hints()
Use g_new0 instead of calloc for motif_hints_from_results and adjust
its callers to use g_free.

Note that in the process_request_frame_extents function this replaces
the wrong original mismatch of calloc + XFree with a matching g_malloc +
g_free pair.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
5eaf655224 xprops: Free meta_prop_get_cardinal_list() return value with g_free()
meta_prop_get_cardinal_list directly passes through the results->prop
pointer which is g_malloc memory, so we should free the buffer it
returns with g_free.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
2c1553570f xprops: Free atom_list_from_results() return value with g_free()
atom_list_from_results directly passes through the results->prop
pointer which is g_malloc memory, so we should free the buffer it
returns with g_free.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
c937dd5ba3 xprops: Use meta_XFree instead of XFree in validate_or_free_results()
Use meta_XFree instead of XFree, letting meta_XFree do the NULL
checks for us.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Carlos Garnacho
8fd55fef85 x11: Update focus on the X11 display before the MetaDisplay
The meta_display_update_focus_window() call has indirect dependencies
on the X11 focus window, in order to determine the correct focus window
on the Wayland side (i.e. may turn out NULL with certain X windows).

In order to have the right x11_display->focus_xwindow there, we should
perform first the focus update on the X11 display.

Fixes focusing of Java applications, as those don't seem to go through
_NET_ACTIVE_WINDOW.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/819
2019-09-27 13:52:12 +00:00
Carlos Garnacho
6922f0e16a x11: Minor refactor of input focus handling code
Instead of open coding the X11 focus management in display.c, expose
it as a single function with similar arguments to its MetaDisplay
counterpart. This just means less X11 specifics in display.c.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
2019-09-13 20:55:57 +00:00
Carlos Garnacho
31df06d94e x11: Use the currently focused X window for _NET_ACTIVE_WINDOW
MetaDisplay and MetaX11Display focus windows are slightly decoupled,
we cannot rely here on the MetaDisplay focus to be updated yet. We
however know the X Window that got focused, so lookup the corresponding
MetaWindow (and client X window) from it.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
2019-09-13 20:55:56 +00:00
Jonas Ådahl
3c0067dc69 x11: Trace XEvent processing
https://gitlab.gnome.org/GNOME/mutter/merge_requests/765
2019-09-02 17:36:00 +00:00
Rémi Bernon
fdda8adfcf
x11: Add window test before accessing reparents_pending field
https://gitlab.gnome.org/GNOME/mutter/merge_requests/768
2019-09-02 18:27:37 +02:00
Rémi Bernon
8f242f8bf0 core: Fix multiple reparent requests handling
If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.

This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>

https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
2019-09-02 15:50:37 +00:00
Ray Strode
556e7694de iconcache: Avoid xrender picture formats when creating cairo surface
If an application provides its window icon via wmhints, then mutter
loads the pixmap specified by the application into a cairo xlib surface. When
creating the surface it specifies the visual, indirectly, via an XRender
picture format.

This is suboptimal, since XRender picture formats don't have a way to specify
16bpp depth, which an application may be using.

In particular, applications are likely to use 16bpp depth pixmaps for their
icons, if the video card offers a 16bpp framebuffer/root window.

This commit drops the XRender middleman, and just tells cairo a visual to use
directly.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
2019-08-27 18:47:41 +03:00
Ray Strode
1a5cba5df5 Revert "iconcache: Support 16bit icons"
This reverts commit b95d7e8276.

It's poisoning cairo's GC cache with a GC that has the wrong
colordepth, leading to a crash in unrelated code later on.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
2019-08-27 18:47:41 +03:00
Carlos Garnacho
433e1b388d core: Move Stack to StackTracker synchronization back to stack.c
We indirectly were relying on the MetaX11Stack for this. We strictly
need the _NET_CLIENT_LIST* property updates there, so move our own
internal synchronization to common code.

Fixes stacking changes of windows while there's no MetaX11Display.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
2019-08-26 17:39:10 +00:00
Carlos Garnacho
ad72fa46b0 clutter: Move X11 input to src/backends/x11
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.

This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
2019-08-24 08:59:08 +00:00
Olivier Fourdan
5fa8b24b2b xwayland: pass the X11 display
Pass the X11 display to `meta_xwayland_complete_init()` so that it can
be used without poking into GDK.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/735
2019-08-19 17:14:40 +02:00
Jonas Ådahl
8ee00cee60 compositor/x11: Move stage input region setting to MetaX11Display
It doesn't use anything specific to MetaCompositor, and
MetaCompositorX11 isn't exposed, so move it to MetaX11Display.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-19 08:44:58 +00:00
Jonas Ådahl
984aad4b86 compositor: Move out X11 compositing code into sub type
Introduce MetaCompositorX11, dealing with being a X11 compositor, and
MetaCompositorServer, being a compositor while also being the display
server itself, e.g. a Wayland display server.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-19 08:44:58 +00:00
Carlos Garnacho
879f5f0dbb x11: Add "closing" flag to MetaX11Display
So code not directly in dispose() can know to avoid certain things
when the X11 display is about to close.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-08-06 00:41:36 +00:00
Carlos Garnacho
123b40105d x11: Shuffle x11-stack destruction in MetaX11Display dispose
Unmanaging the windows may trigger stack operations that we later try
to synchronize despite being in dispose() stage. This may trigger
MetaStackTracker warnings when trying to apply those operations.

Switching destruction order (First dispose the X11 stack representation,
then unmanage windows) won't trigger further stack changes on X11 windows
after having signaled MetaDisplay::x11-display-closing.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-08-06 00:41:36 +00:00
Carlos Garnacho
d3d1ff1aae x11: Do not queue stack operation for guard window
In the case mutter is a x11 compositor, it doesn't matter much
since the stack tracker will go away soon. In the case this is a
wayland compositor with mandatory Xwayland, it matters even less
since the session would be shutting down in those paths.

But if this a wayland compositor that can start Xwayland on demand,
this is even harmful, as the MetaStackTracker should be cleared of
x11 windows at this moment, and we actually did right before dispose
on ::x11-display-closing.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-08-06 00:41:36 +00:00
Carlos Garnacho
9109fa0eb8 x11: Add meta_x11_get_display_name() function
Instead of poking the DISPLAY envvar at places.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-08-06 00:41:36 +00:00
Ray Strode
b95d7e8276 iconcache: Support 16bit icons
Mutter current crashes if an application sets a 16-bit color depth
icon in its window manager hints.

This commit fixes the crash.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/710
2019-08-01 16:52:10 -04:00
Mark Blakeney
e9cc220c8e x11: Remove benign warning for older X clients
The default configuration of libinput-gestures utility invokes wmctrl to
switch between desktops. It uses wmctrl because this works on both Xorg
and Wayland (via XWayland). Unfortunately, this generates the following
warning message every time, in both Xorg and Wayland desktops:

"Received a NET_CURRENT_DESKTOP message from a broken (outdated) client
who sent a 0 timestamp"

The desktop switch still works fine. The tiny code change here removes
this specific warning because, as the prefacing code comment originally
said and still says, older clients can validly pass a 0 time value so
why complain about that?

I also refactored the "if (workspace)" code slightly to avoid the double
test of the workspace value.

This is submitted for MR
https://gitlab.gnome.org/GNOME/mutter/merge_requests/671.
2019-07-22 07:31:41 +00:00
Marco Trevisan (Treviño)
5ca0ef078d window-x11: Focus a window in the active workspace as take-focus fallback
Starting with commit 2db94e2e we try to focus a fallback default focus window
if no take-focus window candidate gets the input focus when we request it and
we limit the focus candidates to the current window's workspace.

However, if the window is unmanaging, the workspace might be unset, and we could
end up in deferencing a NULL pointer causing a crash.

So, in case the window's workspace is unset, just use the currently active
workspace for the display.

Closes https://gitlab.gnome.org/GNOME/mutter/issues/687

https://gitlab.gnome.org/GNOME/mutter/merge_requests/688
2019-07-18 10:09:45 +02:00
Marco Trevisan (Treviño)
6d8293a422 window-x11: Use any focusable window as fallback delayed focus window
As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.

When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.

However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.

So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.

Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.

Added metatests verifying these situations.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
2019-07-08 11:46:52 +02:00
Marco Trevisan (Treviño)
c327b2df95 window-x11: Accept any focusable window as fallback focus
As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.

So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).

Added a stacking test to verify this.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
2019-07-08 11:21:17 +02:00
Marco Trevisan (Treviño)
9aee47daa9 window-x11: Don't double-check for unmanaging windows
When looking for the best fallback focus window, we ignore it if it is in the
unmanaging state, but meta_stack_get_default_focus_window() does this is check
for us already.

So, ignore the redundant test.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
2019-07-08 11:21:17 +02:00
Carlos Garnacho
1f133b3ed2 compositor: Add MetaDnD private function to initialize XDND
We need to set XdndAware and XdndProxy on the stage window if running
a X11 compositor, this is not necessary on wayland.

Takes over gnome-shell code doing this initialization.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/667
2019-07-04 12:24:57 +00:00
Florian Müllner
feb9d129db window-x11: Fix typo 2019-06-24 19:33:30 +02:00