gnome-software:wip/kalev/new-permissions-notification

Last commit made on 2019-11-20
Get this branch:
git clone -b wip/kalev/new-permissions-notification https://git.launchpad.net/gnome-software

Branch merges

Branch information

Name:
wip/kalev/new-permissions-notification
Repository:
lp:gnome-software

Recent commits

06194a4... by Kalev Lember <email address hidden> on 2019-10-04

update monitor: Show a notification when an app requires new permissions

Don't just silently skip apps that require new permissions, but instead
show a shell notification with the app name so that the user knows that
it has been kept back.

0ca6498... by Cédric VALMARY (Tot en òc) on 2019-11-19

Update Occitan translation

c53c670... by Philip Withnall <email address hidden> on 2019-11-19

gs-common: Stop storing GtkCssProvider redundantly

It’s already stored within the `GtkWidget` with a strong reference.
Nothing else refers to `GnomeSoftware::provider`, so we can safely drop
this.

Signed-off-by: Philip Withnall <email address hidden>

fed85f0... by Philip Withnall <email address hidden> on 2019-11-13

gs-common: Require a CSS class name for custom CSS

Rather than building one out of the pointer to the widget name, require
a hard-coded one. CSS class names are interned into the global `GQuark`
table by GTK, so constructing a different one for each widget means that
table grows without bound. That is bad — all those strings are
(deliberately) leaked, and every addition slows the quark table down a
bit.

In order to allow the same class name to be reused across multiple
widgets without interfering, install the custom `GtkCssProvider` only on
the given widget instance, rather than for the entire screen.

Signed-off-by: Philip Withnall <email address hidden>

5800e1e... by jimmac on 2019-11-19

banner: Transmission

avoid using app icon

107bbef... by jimmac on 2019-11-18

banners: Maps -- avoid using app icon

See https://gitlab.gnome.org/Teams/Design/software-mockups/issues/2 for discussion.

a014b3d... by Philip Withnall <email address hidden> on 2019-11-12

flatpak: Ensure use of the installed_refs cache is thread-safe

Just like the `broken_remotes` cache, the `installed_refs` cache is
shared between multiple threads. Previously, there was no mutex
protecting access to it, so one thread could replace it while another
was using it. Or, more typically (which is how I spotted this), two
threads would race to call `flatpak_installation_list_installed_refs()`
to populate it; one would win, and the other thread’s value would be
leaked.

This was resulting in 80KB of leaks after a few minutes of using
gnome-software.

Signed-off-by: Philip Withnall <email address hidden>

d35f942... by Philip Withnall <email address hidden> on 2019-11-12

gs-details-page: Fix a minor leak in a comparison function

Signed-off-by: Philip Withnall <email address hidden>

0995572... by jimmac on 2019-11-19

featured: Foliate

- avoid using the app icon

4115298... by Will Thompson on 2019-11-15

meson: make two compiler warnings fatal

I wasted the best part of an hour this morning because I didn't notice
the following warnings (from Endless's branch):

    ../plugins/eos-blacklist/gs-plugin-eos-blacklist.c: In function 'gs_plugin_setup':
    ../plugins/eos-blacklist/gs-plugin-eos-blacklist.c:193:36: warning: implicit declaration of function 'flatpak_installation_get_default_locales'; did you mean 'flatpak_installation_get_default_languages'? [-Wimplicit-function-declaration]
        priv->flatpak_default_locales = flatpak_installation_get_default_locales (priv->installation, &local_error);
                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                        flatpak_installation_get_default_languages
    ../plugins/eos-blacklist/gs-plugin-eos-blacklist.c:193:36: warning: nested extern declaration of 'flatpak_installation_get_default_locales' [-Wnested-externs]
    ../plugins/eos-blacklist/gs-plugin-eos-blacklist.c:193:34: warning: assignment to 'char **' from 'int' makes pointer from integer without a cast [-Wint-conversion]
        priv->flatpak_default_locales = flatpak_installation_get_default_locales (priv->installation, &local_error);

My Flatpak headers were older than my Flatpak shared library, which did
define the 'flatpak_installation_get_default_locales' symbol. The
default return type, int, is narrower than a pointer on x86_64 so the
pointer was truncated and this would crash at runtime.

Of course, I could have passed `-Dwerror=true` to Meson but I believe
that implicit-function-declaration and nested-externs should always be
fatal, regardless of that setting.

Another option would be to add 'werror=true' to default_options, but I
think this is bad practice: a new compiler version could cause perfectly
good code to stop compiling.