On Thu, 2010-03-25 at 22:24 +0000, Jussi Kukkonen wrote:
Apropos... I was thinking how to solve the problem QA reported: that
autosync works like a black box: you just turn it on and have no idea if
it's working or when it's going to work.
I liked the idea of showing "last synced an hour ago, syncing again in
30 minutes" to solve this the best. Looking at the server code, it
doesn't seem like I can make that sort of estimates though (not without
True, we would have to add a D-Bus signal that is sent out each time a
sync is scheduled or descheduled. Trying to guess that in the GUI would
duplicate the logic that is used for that in the server.
Should we send out the remaining minutes regularly while the server is
waiting, say every five minutes, or should the GUI implement its own
countdown? If it is sent regularly, the GUI and API become easier (no
need to do anything except for reacting to the signal, no need for a
"get" method). The drawback is of course coarse update intervals of the
display or frequent D-Bus traffic.
Perhaps we should also inform why a sync is not scheduled yet. "Waiting
for peer to become available", "peer available for x minutes, waiting
for system to settle down" (autoSyncDelay). Not very good explanations,
Or maybe I can, if I show something more vague
when it seems that a autosync time would be close: "...syncing again soon"?
Same problem - how do you know it is "soon"?
Any other bright ideas? Some already presented were:
* show the interval in UI: this is ok, but doesn't really fill me
(the user) with confidence that something is happening
* mention the sync method in the last-synced message:
"Last synced an hour ago (automatic sync)": This still doesn't
work right after I enable autosync...
The second option is our best bet right now, but I agree, it doesn't
really help much in the "autosync enabled first time" case, exactly when
the user wants some reassurance. Perhaps we should better go for the
more complex solution right away.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.