Hi Bryan, > User Interface / Interactions: > > - Are you providing the API to determine which "occurs" choice should be > selected, or am I supposed to figure that out? Likewise, are you > providing the custom string for recurrences that don't map to ours?
I'd forgotten about those, I've added isCustomRule() and getDescriptionString() to the API. > - How is the "never" case presented and implemented for the recurrence > "ends" field? Good question, Mimi or Sheila? > Modifications in the detail view: > > - It seems wrong that only the calendar related fields cause the dialog; > any change to any attribute of the item, whether calendar-related or > not, should cause the alert and trigger the resulting exceptional > processing. > > - (I don't know the answers to any of the "Issue: [Jeffrey]" questions > you ask in this section, but I think the answers need to be worked out!) I think in general changes to any UI facing field should trigger an alert or modification, probably the best thing to do would be to define which fields SHOULDN'T trigger. I imagine we'll bump into exactly which attributes these are as we implement recurrence, so I haven't been blocking on not knowing the answer to this yet. > Unstamping a recurring event: > > - Presumably, unstamping a recurring event will forget about all > recurrence, so the choices in the dialog shown aren't appropriate. > (Actually, I think "change/remove/delete" is bad: the message and > buttons presented should always be operation-specific.) I agree that the dialog message and buttons should be operation specific. From a content model perspective, essentially the same thing is happening, but we should present the options in contextually relevant English. I don't think unstamping a single occurrence's eventness necessarily should apply to all other occurrences. If it applies to future occurrences and there are no other recurrence related mixin kinds, that probably means that future occurrences are deleted. If it applies to all, it probably means all but the current occurrence should be deleted. But I agree this should be spelled out more clearly. > - What's "editsAreUnsafe"? Typo, should've been setAttributeSafely. > - It looks like not only UI code, but any modification to ContentItem > attributes must go through this mechanism, right? Yes, although Ted's busily trying to convince me there's a better way, I hope he's right ;). > - I don't know what this means: "Modifications will by default apply to > THIS if currentlyModifying is None, but such changes result in warnings > being logged." What log? What for? The general Chandler log, for debugging, because it's reasonably likely a change made with currentlyModifying == None is a mistake. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
