Mimi,
Again, replies inline.
...Bryan
Mimi Yin wrote:
Okay, there are a couple of doozies in here...see in-line Mimi
On Feb 15, 2007, at 5:10 PM, Bryan Stearns wrote:
[...]
OK, so if I interpret your first question another way: the time you
entered for the alarm is still "11:00 AM", but you hit "enter" to
apply it after waiting for your clock to change to "10:59AM", then
carefully counting "1-mississippi, 2-mississippi" ...
"56-mississippi, 57-mississippi, 58-mississippi, <enter>!" The "LATER
if the start date is in the future or if there's an alarm in the
future" case applies: the event's button triageStatus will be set to
LATER, button triageStatusChanged will be set to "11:00 AM", but it's
sort order won't change (because its previous button triageStatus and
button triageStatusChanged will be copied to sectionTriageStatus &
sectionTriageStatusChanged first).
Right away, though, probably imperceptibly later, the alarm will
fire, which triggers a different autotriage rule: the item will get
its button triageStatus set to NOW. (The code will also set button
triageStatusChanged to the alarm time, 11:00AM, but it already has
that value.) Because we don't move unpurged items willy-nilly,
though, the item won't
move to the top of Now until the user purges...
Aack, I think this was another miscommunication. Can't believe we
didn't catch it until now. Tickling in my own Chandler should move
items willy-nilly. Just like Updates and Errors.
(...Unless you tell me now that this is another case where we want to
override unpurged state, and toss sectionTriageStatus &
sectionTriageStatusChanged, so that the item *does* immediately pop
to the top of the Now section in this case.
Haha. You anticipated my reaction above. Yes the will-nilly comment
was ONLY intended for sharing and is discussed in the context of sync
in the spec.
OK, I've added a note to the spec to reflect that when a start time is
reached or an alarm goes off, the item will change button color (to NOW)
and move overriding any pending sectionTriageStatus (which will be
discarded).
Note that this is distinct from the similar case of an alarm firing
on an event just after the user had clicked on a triage widget: that
case would never pop to the top when the alarm fires because we turn
off auto triaging when the user creates an unpurged state by clicking
on the widget, remember?)
Doh!? We turn off auto-triaging based on the user assigning and/or
changing date/time information on the item. We never turn off
auto-triaging based on time passing, aka tickling. So if I explicitly
triage something to LATER, I still want the item to pop-back into NOW
automatically when the alarm fires.
Yes - I put this in because your spec clearly says so: "Caveat:
Auto-triaging triggered by users assigning and changing date/time
information to items stops if the user 'explicitly' triages the item by
either:
* Clicking on the triage status button in the mark-up bar or the triage
column in the Dashboard
* *Item is triaged to NOW because and alarm fires or event date/time
passes*"
But since you're now saying you don't want that, I've updated my spec to
reflect this.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
