SignalRun Lastadd-SignalRun Lastbasic-The ::basic-auth-start signal gets emitted when a basic user/password
authentication is needed during the operation. If the caller handles this
it should ask the user for the user and password and return true. Once
the information is gathered call flatpak_transaction_complete_basic_auth()
with it.
If the client does not support basic auth then return false from this signal
(or don't implement it). This will abort the authentication and likely
result in the transaction failing (unless the authentication was somehow
optional).
SignalRun Lastchoose-The ::choose-remote-for-ref signal gets emitted when a remote needs to be selected during the execution of the transaction.
SignalRun Lastend-The ::end-of-lifed signal gets emitted when a ref is found to be marked as end-of-life during the execution of the transaction.
SignalRun Lastend-The ::end-of-lifed-with-rebase signal gets emitted when a ref is found to be marked as end-of-life before the transaction begins. Unlike Flatpak.Transaction.SignalSignatures.end_of_lifed | Flatpak.Transaction::end-of-lifed, this signal allows for the transaction to be modified in order to e.g. install the rebased ref.
If the caller wants to install the rebased ref, they should call
flatpak_transaction_add_rebase_and_uninstall() on rebased_to_ref and ref,
and return true. Otherwise false may be returned.
SignalRun Lastinstall-The ::install-authenticator signal gets emitted if, as part of resolving the transaction, we need to use an authenticator, but the authentication is not installed, but is available to be installed from the ref.
The application can handle this signal, and if so create another transaction to install the authenticator.
The default handler does nothing, and if the authenticator is not installed when the signal handler fails the transaction will error out.
SignalRun Lastnew-The ::new-operation signal gets emitted during the execution of the transaction when a new operation is beginning.
SignalRun Lastoperation-The ::operation-done signal gets emitted during the execution of the transaction when an operation is finished.
SignalRun Lastoperation-The ::operation-error signal gets emitted when an error occurs during the execution of the transaction.
SignalRun LastreadyThe ::ready signal is emitted when all the refs involved in the operation
have been resolved to commits, and the required authentication for all ops is gotten.
At this point flatpak_transaction_get_operations() will return all the operations
that will be executed as part of the transaction.
SignalRun Lastready-The ::ready-pre-auth signal is emitted when all the refs involved in the transaction have been resolved to commits, but we might not necessarily have asked for authentication for all their required operations. This is very similar to the ::ready signal, and you can choose which one (or both) to use depending on how you want to handle authentication in your user interface.
At this point flatpak_transaction_get_operations() will return all the
operations that will be executed as part of the transaction. You can call
flatpak_transaction_operation_get_requires_authentication() to see which
will require authentication.
SignalRun Lastwebflow-The ::webflow-done signal gets emitted when the authentication finished the webflow, independent of the reason and results. If you for were showing a web-browser window it can now be closed.
SignalRun Lastwebflow-The ::webflow-start signal gets emitted when some kind of user
authentication is needed during the operation. If the caller handles this
it should show the url in a webbrowser and return true. This will
eventually cause the webbrowser to finish the authentication operation and
operation will continue, as signaled by the webflow-done being emitted.
If the client does not support webflow then return false from this signal
(or don't implement it). This will abort the authentication and likely
result in the transaction failing (unless the authentication was somehow
optional).
During the time between webflow-start and webflow-done the client can call
flatpak_transaction_abort_webflow() to manually abort the authentication.
This is useful if the user aborted the authentication operation some way,
like e.g. closing the browser window.
SignalDetailedActionRun FirstnotifyThe notify signal is emitted on an object when one of its properties has
its value set through g_object_set_property(), g_object_set(), et al.
Note that getting this signal doesn’t itself guarantee that the value of
the property has actually changed. When it is emitted is determined by the
derived GObject class. If the implementor did not create the property with
GObject.ParamFlags.EXPLICIT_NOTIFY, then any call to g_object_set_property() results
in ::notify being emitted, even if the new value is the same as the old.
If they did pass GObject.ParamFlags.EXPLICIT_NOTIFY, then this signal is emitted only
when they explicitly call g_object_notify() or g_object_notify_by_pspec(),
and common practice is to do that only when the value has actually changed.
This signal is typically used to obtain change notification for a
single property, by specifying the property name as a detail in the
g_signal_connect() call, like this:
g_signal_connect (text_view->buffer, "notify::paste-target-list",
G_CALLBACK (gtk_text_view_target_list_notify),
text_view)
It is important to note that you must use [canonical parameter names][class@GObject.ParamSpec#parameter-names] as detail strings for the notify signal.
The ::add-new-remote signal gets emitted if, as part of the transaction, it is required or recommended that a new remote is added, for the reason described in
reason.