In a discussion on the design list*, Mimi asked for implementation
perspective for a change to cause all the columns to not reorder
immediately when the user changes an item attribute that affects the
current sort.
The triage column currently does this, by keeping two sets of triage
attributes: one set is always present, and controls the color of the
triage button in the detail view and dashboard, and changes immediately
when the user clicks on a button; the other set is only present when an
unpurged triage status change exists on the item (eg, the user clicked
on a button but hasn't clicked the Triage toolbar button yet) -- the
index mechanism uses it in preference to the first set if it exists.
One way to accomplish this change would be to double all the attributes
this way - this probably wouldn't affect indexing performance too badly
(though the index comparison functions would look pretty ghastly).
However, I don't think this approach would scale well (and our items are
already pretty heavy with attributes) -- however, I haven't thought of
another approach yet. I'm also concerned with how new items (say,
received by sharing) would get ordered in an unpurged collection.
Anyone have any ideas?
...Bryan
*
http://lists.osafoundation.org/pipermail/design/2007-November/thread.html#7789
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
