Bugzilla – Full Text Bug Listing
| Summary: | provide preview of task context | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ekuleshov, wmitsuda |
| Version: | unspecified | ||
| Target Milestone: | 2.0 M1 | ||
| Hardware: | Other | ||
| OS: | other | ||
| Whiteboard: | |||
|
Description
Mik Kersten
Wouldn't it make more sense to show this information in task properties? This custom tooltip hides other tasks when you trying to browse trough the list. Yes, the size of the tooltip may be problematic. Let's use this report for design discussion before making this a tooltip. That reminds me to name reports with the requirement and not the mechanism to implement the requirement ;) Some ideas of how we can implement this for Mylar 2.0: CONTEXT DISPLAY: * Full Context display for the purpose of preview (e.g. before commit): provide a Context tab on the Task Editor, which displays the task context. The primary display mechanism should probably be the tree view, but we can also use the Visualiser view which we had working way back (bug 106935). * Allow elements to be removed from the task context (bug 147802), e.g. if something becomes interesting but should not be committed. * This display can also be used for merge purposes (bug 138544), providing facilities such as highlighting the incoming and overlapping context elements. * Will work whether or not the task is active. CONTEXT THUMBNAIL: * As part of the tooltip, we show the 3 or so highest-interest landmarks for the task context. This will require a persitent map of task->landmarks, which will be useful for other purposes as well (e.g. context search, bug 137486). Context display done via "Context" tab on task editor, might do a bit more finessing or improvements of functionality. Mik, it seems like context is not shown if workspace don't have correspond resources/projects. It doesn't seem right. Yes, that's a very good point, because while this functionality is already useful (e.g. shows decayed elements and allows deletion), it is not complete without that. I filed bug 174413 last night for that, we will do it via a custom content provider. I didn't want to do a quick iteration on it because a naive algorithm could end quadratic or worse complexity in trying to not show elements in both the content provider and the Orphaned node. But it won't be that hard to do it, might just need an additional data structure. I'm itching to add "merge context", but I don't know if I want to do that without providing highlighting. The more I thin about it, the more it seems like something is not right. I don't think you actually need concept of orphaned nodes, nor you should look into the present resources. So, context view should operate only on context data and just do aggregation to show tree-like structure. Then you can also show last event type and maybe use color coding for deleted elements. (In reply to comment #4) > Context display done via "Context" tab on task editor, might do a bit more > finessing or improvements of functionality. BTW, that slider widget is totally unintuitive. Why don't you use dropdown or even a list instead? Also, it would make sense to show actions and controls on the right side of the context, and those section headers seem redundant waste of the screen real estate. TODO: editor page needs to refresh when context is activated and editor for the corresponding task was already open. How about all the Open actions? Also it would be neat if context tree would show something about shown elements, ie. browsed, changed, added, deleted, etc... Context preview/editor is done. Created new bug 174659 for thumbnailing (comment#3). Refresh will be covered by new bug 174658. Regarding comment#10, I'm a bit torn about the open actions because the main use case is not navigation, and editors are generally poor for navigation because they get obscured. So let's get some usage for a while before adding more actions, but open actions are definitely a candidate because some of the elements that show in the preview are not easily accessible in a focused view (e.g. decayed ones). *** Bug 170586 has been marked as a duplicate of this bug. *** |