Community
Participate
Working Groups
I would like to organize my query tasks within a set of nested categories. For example: Milestone Items >>M1 >>>>Platform Items >>>>JDT Items >>M2
Can't you just create several queries?
There are several queries but I like to have a cleaner top level organization to the task list.
There is a discussion related to subtasks (which will probably bare on sub categories) on bug#137543.
Another use case is to make categories map to roles, e.g. "My tasks", "Products I'm watching", "People I'm watching". This would enable you to work by "going into" the "My tasks" category when working, and then go up to the root when you want to catch up. The problem right now is that it can be easy for the task list to get overloaded with incoming messages. But we have to tread carefully here because there is an overlap with organizing this information via subtasks (a la Microsoft Project) vs. organizing it with nested categories. One way to think about the split is that the subtask attributes comes from the repository (e.g. via milestones, or bug dependendcies as is a convention for Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=330700). The query set up and categorization structure is your own personal view, and you might want the ability nest queries in categories. I'm marking this to be looked at for 0.7 since we need to figure out our task/category hierarchy story in time for 1.0.
We discussed the need for this feature on a recent conference call, and came up with a potential solution that integrates nicely with Eclipse without complicating the UI with arbitrary nesting of categories: allowing the top level elements in the Task List to be working sets. This is going to have to wait post 1.0, and we need to keep subtasks (bug 137543) in mind when designing this UI. Marking P2 to raise the priority for this in post-1.0 planning.
*** Bug 165109 has been marked as a duplicate of this bug. ***
*** Bug 163480 has been marked as a duplicate of this bug. ***
*** Bug 180250 has been marked as a duplicate of this bug. ***
It is also possible to create a "dynamic" working sets that could use scheduling rules to show or hide certain elements in the Task List. For example, let's say Mik have a "home" query (he actually does), so he may not want to see changes in that query (even if it has tasks scheduled for today) while he is working on some other things. So, he can specify a working set and set time intervals when those tasks will be visible (i.e. early morning, lunch time and at the end of the day)... PS: I tweaked summary a little to make it easier to find.
Eugene: I'm restoring the summary first because its better to have the summary be the problem or use case description and not the implementation mechanism, in case we decide to use a different implementation mechanism as a result of discussion on the bug. Added a note to: http://wiki.eclipse.org/index.php/Mylar_Contributor_Reference#Bugzilla Your summary title wasn't bad in this case, but this way it shows up in queries for both nesting and working sets, and there is a chance that the working set mechanism will be overload for this (although I hope we can simply reuse it).
The use case you marked as duplicate had nothing to do with this one except that working sets maybe used to resolve this one (or maybe not). So, using your own logic you not supposed to mark my issue as a duplicate of this one. My use case is to be able to filter out parts of the task list I don't want to see, so summary is totally confusing. So, "go into" is not really enough. for example I may want to filter one or two queries (i.e. tasks I work on the weekend), but keep the rest of the task list visible. Also note that "working set" keyword is way to far from the beginning of summary and it cut off in the narrow task list and you don't even see it when scanning trough filtering results. So, I mainly swapped first and second part of the summary...
Just a thought regarding working sets, perhaps we could do a first iteration where working sets simply consist of the available task repositories. For example, only tasks from selected repository revealed in task list presentations? I realize this doesn't cover all use cases but may work well for a number of people.
It doesn't look right at all. Many repositories have multiple projects, so you won't be able to filter out by project. All in all it seem more natural to use group artifacts (queries and categories) from the task list for inclusion into the working sets.
(In reply to comment #13) > All in all it seem more natural to use group artifacts (queries and categories) > from the task list for inclusion into the working sets. Eugene: could you please elaborate on this?
All I am saying is Task List working sets should be using query/category as base artifact.
(In reply to comment #15) > All I am saying is Task List working sets should be using query/category as base > artifact. Yes, and perhaps the scheduled mode should just be a working set consisting of time based queries.
(In reply to comment #16) > Yes, and perhaps the scheduled mode should just be a working set consisting of > time based queries. I am not sure what you meant by that. :-)
(In reply to comment #17) > I am not sure what you meant by that. :-) I'm suggesting that perhaps task list presentations should be enveloped by working sets. Although this may not be ideal as it doesn't give the same control over the underlying content provider. but thinking in terms of reducing 'concepts' this may be the way to go. Thoughts?
Just curious, does anyone on this bug use the Window Working sets? To figure out whether that would work the for the Task List I've been trying, but find them too hard to use because I can't get my working set list down to below 5 and find it cumbersome to be repeatedly togging them on/off all the time. I tried, but have gone back to just making Working Sets the top-level elements in the Project and Package Explorer.
Same here. The associated overhead for managing window working sets seems disproportionate for filtering in the task list.
I used window working sets to narrow down results of search, open type dialog and synchronize view. Though Sync view takes a static snapshot of what window working set was at the creation of the sync. Anyways, said that, I don't think we need working sets at the toot of the Task List view. There aren't that many queries (comparing to the number of projects) to waste screen space. I think it is sufficient to have something similar to Problems view, which allows to select working set that will be used for filtering problems or something like Search Java references in working set. PS: btw, do you know that you can use Ctrl-click to switch from one working set to another? Without Ctrl clicked working set will be added or removed to the window working set.
I work on very large code bases and I find that working sets nicely break up the behemoth for faster searching, navigating, refreshing, etc. I wholly believe that Mylar effectively replaces working sets at a conceptual level, but I still end up using working sets because Eclipse apparently doesn't perform well for me otherwise.
(In reply to comment #22) Joseph, we are talking about new kind of working sets, that will contain queries and categories from the Task List. They quite orthogonal to resource working sets. The idea is basically completely hide unchosen task working sets so, they won't clutter task list with incoming notifications, and popup notifications.
It doesn't seem like this issue have any progress. So, I can try to take a crack on implementing an UI for editing and managing task working sets. It will add a "configure working sets" action to the Task List view menu, which would show a dialog (similar to the one you can call from the Package Explorer or new working set wizard) listing all task working sets and allow to edit them, by selecting groups/queries available from the Task List. Once we'll have those working sets it should be not too hard to hook them with the Task list.
Great to hear that you want to help out with this Eugene so I'd like us to quickly settle on one mechanism and then experiment with that. The main question I have is whether we should have custom task working sets, or try to piggy-back on resource working sets (e.g. you select the "Mylar" resource working set and then only see the corresponding queries). You are suggesting the former and I think that sounds right, because I think that the UI for switching working sets in the toolbar won't work well for the Task List. For example, I think it is more common not to switch working sets, just to group the navigator views by them. This mode of working should not preclude using Task List working sets. So are you going to make the Task List working sets contain an ITaskListElement? I think the common case will be adding AbstractTaskContainer to them. We will need a good UI for quickly switching between working sets and potentially for showing when an unselected working set has an incoming. I've been brainstorming that with Rob and a good spot for it might be the current active task hyperlink area to the right of the Find menu. But a first version of this this would probably be usable with a working set drop-down on the Task List toolbar.
(In reply to comment #25) > The main question I have is whether we should have custom task working sets, > or try to piggy-back on resource working sets (e.g. you select the "Mylar" resource > working set and then only see the corresponding queries). You are suggesting > the former and I think that sounds right, because I think that the UI for > switching working sets in the toolbar won't work well for the Task List. We can experiment with resource working sets later. I am not too concerned about toolbar at the moment. > So are you going to make the Task List working sets contain an ITaskListElement? > I think the common case will be adding AbstractTaskContainer to them. Sure. Though we may restrict it to AbstractTaskContainer. > We will need a good UI for quickly switching between working sets and > potentially for showing when an unselected working set has an incoming. I don't think that would make sense. The main point is to take anything not from the active working set completely off the list. > I've been brainstorming that with Rob and a good spot for it might be the current > active task hyperlink area to the right of the Find menu. But a first version > of this this would probably be usable with a working set drop-down on the Task > List toolbar. No need for that. View menu in the Task List should be good enough and more accessible then toolbar. See how it works in the Package Explorer (will need to show projects at the root).
I updated the description to reflect that we are gravitating to making the integration be filter-based and not nesting-based, in order to avoid putting overly deep nesting in the Task List. (In reply to comment #26) > I don't think that would make sense. The main point is to take anything not from > the active working set completely off the list. I think we need this for the same reason that mutliple inboxes need to show how many unread messages they contain--it's a trigger to switch working sets (e.g. to check if a critical bug got assigned to you). But it's pure UI and we can add it later. > No need for that. View menu in the Task List should be good enough and more > accessible then toolbar. See how it works in the Package Explorer (will need to > show projects at the root). I want this UI to have two-click switching of working sets. The feedback I keep hearing on the Package Explorer working set stuff is that it is very hard to use and that only advanced users use it. This can be in the view menu to start (making it 3 clicks), but I think that the interaction should be as simple as this: Click button/menu, following popup menu shows, allowing you to click a checkbox for each visible working set, and to quickly click "Select All" (e.g. when planning the workday). [Select All] ------------ v [Mylar] [Subclipse] [Personal] ------------ [Configure...] Is that similar to what you have in mind?
(In reply to comment #27) > I want this UI to have two-click switching of working sets. The feedback I keep > hearing on the Package Explorer working set stuff is that it is very hard to use > and that only advanced users use it. This can be in the view menu to start > (making it 3 clicks), With view menu it takes exactly 2 clicks (after you used working set once) > but I think that the interaction should be as simple as this: ... > Is that similar to what you have in mind? Not even close. I think dialog like in Package Explorer is more usable then messing with submenus and checkboxes. The advantage of the dialog is that you can select and edit selected working sets from the same place. And we should not be inventing something custom if the rest of the platform using this UI, which comes down to the common new working set wizards... Anyways, I am suggesting to implement simplest possible and familiar thing that would work, instead of toying for several weeks with the UI.
(In reply to comment #28) ... > With view menu it takes exactly 2 clicks (after you used working set once) ... > Not even close. I think dialog like in Package Explorer is more usable then > messing with submenus and checkboxes. The advantage of the dialog is that you > can select and edit selected working sets from the same place. And we should not > be inventing something custom if the rest of the platform using this UI, which > comes down to the common new working set wizards... I'm not sure I follow how this will make it quick to switch working sets. I know that as a user it won't work for me if the only way I have of switching working sets is by going into a dialog as I currently have to do with the Package Explorer. Platform UI attempted to improve on that UI by providing the main toolbar based way of switching working sets, which is almost identical to what I am proposing. > Anyways, I am suggesting to implement simplest possible and familiar thing that > would work, instead of toying for several weeks with the UI. Sounds good to me. But let's make sure that we're on the same page on what the "simplest thing" is, because parts of Eclipse's working set support are far from simple.
(In reply to comment #29) > I'm not sure I follow how this will make it quick to switch working sets. I > know that as a user it won't work for me if the only way I have of switching > working sets is by going into a dialog as I currently have to do with the > Package Explorer. That is NOT true. Once you set working set it does appear in the view menu. So, next time you just select it from there, or use window working set and select it from the toolbar. > Platform UI attempted to improve on that UI by providing the > main toolbar based way of switching working sets, which is almost identical to > what I am proposing. An I am suggesting not reinvent it again and use what platform ui provided. Fancy stuff can be added later when someone will have time to play with that. > Sounds good to me. But let's make sure that we're on the same page on what the > "simplest thing" is, because parts of Eclipse's working set support are far from > simple. They may not very obvious, but they are simple.
Created attachment 65721 [details] a quick prototype of the task working set Here is a quick and dirty prototype for working set support for the task list. It doesn't introduce any new UI besides one provided by the platform (basically supports window working set), but I think it does cover my use case pretty well. So, it does allow to quickly filter queries/categories from the task list. Another limitation is that state is not restored, because I couldn't figure out how to retrieve window working sets. Anyways, it is something to start with.
Created attachment 65722 [details] mylar/context/zip
I'm on the fence. At a conceptual level it does seem like what Mylar does is orthogonal to the resource working sets. I guess my only concern, if they are going to be made into separate entities, is what happens when someone tries to resume a context which references files that aren't in one of the active resource working sets? Obviously it'll fail, but how gracefully, and how will the user know which sets he/she may have to make active in order to open the context. Maybe this orthogonal concept can umbrella the resource working sets? In other words, if a "Mylar working set" were to remember the list of resource working sets that were active just before the context was closed, then it could inform the user as to which have to be active in order for this context to work properly. Clearly this isn't a perfect solution (since working sets can be removed), but it's something that I thought might be a potential usability issue.
Joseph, this issue if about filtering content of the Task List view and not related to the active task. Please create separate issue for restoring/saving resource working sets used for other Eclipse views on task activation.
Joseph: I think that it is premature to be creating a new bug for working set behavior since we are still figuring out the design of this and since your points offer some good discussion to some of the questions I raised above. So please feel free to keep discussing here and once we have settled a clear design we can break things out on separate bug reports. Eugene: I am experimenting with the patch and think it's a good start! One thing I'm having trouble with is quickly de-selecting all the working sets to see my whole Task List. But that's probably UI that we could add to the Task List view. I don't think we should commit to having this in 2.0M3 yet, but I'm going to commit it to HEAD so that I can start using it to get a better idea of the UI issues. If it's not stable or clear enough we can move the extension point to the sandbox and put it back after the release.
(In reply to comment #35) > One thing I'm having trouble with is quickly de-selecting all the working sets to > see my whole Task List. Right, that isn't an one clicker action. Note that for toolbar UI, when you click on the working set in the drop down it add/remove selected working set; but if you ctrl-click it will switch to it, removing all other selected working sets. > I don't think we should commit to having this in 2.0M3 yet, but I'm > going to commit it to HEAD so that I can start using it to get a better idea of > the UI issues. If it's not stable or clear enough we can move the extension > point to the sandbox and put it back after the release. That is great! There is some stuff like icons and label provides that needed to be reused from task list. I didn't want to take this stuff away from you, so you could have chance to play with the UI. :-)
Let me now if you can provide another patch that does the right things for add/remove, currently have XXX comments, so that I can focus on the UI stuff? Also: note that I added @author tags for you, please remember to add those when creating new types.
Created attachment 65986 [details] handle removing deleted elements from the working set Here you are TODO implement memento stuff to actually persist working set configuration
Great, patch applied. Also added icons and label provider. If you can do the memento persistence soon I think I should have enough time to get this into 2.0M3!
Created attachment 65991 [details] memento support Uff. It took me quite some time to realize that TaskList.getQueryForHandle() actually return a query for the give task handle and not query handle... I also had to add adapter factory for adapting AbstractTaskContainer to IPersistableElement, otherwise tasks.core would require dependency on workbench plugins.
Created attachment 65992 [details] mylar/context/zip
Patch applied yesterday, have been working on it bootstrapped and the mechanism is looking good! Added alphabetical sorting to TaskWorkingSetpage and improved refresh on working set switch. I'm finding myself using the Ctrl+click all the time, how about you? I'm wondering if for our own working set selector we should make that behavior be the default since it is not very discoverable.
(In reply to comment #42) > Patch applied yesterday, have been working on it bootstrapped and the mechanism > is looking good! Glad you like it. :-) > I'm finding myself using the Ctrl+click all the time, how about you? Me too. I also created working set for all tasks, so Ctrl-Click can be also used to remove the working set.
(In reply to comment #43) > Glad you like it. :-) Yup, the only protests I had were against the dialog-based switcher UI that the Package Explorer uses, which we have so far managed to stay away from.
Eugene got all the core stuff we need working, so closing. I created bug 186493 for the custom UI discussed here.
Mik, there is a small issue. Even so window working set is restored at the startup, Task List isn't being filtered according that restored working set on startup.
The same problem can be seen when Task List model is changed (Categorized to Scheduled and back)
Eugene: will you be providing a patch for that or do you want me to investigate? This should be fixed for 2.0M3.
(In reply to comment #48) > Eugene: will you be providing a patch for that or do you want me to > investigate? This should be fixed for 2.0M3. I won't be able to look at this this before late evening. If it can't wait, please investigate it yourself.
(In reply to comment #49) > I won't be able to look at this this before late evening. If it can't wait, > please investigate it yourself. I could not add this to my plate for 2.0M3. The work-around for comment#46 is to manually re-filter. Please file a new bug for that. The core work here is done so marking resolved.
