Community
Participate
Working Groups
Steffen mentioned the need for a category that aggregates all incoming. This would simplify reviewing new incoming (ideally sorted by modification date). We may want to contribute this to all tasklist modes.
-1 I don't think category is really great idea. I think "incoming only" filter would work better.
Steffen, perhaps you could post your thoughts here regarding adding filter completed to the tasklist toolbar since these two seem like similar use case.
Yes, that would be nice. Like a filter on the task list. One reason why I still can't completely rely on Mylar to track incoming changes is that completed tasks automatically disappear. These should be displayed as long as they have incoming changes even when filtering of completed tasks is on (I can't find the corresponding bug).
Completed tasks are displayed if they have incoming changes, and I haven't seen any bugs with that. There is the scenario where you have a query for only open tasks, and so once resolved those will disappear from your query. But because we have "guaranteed visibility" for tasks with incoming, they will end up showing in the archive category. While I think we could have an "incoming" presentation mode, I think that having a separate category would be a slippery slope so I'm changing the description to focus on the problem.
*** Bug 177664 has been marked as a duplicate of this bug. ***
In my task list completed tasks are filtered regardless of their change status. When I toggle the filter I can see all the tasks returned by the query (including completed ones with an incoming icon). Is there a setting for that or has that been fixed recently in CVS head (I am still running the EclipseCon dev build and 3.3M5 on my notebook)?
I haven't seen this either (at least on windows). Sounds like we need a new bug report.
Steffen: they're only unfiltered this way in Focus on Workweek mode, which forces things you need to see to become visible. Perhaps you're seeing this in the unfocused mode?
Thanks for the hint Mik, that fixed it. Now I need a way to mark tasks as read without having to create task objects for all query hits (bug 159221) and not have all hits marked as having incoming changes when creating a query (bug 177591) :).
*** Bug 195744 has been marked as a duplicate of this bug. ***
Rob: I think that we should at least experiment with this for 2.1
Some more suggestions to improve the incoming presentation: * Order incoming changes chronologically * Indicate which bugs have had the most activity since last read * Allow quick scrolling through tasks: Possibly display the tooltip next to the task with a readable presentation of all changes. This would be very similar to email notifications which usually provide a short description of the task and all changed properties. Also a keyboard shortcut for marking a task as read should be added. This would allow quick scanning of changed tasks similar to an email reader without having to open an editor for each changed task (which is slow compared to browsing the task list). If all that is implemented I will consider to stop using Bugzilla notifications :).
(In reply to comment #12) > * Allow quick scrolling through tasks: Possibly display the tooltip next to the > task with a readable presentation of all changes. Don't we already have it? Well, right now it only show last comment, but it does show all the changed attributes. Though we still need to fix that for the new tasks and show submitter, description and few other common attributes, like component...
On Linux the tooltip is only displayed when the mouse hovers over the task list item. I would like to browse through the changed tasks by keyboard.
(In reply to comment #14) > On Linux the tooltip is only displayed when the mouse hovers over the task list > item. I would like to browse through the changed tasks by keyboard. Good point. I've been missing something like F2 (similar to one in Java editor).
+1 for all suggestions comment#12 and below.
*** Bug 198491 has been marked as a duplicate of this bug. ***
I saw some commits for this feature, but when trying to switch to this presentation I get this exception: java.lang.NullPointerException at org.eclipse.mylyn.internal.sandbox.ui.IncomingTaskListContentProvider.getElements(IncomingTaskListContentProvider.java:38) at org.eclipse.jface.viewers.StructuredViewer.getRawChildren(StructuredViewer.java:937) at org.eclipse.jface.viewers.ColumnViewer.getRawChildren(ColumnViewer.java:660) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1295) at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:366) at org.eclipse.jface.viewers.AbstractTreeViewer.getFilteredChildren(AbstractTreeViewer.java:615) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:581) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2497) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1826) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:692) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1801) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1757) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1743) at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1433) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1368) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:378) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1431) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:503) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.refresh(FilteredTree.java:818) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1390) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.refresh(FilteredTree.java:808) at org.eclipse.jface.viewers.ContentViewer.setContentProvider(ContentViewer.java:229) at org.eclipse.jface.viewers.StructuredViewer.setContentProvider(StructuredViewer.java:1583) at org.eclipse.jface.viewers.AbstractTreeViewer.setContentProvider(AbstractTreeViewer.java:2241) at org.eclipse.jface.viewers.TreeViewer.setContentProvider(TreeViewer.java:916) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.setContentProvider(FilteredTree.java:854) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView.applyPresentation(TaskListView.java:894) at org.eclipse.mylyn.internal.tasks.ui.actions.PresentationDropDownSelectionAction$PresentationSelectionAction.run(PresentationDropDownSelectionAction.java:115) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169) at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
BTW, what was the intention behind the following code? if (task.getSynchronizationState().equals(RepositoryTaskSyncState.INCOMING) && task.getOwner().contains("@")) { people.add(new Person(task.getOwner())); } the owner string is always representing a person, regardless if it has @ or not.
Try it out again.
Why does this presentation shows "persons" as root containers? Anyways, it still doesn't work. java.lang.NullPointerException at org.eclipse.mylyn.internal.tasks.ui.views.TaskElementLabelProvider.getImageDescriptor(TaskElementLabelProvider.java:126) at org.eclipse.mylyn.internal.tasks.ui.views.TaskElementLabelProvider.getImage(TaskElementLabelProvider.java:74) at org.eclipse.jface.viewers.DecoratingLabelProvider.getImage(DecoratingLabelProvider.java:85) at org.eclipse.mylyn.internal.tasks.ui.views.TaskTableLabelProvider.getColumnImage(TaskTableLabelProvider.java:68) at org.eclipse.jface.viewers.TableColumnViewerLabelProvider.update(TableColumnViewerLabelProvider.java:71) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:135) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:911) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:97) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) ...
I'm not seeing this but this trace would indicate a null TaskRepositoryManager.
Rob: I fixed the NPE. The current per-person organization isn't working well for me, so we should consider others (e.g. per repository, but that could have too much overlap with recommended working set usage). Let's proceed with additional experimentation after 2.1.
Created attachment 78861 [details] mylyn/context/zip
Out of curiosity, what is the use case for grouping incomings by owner? +1 for per-repository grouping, or better repo + project grouping. btw, IF we had grouping as a first class feature for the task list (like my first implementation before Mik insisted on using presentations) this incoming presentation could have been simply flat and user could choose the grouping that works the best.
UI wise this is similar to what I would suggest for replacing the presentation of changes in the task list tooltip: http://bp0.blogger.com/_2017w9FY4Do/RvLF35HR3qI/AAAAAAAAALk/8ihv6Hx0sK8/s1600-h/pde-pluginspy.png
(In reply to comment #26) > UI wise this is similar to what I would suggest for replacing the presentation > of changes in the task list tooltip: > http://bp0.blogger.com/_2017w9FY4Do/RvLF35HR3qI/AAAAAAAAALk/8ihv6Hx0sK8/s1600-h/pde-pluginspy.png Steffen, can you please elaborate how this is related to the presentation?
I meant the link as a follow-up to comments 12-14. I'll open a new bug report to discuss the UI for displaying incoming changes.
(In reply to comment #28) > I'll open a new bug report to discuss the UI for displaying incoming changes. btw, there are few bugs about tooltips already
Created attachment 81020 [details] issues with current implementation What is the plan in regards to this presentation? It feels really confusing that issues are grouped by assignee, wich in some cases look really weird (see screenshot). I think it would make more sense to group by repository + project, but we may need api from bug 199818 and some support in repository connectors that have concept of project. Also, if this presentation is active and you mark issue as read, read issue is not filtered out from the list.
This isn't currently a priority for 2.2. Agreed about the problems, not sure I agree with the proposed solutions. I think that we should resurrect this once we have iterated figured out changes related to bug 206566 and sorting of incomings in the current presentations.
This presentation is available in the Sandbox. We don't currently have enough indication that it is working well enough to promote out of the Sandbox. If anyone is using it and has thoughts about improving it's usability or utility please post here. As a meta-point, I think that we have "room" in the UI for three default presentations, and I think it would be useful for them to show up on the toolbar and be toggled via single-click (similar to the iTunes UI for presentations). In the 3.x timeframe I think that we should figure out if there is a useful third presentation, and "Incoming" still appears to be the top candidate.
*** Bug 238109 has been marked as a duplicate of this bug. ***
*** Bug 268100 has been marked as a duplicate of this bug. ***
*** Bug 206098 has been marked as a duplicate of this bug. ***
*** Bug 170606 has been marked as a duplicate of this bug. ***
Related to bug#177208
I would like us to consider this again for Eclipse 3.6.
Moving off plan, this will need to wait post Indigo due to the scope of changes needed to the Task List here. In the meantime, for those wanting to try it, we have the incoming presentation available in the sandbox.
Toaster popups are nice because they often give you enough info to mark a task as read and you can see a few tasks at once. It would be nice to have a similar view that shows a larger number of incomings with details about what changed and with a mark all read button. Maybe it could even do some kind of automatic grouping, e.g. all tasks that were marked completed, all tasks where the subtasks changed, all tasks with new comments, and have a mark as read button for each group.
Closing as part of backlog cleanup. Please reopen if you are working on this.
