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
Doing so is inconsistent with the behavior in the summary, and
is quite annoying when dealing with chats (because there is no way
to unfocus a chat notification with the keyboard only)
https://bugzilla.gnome.org/show_bug.cgi?id=724178
We can't let live (ie, never destroyed) actors undergo GC, because
they will emit :destroy signals during finalization and assert/crash
libmozjs. Properly destroy all actors before letting the GC
free them.
https://bugzilla.gnome.org/show_bug.cgi?id=724798
It's possible that FBO creation fails due to hw limits or the
driver not exposing the EXT_framebuffer_object extension.
In that case, just give up on creating square icons.
https://bugzilla.gnome.org/show_bug.cgi?id=724977
If we have the following sequence:
cache.getImageContent({ filename: "foo", cancellable: cancellable1 });
cache.getImageContent({ filename: "foo", cancellable: cancellable2 });
cancellable1.cancel();
Then the second load will complete with "null" as its content, even though
it was never cancelled, and we'll see a blank image. Meanwhile, since the
second load simply appends to the list of callers for the second load,
cancellable2 does absolutely nothing: cancelling it won't stop the load,
and it will still receive onFinished handling.
To prevent this from happening, give the actual load operation its own
Gio.Cancellable, which is "ref-counted" -- only cancel it when all the other
possible callers cancel.
Based on work from Jasper St. Pierre <jstpierre@macheye.net>
https://bugzilla.gnome.org/show_bug.cgi?id=722149
At the moment when a file is loaded, we iterate through the list of
pending file loads and ignore any unrelated to the file, then iterate
all the callers of the related file loads and finish them.
In fact, there can only ever be one pending file load related to the
file, and we already know it, so we can avoid the ugly nested loops.
https://bugzilla.gnome.org/show_bug.cgi?id=722149
This commit moves the code around a bit such that the
caller gets allocated up front and then a file load is either
found or created to attach the caller to.
Functionally, the code is the same, it's just now factored in a way
that will make it easier to fix a bug with cancellation later.
https://bugzilla.gnome.org/show_bug.cgi?id=722149
Copying is actually a lightweight operation, so trying to avoid it just adds
code complexity for little gain.
Based on work from Jasper St. Pierre <jstpierre@macheye.net>
https://bugzilla.gnome.org/show_bug.cgi?id=722149
Instead of poking through IDLETIME, which confuses the state tracking
and can prevent automatic suspend, send a special signal to GSD
when the screen is to be waken up for a notification.
Someday we'll bring over all the state tracking and avoid this
ping-pong between gnome-shell and gnome-settings-daemon, but
that day's not today.
https://bugzilla.gnome.org/show_bug.cgi?id=712706
NMApplet will call removeConnection() unconditionally on all sections,
including those that had nothing to do with the connection in the first
place.
Fixes:
Gjs-WARNING **: JS ERROR: TypeError: this._connectionItems.get(...) is undefined
NMConnectionSection<.removeConnection@resource:///org/gnome/shell/ui/status/network.js:323
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._connectionRemoved@resource:///org/gnome/shell/ui/status/network.js:1885
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=725958
Loading the user list can be expensive, for instance when there is
a large number of users and/or their avatars have to be fetched over
the network. In case the user list is disabled anyway, there is no
point in doing that work just to hide it, so stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=725905
When the user changes the active day by mouse click or keyboard focus
plus key press on a day in the grid, always move the keyboard focus to
the newly activated day.
This basically restores functionality that was introduced in commit
31478e9fb4 but got lost again in the re-factoring in commit
cc4659f5c6.
https://bugzilla.gnome.org/show_bug.cgi?id=725606
Having to go through import.gi is awfully inconvenient when one
is using the looking glass as a quick gjs console, and we're
already importing all sorts of stuff there.
https://bugzilla.gnome.org/show_bug.cgi?id=725832
