[chandler-users] Alarms beating sync!
cubranic at cs.ubc.ca
Thu Aug 14 10:49:20 PDT 2008
On Thu, 7 Aug 2008, Paul Mattal wrote:
> 2) Go home and open Chandler at home.
> 3) First, Chandler processes all of its alarms.. the OLD ones for all the
> items above. This kicks them all into NOW.
> 4) Then Chandler syncs the collections and gets the new alarms. However,
> since the state change was more recent (I think), the LATER state stored in
> the collection is applied as a "pending change".
> 5) I spend at least 10 minutes clicking each item and applying the pending
> changes and getting myself back to the state I was looking at when I left
> Is there any way around this? Something that blindly applied all pending
> changes would even be fine for me. Or some way to keep the alarms from
> triggering before the first sync.
I use Chandler very similarly to Paul and regularly suffer from the same
issue. I think what would really fix this issue (as opposed to papering
over the bug with "resolve all conflicts" menu action) is if Chandler
could distinguish between actions that it did automatically at a certain
time vs. a consequence of the user's action.
In Paul's example, when the second Chandler moves the item to NOW
because of its due date or alarm and then syncs to find a conflict with
the same item set to LATER because a user changed the due date earlier
on, the remote change should automatically override the local one.
I'm not sure how feasible this would be to implement, but I do believe a
better resolution of these kinds of "fake" conflicts is important to the
user experience with Chandler Desktop.
More information about the chandler-users