Speaking of usability: More important then progress metering or details
about, what is duplicity doing right now, might be guiding users through
error scenarios.
I didn't have a look at your frontend by now, but already know from
ftplicity development that there are some hurdles to be taken until
everything works flawlessly.
What does Deja Dup in case of errors, how does it support the user to solve
these?
As I said above, Déjà Dup just displays stderr and the user can't do
anything about it. With dbus and my patch, Déjà Dup can especially
handle some errors. For example, on a command line error, Déjà Dup
would say "Sorry, mate, I fucked up. Internal error." Which isn't
very helpful, but more meaningful than "command line error". On a
"source mismatch error", Déjà Dup can say "Hey, your sources don't
match. [Cancel] [Continue anyway]" and recall duplicity with
--allow-source-mismatch if the user chooses. But I can't do that at
all without IPC. Right now if sources mismatch, the user is SOL.
duplicity allows already as your Deja Dup 1.0 clearly proves, there's just
no majority for dbus integration now
But I want to make a Déjà Dup 2.0.
Take for example the warning duplicity shows when it finds leftover
files that can be cleaned by "duplicity cleanup". That's useful for a
frontend to know (so it can run the command for the user).
actually if there are leftovers, this is asign that something broke in the
middle. So the user should be bothered at least with a warning.
If the user cancels, they have left overs. And Déjà Dup (in bzr)
automatically calls "cleanup" if the user cancels, but we'd still end
up with cruft if for some reason Déjà Dup got killed or some error
occurred halfway through.