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
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
Don't forget to rebuild the calendar when changing the setting
'org.gnome.shell.calendar show-weekdate'. This wasn't happening anymore
and changing the setting resulted in a calendar without the days
grid.
https://bugzilla.gnome.org/show_bug.cgi?id=725533
Once you start navigating between months, you can't return to the
current day. However, the current day is always displayed above the
calendar grid. Fix this by making the current date clickable; when
clicked, the calendar grid jumps back to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=641366
The profile name is most often not useful (because it's an
autogenerated string like "Wired Connection 1"), and even when it
is, it's already available in the submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=725586
Commit b7e1539699 removed the size to support hidpi but that caused the
actor to no longer be square. Fix that by going back to setting a size
but apply the scale factor before doing so.
To be able to correctly setup dbus policy, I had to change the expected
agent D-Bus API a bit: Now object path is fixed and not different for
each user.
https://bugzilla.gnome.org/show_bug.cgi?id=725082
Commit 61a58ff3c9 replaced the (removed in commit 254afc50223a7)
MetaWindowActor.get_workspace() method by MetaWindow.get_workspace(),
but did not take into account that the return values differ - the
former returns the workspace index, the latter the workspace object.
https://bugzilla.gnome.org/show_bug.cgi?id=724686
With tile previews being implemented as Clutter actors in the shell, we
can now easily add fancy animations when showing/hiding the preview.
Besides looking more polished, the animations also help understanding
what will happen to the window when the drag is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=665758
Interrupting update installation can mess up the package database quite
a bit and could lead to totally destroying the distro installtion. To
avoid running out of juice during an upgrade, warn when someone tries to
install updates on battery power.
https://bugzilla.gnome.org/show_bug.cgi?id=722898
This adds a checkbox for installing software updates to the shut down
dialog. The implementation relies on an already prepared offline update
and uses PackageKit's pk-trigger-offline-update helper to trigger the
installation.
https://bugzilla.gnome.org/show_bug.cgi?id=722898
This moves the dialog type overriding that gnome-software uses to bring
up restartInstallDialogContent from _sync() to OpenAsync(), in order to
ensure the type is overridden early enough to show the correct buttons.
While at this, make sure the & symbol in the button's label is escaped
to avoid runtime warnings, now that the label actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=722898
Currently workspaces (except for the last one) are removed when
they become empty. While we do have special treatment for the
case where the currently active workspace is removed, we just
move directly without animations to the last workspace to avoid
ending up on a "random" workspace. However this behavior is still
a bit confusing, so keep the workspace around instead until the
user decides to move to another one.
https://bugzilla.gnome.org/show_bug.cgi?id=709064
Add a key 'disable-extension-version-validation' key that disables
the validation of extension's claimed to be supported shell version
with the shell version and just load all extensions unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=724683
Until now the arrows were the associated arrow
character of the font. This cause some problems like
different arrows for different fonts, and size can be
altered because of the font size.
To solve that, use an image for the arrows.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Currently the animation of the arrows doesn't take
into account previous rotation.
Since in a incoming patch we will use one arrow
and rotate it to generate the four directions, we
need that the animation use relative rotation.
https://bugzilla.gnome.org/show_bug.cgi?id=720206
Currently destroying a menu's actor and calling its destroy() method
are subtly different - the latter will also result in the menu being
removed from the corresponding menu manager.
There is no good justification for that behavior, so make both actions
behave the same.
https://bugzilla.gnome.org/show_bug.cgi?id=724690
Until now the timestamps were using 24h format.
Check gsetting clock-format to know when
the user is using 12h format or 24h format and
make the timestamp acordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=715158
Multiple connections for the same device are mutually exclusive, so
a switch is not the appropriate UI metaphor. Use a radio item instead,
and provide a separate "Turn off" item to disconnect.
Behavior when there is only one connection is not changed, there
is a single Connect/Turn off item.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
We don't watch for timestamp changes, and sorting by name keeps
the order consistent and predictable. In practice, there should
be at most 3 or 4 elements, so the user will always read all them
at once and sorting is irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
If the connection name is changed, the UUID doesn't necessarily,
so checkConnection would take the early return path. Make sure
we update the existing menu item too.
https://bugzilla.gnome.org/show_bug.cgi?id=723570
The active_connection might be null, but the NMApplet code might
still belive the device wrapper is the primary connection (because
dbus signals are emitted one after the other).
(Also, remove an old and wrong comment about bluetooth in wwan code)
Fixes:
(gnome-shell:22511): Gjs-WARNING **: JS ERROR: Exception in callback for signal: icon-changed: TypeError: this._device.active_connection is null
NMDeviceWired<.getIndicatorIcon@resource:///org/gnome/shell/ui/status/network.js:475
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._updateIcon@resource:///org/gnome/shell/ui/status/network.js:1790
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionSection<._addConnection/<@resource:///org/gnome/shell/ui/status/network.js:265
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionItem<._sync@resource:///org/gnome/shell/ui/status/network.js:137
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionItem<.setActiveConnection@resource:///org/gnome/shell/ui/status/network.js:169
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionDevice<._activeConnectionChanged@resource:///org/gnome/shell/ui/status/network.js:327
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=723570
This reverts commit 5d05b66902.
Had a long discussion with Bastien Nocera and Allan Day on IRC about
this and in the end we decided to go with the simple on/off controls for
now.
Conflicts:
js/ui/status/location.js
https://bugzilla.gnome.org/show_bug.cgi?id=723684
