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.
There are a couple of places where this "instead" could be implemented,
either centrally at the table-data level (anytime we do
get-item-for-row, convert to occurrence -- or even proxy-wrap it too,
saving work at higher levels), or in each attribute editor. (The former
has the advantage that we could avoid putting equivalent code in the row
operations -- delete, drag-and-drop, etc).
However, this facade breaks the notification mechanism: changes made
elsewhere (in the detail view, triageStatus upon starttime being
reached, sharing changes, etc) wouldn't trigger collection
notifications; maybe the proxy wrapper could force an innocuous change
to the master to trigger the notification, or generate fake collection
notifications itself?
Or, as a separate suggestion, Is it time to reconsider whether
occurrences belong in collections? (I'm under the impression that it's
to simplify sharing, but since sharing already has to special-case
private items in shared collections, maybe special-casing occurrences at
the same level would be no harder?)
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
