Returning a GLib.Error from a method invocation will encode the
error when sent over the wire. In case the error itself is already
an encoded remote error, just passing it on will result in double
wrapping.
Avoid that by stripping any remote error information before
returning it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
If an interface has any signals, we don't want to auto-shutdown
while a caller is still connected to a signal.
Unfortunately we can't tell whether there are any signal connections,
so we track all callers instead, and keep the service alive while
any of them is still on the bus.
For services that we call from gnome-shell itself - like screencasts
or extensions - this has the unintended side effect of effectively
disabling auto-shutdown.
Address this by exempting the org.gnome.Shell name from sender
tracking.
Services that we expect to keep running for the lifetime of the
shell already disable auto-shutdown, so the only downside is a
small startup delay to resolve the well-known shell name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7250
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3052>
We want to replace gjs' custom (and now legacy) imports system
with standard EcmaScript modules: JS developers are already
familiar with them, they have better tooling support and using
standard features over non-standard ones is generally the right
thing to do.
Our D-Bus services are separate from the main process, and thus
can be ported separately (except for the few imports that are
shared with the main process' code base).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2786>
The REPLACE flag we currently pass is useless, as replacing the service
is disallowed when not started with the ALLOW_REPLACEMENT flag.
Fix this by adopting a more standard pattern where replacement is always
allowed, but only actually requested when `--replace` is passed on the
command line.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2152>
If something started the service, but crashed before managing to make a
method call, we'd end up with the service running indefinitely. Fix this
by queueing a shutdown check immediately on startup.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
While we only shut down after a method call completed or (if the
interface has signals) the sender disconnects from the bus, services
may need to inhibit auto-shutdown for more specific reasons themselves,
for example when a method call kicks off an operation that should
complete before shutting down.
Add hold() and release() methods like Gio.Application for those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1115
There are a couple of D-Bus services that are currently provided by
gnome-shell for which it makes sense to move them fully or partially
into separate processes:
- screen recording (performance)
- FDO notifications (security)
- Extensions (portalization)
Add some base classes and build system glue to take care of the
common boilerplate.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547