Community
Participate
Working Groups
Build ID: M20060921-0945 Mylar 1.0.1 I have "Toggle focused mode" and "manage open editors" preferences turned on, because they are very useful when switching between multiple tasks that are already in progress. But when I activate a newly created Mylar task, the way these options work right now feels pretty counterproductive, because they leave me with a blank package explorer and a blank editor section. So to begin working, I either have to know the class I want to open through the Open Type dialog, or switch off the focused mode on the package explorer, navigate to the package I want, start working, and then after I have built up sufficient context turn the focused mode on again. This is one of the rare examples when I really feel like Mylar gets in my way. Are there any plans to get this initial UI to be a little more useful instead of a blank slate? For example, I have over 60 projects in my workspace, some 40 of which are required to be open in order for everything to compile properly. But every one of my dozen tasks recently has been in the same 3-4 projects, and I have a feeling this is not such an uncommon situation. Could the focused UI when I activate a new task at least show the union of projects (or maybe packages) that were part of the context of the last several tasks? This way Mylar would actually help to quickly and easily navigate to where chances are the new task is going to take place too, and to build the context from there.
I have a suggestion. After activating task without context switch to the Package Explorer (or Project Explorer) view and show root working sets or projects unfiltered (like they been opened with Alt).
Tentatively scheduling this for 2.0, because we need to improve this experience as you indicate.
In Mylyn 2.0 there we have made a small improvement to make this easier. When a task with no context is activated we do not close any editors that are already open, so selecting those will have the effect of populating the context. This still does not address the core issue. But the good news is that for 2.0 we have just added the notion of task working sets, and in 3.0 I think that it would be worth exploring maintaining a global context for each of those working sets and using that as a way to prime a context for a new task. The only current work around is to copy a context from an existing task.
(In reply to comment #0) > This is one of the rare examples when I really feel like Mylar gets in my way. +1. For this reason, I turned off those settings.
Willian: consider trying them again at some point and using "Context -> Copy" in order to grab the context from an existing task, or just start getting going by Alt+clicking into the Package Explorer. Those are the current approaches that others use and it would be useful to know what does and does not work about them for you in order to further inform how we resolve this.
Mik, Alt-clicking on blank package explorer does not work if working sets used as the root nodes in package explorer. My experience working sets are quite useful for grouping modules per project (i.e. Mylyn is a project, but each plugin is just a module in that project, even so Workbench calls them projects). Also, there is a few projects that are using fully qualified module names and without working sets they all get mixed up in the package explorer. To give you more specific example, one of the typical configurations in my daily work look like this: terracotta working sets (~50 modules), ASM working set (2 modules), spring or wicket or other xyz framework (from 10 to 30 modules), none of those actually using qualified project names, so sorting is very important.
(In reply to comment #5) > Willian: consider trying them again at some point and using "Context -> Copy" in > order to grab the context from an existing task, or just start getting going by > Alt+clicking into the Package Explorer. The problem with the "copy" approach is that I don't feel comfortable having to "think" about some other similar task I have worked and having to copy the context. It is too much manual work. (In reply to comment #6) > My experience working sets are quite useful for grouping modules per project +1. I have many different projects in my workspace, and I always use working sets to organize them to avoid having to setup different workspaces.
*** Bug 157933 has been marked as a duplicate of this bug. ***
Created attachment 104923 [details] overlay for empty views
We now provide an instructional overlay if the tree viewer is empty, indicating that the user should unfocus or use Alt+click. Let's consider further improvements for 3.1.
check
We out of time for 3.2, moving to the back log.
Shawn: I think that you are very close to having this one licked.
We made some good progress towards this as part of bug 337266 and gathered input that we should consider for the next cycle. I would like to keep this bug open as a theme bug for a while longer until we have had more feedback.
Reposting my comments from bug 337266: (In reply to comment #5) > I always thought the right thing to do here would be to auto focus once there > are a certain number of elements in the context. (In reply to comment #6) > A perhaps even better but much harder thing to do would be to have the views > show as focussed as soon as a task is activated (i.e. the button appears > depressed), but start out in a special mode where initially everything is > visible, and then the set of visible things shrinks gradually until it is just > your context. I'm imagining a workflow roughly like this: > > # I activate a task, everything is visible > # I click a few things, and Mylyn shows me my context plus a set of say 25 > projects that are most closely related to those things (based on previously > active task contexts, wheighted by how recently they were active) > # After some more interaction, the set of relelated projects is reduced to say > 10, and maybe the most interesting elements within those projects become visible > (again based on past tasks) > # Finally, once my context is big enough, Mylyn drops into its usual mode and > just shows me the context (In reply to comment #7) > The current solution, and my suggestion to autofocus when the context reaches a > certain size, have the problem that there is no longer the "empty context" > message displayed in the pacakge explorer, so users might have an even harder > time understanding what happened. Perhaps there should be a "Where did my files > go?" hyperlink displayed when a task is first focussed that would open an > explanation. Or else we could add a tooltip to the package explorer explaining > that it is now in focussed mode.
Shawn: What's left here?
Unless we want to add a threshold to auto-focus after some number of interactions, I think that we are done here. Feel free to resolve if you agree.
One thing I would like to see fixed is that the first time I focus a task, the package explorer is never correctly expanded until I click on something in it.
We still have only very limited support for gradually introducing focusing to Mylyn users. This bug captures a number of useful suggestions that we should consider for future releases. We can create new bugs as we implement them but I would prefer to keep this bug open as an anchor for discussion.
That sounds right Steffen. Sam, as for the bug that you are seeing, can you file a bug so that we make sure that we track this issue?
Created 345005: When first focusing a task, the package explorer is not correctly expanded https://bugs.eclipse.org/bugs/show_bug.cgi?id=345005
Here's a simple suggestion for Bugzilla: when activating a task with an empty (or very small) context, initially seed the context with items from recent tasks that have the same product and component.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
