In hindsight connect() was a poor choice of name as this is hardcoded
as the GObject parent method for signal attachment. It's not actually
required when using the sync API in Python as it's called when required.
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
We forgot to include FwupdClientDownloadFlags when adding the original method
fwupd_client_install_release() -- and we want to use additional download flags
for operations in the future.
From Philip's guide: "Never iterate a context created outside the library,
including the global-default or thread-default contexts. Otherwise, GSources
created in the application may be dispatched when the application is not
expecting it, causing re-entrancy problems for the application code."
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
Use the 'default' main context by default so that we still get the signals
delivered via g_object_notify() but allow the library user to specify an
alternate GMainContext as required.
Using g_main_context_push_thread_default() works for PackageKit as signals are
returned using g_signal_emit() which is synchronous, and so doesn't use the
main context at all.
Use the same style of API which we did for libgusb all those years ago instead.
I'm porting gnome-software to use this new API and this would be a very useful
thing to provide. No async API as we want to avoid writing temp files in most
cases -- this is just for legacy apps.
For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
