When a user logs in to a wayland session, we keep the login screen
running on the X server with the login screen running in a deactivated mode.
This commit makes sure it get reactivated when the user comes back to
the VT (from user switching, logout or just ctrl-alt-f1).
https://bugzilla.gnome.org/show_bug.cgi?id=726989
In addition to BluetoothAirplaneMode, we need to check also
BluetoothHasAirplaneMode, which is indicative of bluetooth rfkill
devices (and by extension bluetooth adapters).
This prevents showing the menu if there is no adapter present.
https://bugzilla.gnome.org/show_bug.cgi?id=725057
Since rebasing our AppSystem on GLib's facilities, we only ever
append to the id-to-app cache. So if an application is uninstalled,
shell_app_system_lookup_app() will still happily return it if it
was cached previously. For instance if a favorite app is uninstalled,
it keeps lurking in the dash until a restart.
To fix, filter out removed apps from the cache when handling
GAppInfoMonitor::installed-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=726414
Most system menu entries are disabled on the lock/login screen;
there is no good reason why users should be allowed to turn bluetooth
on/off (but not e.g. Wifi), so disable the entry as well.
https://bugzilla.gnome.org/show_bug.cgi?id=726319
When reacting to background settings changes, we may end up queuing
more than one load. The redundant backgrounds are expected to be
destroyed when the previous background has faded out; however since
commit 933f38390b, the tweened actor is the same for all
consecutive load operations and we end up with a single onComplete
handler, ergo a single destroyed actor.
As new backgrounds are always added to the bottom, we are not only
piling up additional background actors, but break changing backgrounds
more than once, as the correct background ends up being covered by
previously added redundant actors.
Fix this by destroying redundant actors right after loading rather
than waiting for the fade animation to complete.
https://bugzilla.gnome.org/show_bug.cgi?id=726120
Folders use a 2x2 grid of the first 4 app icons as icon - if a folder
contains less apps, we currently skip the corresponding grid positions.
As a result, the overall size request may be smaller than the one for
other icons, making the folder icon look out of place.
Fix this by always using a full grid as folder icon, using dummy actors
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=726322
At some point ScreenShield had code to do this, I don't know when
it was lost, but it makes sense and avoids having to move the mouse
just to see the shield.
https://bugzilla.gnome.org/show_bug.cgi?id=726378
With the switch to a table layout in commit f959cafb36, setting
alignments to place the individual icons at the outer edge of the grid
stopped working. Remove that code and add some explicit spacing instead.
https://bugzilla.gnome.org/show_bug.cgi?id=726323
If the notification is updated while SHOWING, we'll overwrite the
tween updating it to the new 'y' position, but forget to update the
state to SHOWN at the end of our transition. Make sure to always set
the state to SHOWN at the end.
https://bugzilla.gnome.org/show_bug.cgi?id=704844
This code may have worked when written in 2009, but later gjs commit
b5e467d89aea43a8e32a1138d232c8a32e6b0785 removed the priority
parameter from idle_add.
Now, when running a constantly-updating client (es2gears) on an
embedded platform, _updateRegions() does not get called and I see
unresponsive window decorations.
Update the code to use meta_later_add() like other parts of the
shell, which is actually slightly better in this case anyway.
Solves the unresponsiveness problem.
https://bugzilla.gnome.org/show_bug.cgi?id=585500
The smartcard service is put in the foreground in two cases:
1) If password service is disabled by admin configuratoin
2) if a smartcard is inserted
In either case we don't want to ask the user to pick a user from the
userlist. We currently only avoid asking in case 2.
This commit fixes case 1.
https://bugzilla.gnome.org/show_bug.cgi?id=726263
We only want to react to the card the user logged in with, at
the unlock screen. We check "at the unlock screen" by checking
the "reauthenticating" state variable. That variable is the
wrong one, though. It gets set too late, and in some cases, gets
set at the login screen, too. We should be checking this._reauthOnly
instead.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=726262
If a user inserts the smartcard they logged in with into the system,
it's supposed to lift the shield and prompt for pin. That doesn't
happen because the parameter list of the smartcard-inserted signal
handler is wrong.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=726262
Currently we update the scale factor on startup and when we get a
monitors-changed signal, which is not the only cases where the setting changes. We cannot listen for gdk-window-scaling-factor changes because it is not
exported to gdk.
So use gtk-xft-dpi which also indicates a scale factor change.
When someone changes gtk-xft-dpi directly without changing the scale factor
we will just re-read the gdk-window-scaling-factor so no harm is done.
https://bugzilla.gnome.org/show_bug.cgi?id=726238
