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.
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>
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>
a014b3d...
by
Philip Withnall <email address hidden>
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>
gs-details-page: Fix a minor leak in a comparison function
Signed-off-by: Philip Withnall <email address hidden>
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.
