window-tracker: check WM_CLASS for sandboxed apps before the app's ID
For sandboxed apps, the shell needs to consider the app's ID when
matching its windows against the right .desktop file, but that
check can't be done before having attempted to match using the
WM_CLASS property of the app's window, otherwise apps installing
multiple desktop files (e.g. LibreOffice) will always match every
single window against the same .desktop file, ignoring hints such
as the StartupWMClass key.
This commit moves the call to get_app_from_sandboxed_app_id() after
get_app_from_window_wmclass() and before get_app_from_window_pid(),
so that we only rely on the sandboxed app's ID when no match has
succeed using the WM_CLASS property, but before checking by PID to
prevent wrong groups that could be created when the PID of the app
inside the sandbox matches the one from a process outside of it.
* Remove tiny padding of user-list
* Less space between avatar and username
* Apply the 1em padding only to the user-widget, not the timed-login-indicator
loginDialog: Correct source name for timed login idle timeout
The _blockTimedLoginUntilIdle method sets a timeout to be called after
the user is idle for 5 seconds. That timeout is erroneously given the
source name "[gnome-shell] this._timedLoginAnimationTime" which looks
like a copy-and-paste mistake. The original intention was probably to
use a source name of "[gnome-shell] this._timedLoginIdleTimeOutId" which
more closely matches existing convention for source names.
loginDialog: Restrict grabbing of focus while timed login is running
Make sure the focus isn't grabbed right after user interaction starts a
new timed login. Only grab it after the idle timeout is done and on the
first run instead.
loginDialog: Ensure old timed login timeout is removed before starting a new one
Normally, we give the user a 5 second grace period of inactivity before
starting a timed login operation. Unfortunately, that grace period
timeout isn't properly removed if the timed login operation is restarted
during the grace period. That means the timeout handler can
inadvertently get called multiple times leading to the grace period
duration getting subtracted from the total animation time more than
once.
This commit ensures we only ever have one grace period timeout scheduled
at a time.
