1589209...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
shellDBus: Properly return from D-Bus methods
When implementing a D-Bus method synchronously, regular JS methods are
used. That is, whatever the method returns is passed as return value
to the method invocation.
However for asynchronous implementations, we need to explicitly return
a value to the invocation, otherwise the caller will wait until it times
out eventually.
c90fb27...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
shellDBus: Fix FocusApp()
The appDisplay used to be accessible via the viewSelector, but
that is gone now. Commit c09c070b15 adjusted the code, but the
replacement uses a Main.overview.appDisplay accessor that never
existed, whoops.
Fix this by exposing a new selectApp() method directly on the
overview, so we don't have to shuffle the appDisplay through
controls → overviewActor → overview.
f5be205...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
data: Remove old GConf migration files
The migration happened in GNOME 3.6 over 9 years ago. The chances
that someone migrates from 3.0.x or 3.2.x to 41 are very much zero.
And if it were to happen, it wouldn't work anyway, because we stopped
using a separate overrides schema.
8be5d33...
by
Olivier Fourdan <email address hidden>
windowManager: Remove timeout on starting X11 services
With Xwayland started on demand, mutter/gnome-shell will spawn Xwayland
and GNOME settings daemon Xsettings.
Currently, gnome-shell uses a timeout of 5 seconds before canceling the
launch and declare failure to start X11 services.
While 5 seconds may seem like a lot of time, when this is executed on a
virtual machine part of a QA tests under load, this causes random
failures.
There is no good value here, we could increase the timeout but it will
always remain racy. Instead, remove the timeout, systemd itself already
has a timeout mechanism (with a much longer wait time).
Thanks to Benjamin Berg <email address hidden> for finding the root cause
and suggesting the fix.
3f2db31...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
shell/app: Keep cancellable after cancelled proxy request
When a GTK app is started, we create a corresponding GtkApplication
proxy to monitor the app's busy state. If the app is stopped before
the proxy request finishes, we cancel the cancellable before clearing
the running state.
Usually we clear the cancellable once it is no longer needed, namely
when we got the proxy. However when the request was cancelled, the
cancellable has already been cleared, and if there's a cancellable,
it belongs to another request (because the window was added again,
for example when moving between monitors).
Leave that cancellable alone in that case, so we can cancel the
second request as well if necessary to avoid a crash when trying
to set the proxy on a cleared running state.
