Bugzilla – Full Text Bug Listing
| Summary: | warn when copying context to a task that already has context | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Sam Davis <sam.davis> | ||||||||||||
| Component: | Mylyn | Assignee: | Sam Davis <sam.davis> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | enhancement | ||||||||||||||
| Priority: | P3 | CC: | shawn.minto, steffen.pingel | ||||||||||||
| Version: | unspecified | Keywords: | contributed, noteworthy, plan | ||||||||||||
| Target Milestone: | 3.5 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows 7 | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Sam Davis
Great suggestion. A popup dialog that asks to add or replace would be a nice enhancement. Sam, did you want to submit a patch for this? I'll look into this. Created attachment 186131 [details]
Patch
This adds the interaction events from the source task's context to the target context. This may result in the target context's events not being ordered by date, but I don't think that should matter.
Created attachment 186132 [details]
mylyn/context/zip
Created attachment 186773 [details]
patch
I just removed an unused empty method I had added by mistake.
Created attachment 188110 [details]
screenshot
That's an awesome patch! I wonder though we should make this API on IInteractionContext. To me it seems that this would allow working around the event processing in InteractionContextManager and make the interface inconsistent. What do you think about adding a merge() method to LocalContextStore or keeping this internal? Shawn, do you have any thoughts on that? Whatever you think makes sense. One thing I didn't really realize until I tried using this is that after you merge 2 contexts, the elements in the merged context that are interesting might all come from only one of the original contexts. We could try to change the date stamps on events or somehow normalize interest levels between the 2 contexts, because the user might expect/want the set of interesting elements in the merged context to be roughly the union of the interesting elements in the 2 original contexts. Otherwise, the difference between Replace and Add might not be noticable in some cases. On the call today it was suggested to rename "Add" to "Merge" in the UI. I would propose to add an internal method to LocalContextStore that implements the merge operation. (In reply to comment #9) > One thing I didn't really realize until I tried using this is that after you > merge 2 contexts, the elements in the merged context that are interesting might > all come from only one of the original contexts. We could try to change the date > stamps on events or somehow normalize interest levels between the 2 contexts, > because the user might expect/want the set of interesting elements in the merged > context to be roughly the union of the interesting elements in the 2 original > contexts. Otherwise, the difference between Replace and Add might not be > noticable in some cases. That's very interesting. If there is an easy way to normalize that it sounds good to me, otherwise the current approach should be okay as well. I'll try to look into that on Monday. Created attachment 189246 [details]
moved to internal merge method and changed to merge in UI
Steffen, here's an updated patch.
Great work on this Sam! I have committed this patch. Before committing, I updated this so that the editor memento is only copied if there wasn't already one for the active task. Can you create a bug to improve this by normalizing the interest values? 337768: Normalize interest values when merging contexts https://bugs.eclipse.org/bugs/show_bug.cgi?id=337768 |