There is a convention for setting up a request and cancelling it in other portals already: org.freedesktop.impl.portal.Request.
The Close method does what is currently on the org.freedesktop.impl.portal.experimental.Credential.Ceremony.Cancel() does, so it wouldn't very different, just a different interface and method name.
The UserInteracted::RequestCancelled event could be accomplished by listening for the InterfacesRemoved for the object path and org.freedesktop.impl.portal.experimental.Credential.Ceremony or org.freedesktop.impl.portal.Request interfaces. An application would need to do this anyway to be robust against the backend crashing and not emitting the RequestCancelled signal.
This would change the Initialize method to accept an object path generated by the frontend, which means that the frontend can subscribe to the UserInteracted signal before initializing the request, eliminating the need for the Ceremony.Start() method.
We should move in this direction for consistency and more robust cancellation.
There is a convention for setting up a request and cancelling it in other portals already:
org.freedesktop.impl.portal.Request.The
Closemethod does what is currently on theorg.freedesktop.impl.portal.experimental.Credential.Ceremony.Cancel()does, so it wouldn't very different, just a different interface and method name.The
UserInteracted::RequestCancelledevent could be accomplished by listening for theInterfacesRemovedfor the object path andorg.freedesktop.impl.portal.experimental.Credential.Ceremonyororg.freedesktop.impl.portal.Requestinterfaces. An application would need to do this anyway to be robust against the backend crashing and not emitting the RequestCancelled signal.This would change the Initialize method to accept an object path generated by the frontend, which means that the frontend can subscribe to the UserInteracted signal before initializing the request, eliminating the need for the Ceremony.Start() method.
We should move in this direction for consistency and more robust cancellation.