On 8 Sep, 2006, at 15:34, Mimi Yin wrote:
This would be a good first step towards what we would eventually
like for recurring events in the Dashboard: http://
svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/Dashboard-0.7.html
Here's what I understand from this:
1) We should show modifications in the summary table. This comes from
the requirement that we want to show occurrences that have been
triaged. Note that these really are modifications to the master: they
have different triageStatusChanged/lastModified values (and therefore
have a different value in the date column).
2) Jeffrey's idea of showing the "next relevant occurrence" makes
sense. Perhaps we can even get away with showing this as a
placeholder for the master, except for:
3) There are some cases where no occurrences exist, only the master.
These are somewhat pathological, but users could accidentally get
into this state (e.g. by mistyping the "until" date).
Anyway, the design question here is to figure out specifically what
events/occurrences we need to display so that people can see/edit
their events. This includes some tricky cases, like modifications or
deletions to the master itself, or #3 above. Or, say, a case where
you have a weekly event, and want to delete the occurrence that
occurs in three weeks' time, which isn't shown in the dashboard.
<<This really belongs on chandler-dev, but it follows on from the
previous stuff>>...
On the implementation side, much as been made of the difficulty of
retrofitting the existing collection-based model to support having
various and sundry occurrences and/or masters floating around in the
summary table. I think the easiest approach is to create a filter on
the collection of all events (much as we do to filter out non-masters
today). That filter would be very simple: it would check a Boolean
attribute on the events, and the domain model would be responsible
for maintaining that attribute. I don't think this is an
inappropriate infiltration of UI requirements into the model layer.
--Grant
On Sep 8, 2006, at 3:16 PM, Philippe Bossut wrote:
Jeffrey Harris wrote:
The first thing that comes to mind for me is that perhaps instead of
always displaying the master, we want to display the next relevant
occurrence in the table view, taking the current time and triage
status
into account. I expect doing that would be quite a bit of work,
but at
least it wouldn't involve varying numbers of rows per item like
displaying several occurrences alongside a master would.
+1
Since the table view is now the Dashboard, we should see in
priority here things that are upcoming next or close to (Now or
Later).
For the "changing the triage status to unique occurrences" issue,
why can' we have a "All, All future, This one only" dialog? IOW,
isn't the triage status an attribute of the item and should
trigger the same behavior as other attribute change? (obviously a
naive question but I thought I ask to clarify the problem)
Yes this is the desired behavior.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
