We have no guarantees on the number of ::size-changed signals that we may
receive, so the _sizeChangedWindow handler may run multiple times, which
leads to multiple calls to meta_plugin_size_change_completed(). So double
check the actor is not already being animated in the _sizeChangedWindow
handler to avoid reentrancy.
https://bugzilla.gnome.org/show_bug.cgi?id=777784
The title of the window should not be in control of a potentially
hostile hotspot provider, so only set the subtitle to be that of the
page, the main title will stay the same.
The subtitle will also be set to a URI, so that the hotspot cannot be
used to control the title shown in our UI.
Helps https://bugzilla.gnome.org/show_bug.cgi?id=749197
Even though the window is maximised when created, the window is still
resizable. This avoids making the window smaller than usable. If the
screen is smaller than the minimum window size, the maximise should make
it fullscreen and non-resizable.
https://bugzilla.gnome.org/show_bug.cgi?id=735233
This fixes the shell not picking updates to the contents of the underlying
.desktop files for application launchers, or when a .desktop file is
overriden by a user-installed one under ~/.local/share/applications
https://bugzilla.gnome.org/show_bug.cgi?id=773636
Ever since commit b8e29ae8c7
(I think), start up is littered with this message:
Gjs-WARNING **: JS ERROR: could not get remote objects for service
org.gnome.SettingsDaemon.Smartcard path
since gnome-shell is now started before gnome-settings-daemon.
This commit addresses the problem by making the object manager code
not try to autostart its proxy, and instead wait for it to appear.
https://bugzilla.gnome.org/show_bug.cgi?id=772589
If the call to settings.get_connection_by_path in
ensureActiveConnectionProps returns null, we'll hit a JS error here.
Seems to happen always when activating a VPN connection. Avoid that.
Giovanni says:
"I believe this is papering over an existing bug, but it's possible for
settings.get_connection_by_path() to legitimately return null (if the
connection is owned by a different user and invisible to the current
one), so the fix is correct anyway."
https://bugzilla.gnome.org/show_bug.cgi?id=759793
After having embedded a Gtk window, we start to listen for the
corresponding MetaWindow to know when it has been mapped by the
compositor. If the embedder does not realize the window immediately,
and some other window is created and mapped before the embedder
realizes the window, we would prior to this patch try to dereference
the not created GdkWindow. Fix this by NULL checking the GdkWindow
before dereferencing. We will never miss the needed MetaWindow creation
since it can not have been mapped have it not yet been realized.
https://bugzilla.gnome.org/show_bug.cgi?id=776130
This will be required in the upcoming version of GJS.
The reference count on ShellGlobal is 2 at this point, because JS holds a
reference due to the "window.global = Shell.Global.get()" line in
ui/environment.js. Therefore, destroy the GjsContext first, then unref
the ShellGlobal object.
Cleaning up ShellGlobal was previously only enabled behind a debug
environment variable, but it should be required now.
https://bugzilla.gnome.org/show_bug.cgi?id=775374
When a GNotification has the same ID as a previous one, it should
be shown as a new notification after withdrawing the old one.
However for this to work, we must not destroy the corresponding
source if withdrawing the old notification lets the notification
count drop to zero, so make sure the source is kept alive until
the replace operation has completed.
https://bugzilla.gnome.org/show_bug.cgi?id=775149
Clicking on calendar notifications might block till the DBus request times
out if the application being poked happens to be non-responsive. Perform
this asynchronously so we don't block if that is the case.
If an onComplete handler is passed to animate(), it is set to run at
the end of the animation via the icon grid's ::animation-done signal.
Currently the signal is connected after starting the animation, with
the result that the handler doesn't run when the animation completes
immediately (because there are no icons to animate). Fix this by only
starting the animation after connecting the signal.
https://bugzilla.gnome.org/show_bug.cgi?id=774381
We currently assume that the current view matches the 'app-picker-view'
setting. While that is usually the case, there is one notable exception:
While there isn't sufficient usage data (yet), we show all applications
instead of an empty frequent view regardless of the setting. We should
animate the actually visible icons in that case, not the (non-existent)
ones from the hidden frequent view.
https://bugzilla.gnome.org/show_bug.cgi?id=774381
