isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-22 08:00:42 -05:00
Code Issues Packages Projects Releases Wiki Activity

window: Don't unmanage transient_for when attached

Browse Source 
For some reason, when a modal dialog was made an attaching
transient-for, if the window wasn't "constructing", it would be
unmanaged and rely on some side effect to be recreated. This side
effect is not triggered for Wayland clients, thus if one happen to set
a surface as "modal" via gtk_surface.set_modal before
xdg_toplevel.set_parent, it'd be unmanaged and never show up.

Instead, simply just set the tranciency anyway for Wayland clients.
This makes GTK+ clients that set_modal() before set_transient_for()
work.

https://bugzilla.gnome.org/show_bug.cgi?id=770324
This commit is contained in:
Jonas Ådahl 2016-08-24 12:53:25 +08:00
parent 8942e98e1d
commit 658d97d00e
1 changed files with 18 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/core/window.c
View File

@ -7415,6 +7415,7 @@ meta_window_set_transient_for (MetaWindow *window,
/* may now be a dialog */
if (window->client_type == META_WINDOW_CLIENT_TYPE_X11)
{
meta_window_x11_recalc_window_type (window);
if (!window->constructing)
@ -7429,11 +7430,13 @@ meta_window_set_transient_for (MetaWindow *window,
{
guint32 timestamp;
timestamp = meta_display_get_current_time_roundtrip (window->display);
timestamp =
meta_display_get_current_time_roundtrip (window->display);
meta_window_unmanage (window, timestamp);
return;
}
}
}
/* We know this won't create a reference cycle because we check for loops */
g_clear_object (&window->transient_for);