Hi John,
You are right, that was the spec back in 0.4 when the bug was originally
logged. I think the current plan is to come up with an updated spec,
sometime before alpha3. The new updated spec will take into
consideration sharing and collaboration scenarios, extensibility
requirements (how 3rd party parcels might plug in), etc.
I've reassigned this bug to Ted, and it is scheduled for alpha3.
Note that we are trying to respect the staging proposed by the ppd team,
so that they can schedule their work as well.
Cheers,
Katie
John Anderson wrote:
I think Mimi has already nailed down how she thinks the end-user design
ought to work. The following is taken from a spec referenced in Bug
#2167: Who, Date, not always showing the right attribute.
* *Who column*
* Notes, Tasks, Events - Who - Blank (to the user)
* Messages - Who (from) or (to) - Display *from* if it's incoming
mail. Display *to* if it's outgoing mail.
* Shared messages - Who (from) or (to) - Display *from* if the
sender is me. Otherwise, display *to*.
* *About column*
* [*OI^?
<http://wiki.osafoundation.org/bin/edit/Glossary/OpenIssue?topicparent=Projects.SummaryTableViewSpec>*]
There is a proposal to change the About column to be Subject for
all Kinds. Otherwise, it should be:
* Notes, Tasks, Calendar - About (Title) - Title
* Email - About (Subject) - Subject
* *Date column*
* The following proposal is contingent on the ability to display an
icon in the same cell as text in the summary table widget
* Which date to display in order of priority:
1. Calendar date (if Alarm date is dependent on the Calendar
date: ie. 15 minutes before)
2. Alarm date (even if there is a calendar date so long as the
alarm date is a custom date)
3. Date sent or Date received
If you think this isn't the right way to go, you might follow up with her.
John
Ted Leung wrote:
John Anderson wrote:
I'm planning on getting rid of redirect attributes to handle the Who,
About and Date attributes in the Summary Table. Instead I plan to add
an explicit Who, About and Date attribute. By noticing when
attributes that affect the value of Who, About or Date change (using
onValueChanged), I'll update Who, About and Date as necessary.
This is simple to implement and eliminates the current problem where
Who, About and Date sometimes doesn't display the correct value. It
also doesn't require a special "computed attribute" that isn't stored
in the repository, so you can always search for Who, About and Date
like any other attribute. Finally, it allows Andi to get rid of
redirect, which simplifies the repository design.
I think we need to take a step back here and really nail down how the
end-user design ought to work. Then we can figure out what the right
thing to do at the implementation level(s) ought to be.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
