shell-app: Finish startup sequence for process that exit too early
If a process associated to an application declaring StartupNotify=true
in its desktop file exits before having ever mapped a top level window,
the "remove" X message expected as per the Startup Notification Spec [1]
won't ever be issued, and the shell will keep waiting for a while until
the sequence is finished on time out.
This provides a confusing and bad experience since things like a confusing
icon + a spinner, or the mouse pointer switching to a spinning cursor, will
be showing up in the meantime, so we need to detect those situations and
make sure the sequence gets completed, and the app moved to STOPPED.
window-tracker: Add new public method shell_startup_sequence_complete()
We need to provide a wrapper for sn_startup_sequence_complete() from libsn,
so that's there's a way to make sure that the startup sequence gets always
finished, even if the launched process exits early without an error code
before ever having mapped a top level window (i.e. gnome-control-center).
Closes: #267
c0a453f...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
networkAgent: Fix fallout from libnm port
While the libnm-glib version of the function returns a GByteArray*
that gjs can directly cast to the required gutf8*, the libnm function
returns GBytes* from which we need to explicitly fetch the data.
keyboardManager: take group index into account when preserving keymap
commit 642107a2 attempts to avoid resetting the current keymap on
spurious input source changes.
It does this by checking if the current layout id is found in
the new list of layouts and resetting the current layout to the
associated match in the list. By not nullifying the current
layout, it won't get subsequently reset.
Unfortunately, if the order of the list changes, resetting the
current keymap is still necessary, since the order corresponds
with the index of the activated group.
This commit changes the code to nullify the current layout if
its group index changes.
calendar-server: Update views only after the time range is set
The gnome-shell-calendar-server calls to refresh queries even when it
has no time range set, which results in:
a) waste of resources (for example after login),
b) many runtime warnings in the journalctl log, related to
incorrect time range being used.
