While gnome-shell will now check for extension updates, the checks
are performed infrequently. Opening the Extensions app implies that
the user's current focus is on extensions, so it is an appropriate
time to schedule another updates check.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we can download, apply and display extension updates, it is time
to actually check for updates. Schedule an update check right on startup,
then every 24 hours.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Now that we have support for extension updates in the shell, we
need some place to display the updates to the user.
As we are establishing the Extensions app as the primary way for
managing extensions, it's a natural place for that functionality.
Show which extensions have updates available, and offer a log out
button (so gnome-shell can apply the updates when logging back in).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Until now, it didn't matter whether an extension was installed in the
user's home or system-wide. However with support for uninstallation,
there is now a significant different, as that action is only available
for user extensions.
Account for that by separating extensions by type, so that users don't
have to second-guess which extensions can be fully-managed and which
appear as part of the system.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The newly added expander gives us a place where we can display
more details without cluttering the interface.
Take advantage of that by including the extension website, version
and author.
(Author is in the mockups, but will not actually be shown until
the extensions website is changed to include it in its metadata;
however best to have UI and string in place for the freezes)
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The description can be useful information, but also increases the
visual complexity of the extensions list. Move it into a hidden
details area that can be expanded, which unclutters the interface
while keeping the information readily available.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
The current fixed two-line label requires a custom widget, which
make moving to a widget template harder.
As the description will soon move elsewhere anyway, just go back
to a single line with a standard label for now.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Extensions can have a major impact on stability and performance. Now that
the tool will become the main way for users to manage their extensions, it
is an appropriate place to warn the user of that risk.
Add a small info popover to the headerbar to display that warning, together
with the previously removed hint of where to go for finding new extensions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently when the extensions list is scrolled, it is possible to
keynav out of view, as the scrolling doesn't follow the key focus.
Hook up the adjustment to fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
Currently the main window is a plain Gtk.ApplicationWindow that is
built and managed from within the application.
As the application becomes more complex, it makes sense to decouple
the two and handle the window from a separate ExtensionsWindow class.
Not least this is a prerequisite of using a widget template for the
window.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
GNOME Software will remove its extension support, so we should stop
referencing it in addition to extensions.gnome.org.
In fact, the placeholder is not the best place to hint at where new
extensions can be found, as the user will never see it in case the
distribution includes pre-installed extensions.
So remove the hint altogether, we will add it back in a more prominent
place later.
With the whole placeholder now being much lighter, we can stop dimming
the remaining elements.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
If all password entries in dialogs are hidden, there is either an entry
that has visible characters or no entry at all. That means we don't have
to show the caps lock warning at all, so hide it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the headlines of the dialogs now use a much larger font, the
strings need to be shorter so they won't be ellipsized. So use a shorter
strings for those titles and also adjust the title-strings of the
notifications sent by the NetworkAgent to be consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the wiggle effect will be used by the redesigned prompt-dialogs
and we always want to use the same parameters, move those as defaults
for the wiggle function to the util.js file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the caps-lock warning adds a lot of spacing to dialogs and the
lock screen, hide it by default and only show it when necessary. To make
the transition smooth instead of just showing the label, animate it in
using the height and opacity.
Also add some bottom padding to the label so we can show or hide that
padding, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The caps-lock warning is more related to entries than dialogs and is
also used in gdm, which is not realated to dialogs at all. Rename the
css class to caps-lock-warning-label and move it to the entry
stylesheet.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/952
The Animation class inherits from St.Bin and manages the scale factor
in the image loading, but the widget size doesn't change and doesn't
depend on the scale factor so when the scale factor is different
from 1 the widget size doesn't match the image size.
This patch resizes the Animation widget using the scale factor so the
widget will match the animation images sizes.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1746
Now that we have a way to check for updates and download them, we
should actually apply them as well. Do this on startup before any
extensions are initialized, to make sure we don't run into any
conflicts with a previously loaded version.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
While it is possible that an extension has a newer version available
than the previously downloaded update, it's more likely that we end up
downloading the same archive again. That would be a bit silly despite
the usually small size, so we can either use the metadata from the
update, or exclude the extension from the check.
The latter is much easier, so let's go with that for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/945
