Community
Participate
Working Groups
Comments from Randy Hudson (to platform-dev-ui mailing list): I would prefer to see a single TaskView that is more efficient than the current version. I'm sometimes sorting through 2000 problems. Splitting that in half doesn't really solve the problem. Maybe the two new views already do this, but if not, why not first experiment with tabletrees, filters, modes (like "problems" and "tasks"), and other approaches to improving the management issue. As a user, I would prefer one view that works well. This change goes against the "Reduce Workbench Clutter" line item. It is also going to confuse users who already know how things work.
Comments from Bob Foster (to platform-dev-ui mailing list): I'm not so sure. When I filter out all warnings, in the absence of errors I'm just left with 100's of TODOs. I would prefer to have those in a separate view rather than filter them out. Perhaps the filters could be improved, in addition. Changing the subject, I see XML Errors and XML Schema Errors in the filter list. How are markers flagged as these types? Do they correspond to anything in Eclipse today? Please don't tell me they are hard-wired to PDE markers. ;-}
Created attachment 4935 [details] Sample single task view Comments from Randy Hudson (to platform-dev-ui mailing list): That's a good point. But, you can create the equivalent of two views with the single existing view. Why not introduce a "Task Set" that could be similar to working sets elsewhere. This builds on what the user already knows, meaning both the Tasks View, and use of "sets". And it scales to more than 2.
From Kevin McGuire (to the platform-dev-ui mailing list): From Randy's comment, >>I'm sometimes sorting through 2000 problems. I was going to say that maybe he should try writing better code :) But actually this denotes a problem in the way the, err, problems are being presented. I think we can agree that the current filtering mechanism doesn't help. Often when there are tons of errors there are actually a few key ones that generate the rest. For example, a missed import in java can make a real mess. In this case, a better presentation might be to just list the resources which have problems, then expand to see the actual errors. I am guessing this is what Randy had in mind when he mentioned tabletrees? Better still would be more structure to the error markers with plugins making use of this. Presently in the case of the missing import, you first get an error on a missing class, an instance of which say is assigned to a variable, then you get an error for each use of that variable. A good programmer always looks for the first one, knows the others are just chaff and tries to ignore them. Better reporting would do just that: have the first error as the parent/cause and subsequent ones as children/effects which could be dealt with differently in the UI (e.g hidden, de-emphasized visually through use of a different icon, etc.). Another approach might be the ability to group the errors by type (e.g. unresolved reference). Just some random ideas. Our experiments (on VCM) with 'helpful' generated tasks were disappointing because for the most part they were ignored or never seen. We assume this is because there was so much clutter in the task view that people didn't find our helpful ones there. So perhaps a second view would solve this, but I really don't know because I haven't been given any information which explains why we chose these particular changes (if I've just missed that email then apologies). I take it that the current changes are just random experiments, and if so then that's fine, but people need to know the context/motivation for what they are evaluating (is it an experiment? a prototype? what problems is it attempting to solve? what's the 'vision'?). What I'd like to see is a systematic analysis of the ways in which the task list fails, with an explanation of why a given set of proposed changes would fix it. Such an analysis, ideally backed by UCD usability session data, is *critical* for hitting the mark with a new task list. Without it I don't think you can expect buy-in from the community (and without it there'll just be swirl).
closing as invalid. these comments suggest an analysis of task view usability regarding use of trees, treetables perhaps, or other mechanisms. i don't oppose that idea, and this change is not meant to close the door on any usability issues people have with these views. (whatever they may be) i disagree with the idea that adding this view goes against reducing workbench clutter. one could just as easily say it reduces it by removing the tasks (and associated columns) when one is working with problems, for example. as i mentioned on the mailing list, this change garnered us significantly cleaner code. because of this, the opportunity for the community to provide different views have increased, hopefully precisely defining the usability issues in the process. kevin's comments are fine, but a little out of place for what we were trying to accomplish here.
Sorry, but the addition of a view creates clutter. Similarly, providing reusable code is begging Eclipse clients to produce even more clutter. Have you considered the existing user base? What is going to happen when thousands of 2.1 users open the Tasks View in 3.0 looking for their todo markers? I'm happy that your code is clean, but you need to consider usability (for a 2.1 user) and scalability/clutter.
Could you also add a marker View called "Auditing". I want a view that displays only markers generated by a code auditor like Checkstyle. For example, markers for methods that are missing JavaDoc, or missing a @param or @return tag.
What would go in the auditing view, if no code auditor were present? If you want a separate Audit view, why not approach the Checkstyle folks and have them add one. That is what we did with our code auditor in CodePro... http://www.instantiations.com/codepro/ws/docs/features/audit/
this bug is closed. please open a new enhancement request to track any 'code auditor' ideas.
Eric, I've used you're product and appreciate the auditing portion. But, in my opinion, I would prefer to see Instantiations provide an Audit "Task Set" extension instead of an Audit View, which clutters the perspective. See the attachment to this bugzilla. In the drop-down Combo, you could provide a "CodePro Audits" choice, which would reuse the existing Tasks View area. If the TasksView becomes a TableTree, it will look very similar to the view you have created. Another option is that the "Task Set" extension point allows the client to provide his own IPage, instead of using the default Table. Then you could completely rehost your "Audits" view inside the Tasks View.
Regarding comment #6: I second this. We (the zclipse team) decided to write a plugin against the current Tasks view instead of a custom view, in order that our tasks be included in the consolidated list. This in spite of the Task view's minimal API. I use a laptop with 1024x resolution and do not favor an additional "fundamental" view taking up precious screen real estate. I hope this issue has not been completely closed.
Was this bug marked INVALID meaning that the workbench has already gone back to one view? The comments indicate that the two view approach is being kept, in which case the resolution should be WONTFIX.
My comment referencing comment #6 was actually in recognition of (I hope) its tongue-in-cheek nature. I don't favor a proliferation of custom views (hopefully that was clear from my earlier comment). The eclipse team should seriously consider Randy Hudson's solution of TaskSets within a single Tasks view before making the two (or more) tasks, problems, audits, etc.
I'd just like to mention that I started up eclipse 3.0 RC1 on a mac (to try out the new speedy gtk fixes) and was surprised to find that I couldn't see the problems in the code base, yet the tasks view was visible. I immediately realized what was going on and found the problems view. Granted, this is more of a UI/upgrade problem, but I would really prefer a unified tasks view that has tools to sort and view tasks. I can't see any point to showing both the tasks and the problems views in the same perspective and I can see a reason why I'd want the two views should have all their data visible, so why should they be separate? mike
CC: Platform UI-Dev mailing list I was a bit slow in checking out Eclipse 3.0M1, but now that I finally have I have to side with Randy on this one. I understand the rationale, but I think the solution is worse than the problem. Pre 3.0 the tasks view was certainly "overloaded" -- it was (is) difficult to show exaclty what you want to see. You could choose to see only errors, you could set the filters for working sets, etc, all of which is better than nothing. However, none of those solutions provided "random access" to what you wanted to see when you wanted to see it. Twiddling the filters every time you wanted to see slightly different sets of tasks is a bit of pain. Enter the split view. As I mentioned, I understand the rationale. Many people want to see tasks & problems at different times and in different contexts. For example, someone may want only problems visible when developing the initial versions of component. Don't bug me about every pedantic warning, they think. Or perhaps they think "I just added those TODO tags, I know they're there, but I am not dealing with it now". All of this makes perfect sense. But also consider that the same person may, at a later time, decide they want to see ALL markers associated with a file. What do I do now if I want to browse code and see all the associated tasks, warnings, checkstyle checks, etc? Consider for a moment someone doing a code review -- they would certainly want to browse source files and see all associated issues (tasks, audit/style warnings, problems) with that file. Currently their only option is to make both views visible, eating up screen real estate and forcing them to constantly try to take assimilate information from multiple visual sources. This stinks, IMHO. Also consider: Consistency of Information Presentation in the UI : Currently, if I browse a file with one or the other view open (tasks or problems), the information I see in the editor margin no longer corresponds to the (default) information I see in the task/problems list. I will see additional markers in the file, but those markers will not appear in the task list. Previously, for this to happen I had to explicitly "request" it. This is probably not a big deal to people on this list, but it could definitely be confusing to some Eclipse 2.X users, comfortable with their TODOs and style warnings, when they switch to 3.0 next year. Classification Confusion: What is a task and what is a problem? Currently, task is the only well defined marker. Problems range from style warnings to compiler errors. Surely someone would make the case that to them "problems" are only those things I define as causing an "Error" in the compiler preferences, everything else is just "FYI". Who is right? I think you'll have quite a few unhappy people if there is no way for them to view tasks and markers the way THEY want to. Deciding for the user, especially in a way radically different from previous experience, is garaunteed to cause outcry. Fixing the Problem: I think Randy's mockup shows how everyone could be happy without multiple views. Out of the box, provide 3-5 default filters (Tasks Only, Problems Only, All, etc). Allow the user to define new named filters (and/or modify the default filters), and let them switch between them. -Andrew
reopening for further investigation
To add my two cents, I have to agree with Randy on this one. I've been using the split views for a couple of months, but it doesn't make it any easier to find what I'm looking for (plus the wasted vertical space from having to stack the two view). The table tree might work for some people, but in my opinion you can easily construct a task table tree by putting the navigator view and the task view side by side, and configuring the task view to show markers on the selected element only. The "marker sets" idea with the drop down for changing it sounds promising though.
"and configuring the task view to show markers on the selected element only" See bug 43095. Currently changing the filtering mode isn't remembered for new workbench windows. The workaround is to shutdown Eclipse with a single window open, which saves your current filter setting. After restarting, Task Views in new windows should end up with the filter mode at last shutdown.
"plus the wasted vertical space from having to stack the two view" That issue has been addressed in the new L&F by always wasting vertical space. But seriously, what is the status of this bugzilla? I have been using the split views for 5 months at least. And what I have found is that as a user, I simply don't use the Tasks View. So I don't see Tasks anymore. So although I have 47 $ToDos in comments, they just sit there and don't get "ToDone".
Randy, I agree. You have to switch to the Task View manually. I found myself not switching very often to check the tasks that are there. Problems are nothing else than tasks that has to be fixed. There should be only one view.
Please set a target for this bugzilla. This is not something which should slip through the cracks because it will be hard to retract this view once it goes out in a release.
After working a while with both views I conclude to a knockdown result. The UI is NOT as responsible as with working with one view. Why? I'm dumped all the time with dialogs forcing me to wait because of ongoing operations. Everytime I'm looking for "ongoing" operations I see the Tasks view refreshing its content AND the Problems view refreshing its content. The operation indicator is never silent and always perfoming some refreshing for TWO seperate views which can be reduced to ONE operation for ONE view. I don't understand why something has to be done in two steps if it could be done in one step inside a single view.
Created attachment 8972 [details] Waiting for the task+problems view As you can see, I always have to wait for two operations where one is suitable. It would save me a lot of time when the operations are merged into one and the split is removed. I have a rather old machine (800Mhz AMD) to work with and thus I have to reduce the number of concurrent jobs.
ping
Just to give you an update, I opened bug 59006 for removing the split of task and problems view. It has been resolved as WONTFIX.
I'd prefer a unified task/problems view. Having to switch between the two is awkward.
I liked the solution that Instantiations did - one view but with a button to switch between filters (todo tasks, compile errors, etc.).
Re: comment 26--me too.
There are some good suggestions here. However, the UI team won't have time to address this before version 3.0. We will investigate adding a new unified marker view after Eclipse 3.0.
Re: comment 22 and comment 21 The two jobs here are misleading. You are not actually waiting for these jobs (in your screenshot, they were asleep and using no CPU time). They were only shown in the progress view due to limitations in initial versions of the Jobs API. This has been fixed in new builds, which don't show the erroneous progress messages. There are good usability reasons for providing a unified marker view, but there will be no significant performance benefits.
*** Bug 59006 has been marked as a duplicate of this bug. ***
Please schedule for 3.1. I no longer use the TODO feature because I don't have that much space for another view. IMO, TODOs are problems with low severity. I would like to see Errors, warnings, then ToDos. Regarding Marker sets, I would like to work in 2 modes, depending on the development cycle: 1) Show me compiler Errors, Warnings, and Todos. 2) Show me code-auditing markers from checkstyle, such as missing JavaDoc, copyright statements, formatting issues with whitespace, etc. It would be interesting if "Marker Sets" were additive instead of just being able to choose 1 active set. Or maybe one of the choices would be "Combine...".
This is scheduled for 3.1. We will post something on the UI proposals page to describe the new marker view before development work starts.
I've added a rough proposal to the UI proposals page describing the requirements for the unified view. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/generic-marker-view/markers.html
The entire "configuration" (all settings/prefs.) for the new UMV (unified marker view) should be swappable. I was calling it a "marker set" before, but that's not the best name. For lack of a better name lets call this a "mode". Eclipse should ship with at least the 3 modes: Bookmarks, Tasks, and Problems. The available modes would be displayed in a combo on the view's local toolbar as shown in the attachment. Changes made to filters, working sets, selection, limits, etc. would be immediately saved in the active mode's configuration. If two workbench windows are both displaying the "Problems" mode, they both instantly reflect changes made to that mode's config. The user could define new modes and those modes' settings would be stored separately, similar to the ways perspectives are handled (except persistance of settings is automatic).
The requirements in comment #33 look great to me if all that can really be implemented. I'm especially interested in the line about markers not associated with a resource. Regarding comment #34, why would somebody want to have more than one view named "Problems" up? That seems like a good way to get yourself confused. Would Problems, Tasks, and Bookmarks would be different instances of the same view with different names and default filter settings, or would they be different views that share the same "MarkerView" superclass? I don't think it matters much from a usability standpoint, just wondering.
Ed, invoke Window->New Window, and you will have two Problems views open, one in *each* workbench window. I wouldn't want two problems views in the same window. In fact, I don't even want a Tasks and Problems view in the same window. Who do you think started this mess :-)
Re: comment 34 The plan is to configure filters in the way you describe (they will either be selectable in a combo, a radio list in the view menu, or something equivalent). There will be default filters for "problems", "tasks", "bookmarks", etc. However, this will only affect which markers are visible in the view - not other preferences like sort order, the set of visible columns, etc.. I've been considering a more general configuration that would include a filter plus a set of visible columns, but I was worried about complicating the UI more than necessary. (Thoughts?) The marker limit is really a performance setting, not part of the filter. It will become a global preference and will affect all marker views. Re: comment 35 The current plan is to create a new view in addition to the existing views, not necessarily to replace them. In particular, the initial cut of the new view will probably not support in-place editing and some specialized columns that only apply to one marker type. This means that, at first, the new view will only be a marker VIEWER and that the tasks and bookmarks views may remain (and possibly be further specialized) for creating and editing user-editable markers.
Re: comment 35 One idea for IMarkers that aren't tied to a IResource: If we allow 3rd party plugins to contribute their own marker filters and GOTO actions, then they could associate IMarkers with any arbitrary object like this: 1. Attach their own custom markers to some bogus IResource (like the workspace root) 2. Attach a field that identifies the model object they really want to associate the marker with. 3. Contribute a programmatic filter that only displays that marker type when that model object is selected. 4. Contribute a GOTO action that opens their model object when the marker is selected. This would allow IMarkers to appear to be associated with any arbitrary object, even though there would still be an underlying association with an IResource.
I use the bogus IResource+extra field technique in one of my plug-ins. In my case the extra field is a path name for some file that might be outside the Workspace. It works but it just seems so... bogus. :)
I think the "config" should include everything. For example: - Exclude description contains "unused import" doesn't apply to ToDo markers or Bookmarks - if I am looking for compile errors, I want Selected Resource+children, but if I am looking for tasks, I may want all resources. - If I am looking for compile errors, I want sorted by priority. Marker limit could probably be global since it's performance related, although virtual tables exist now so maybe this can be removed.
Virtual tables can only speed up the time taken to talk to the widget. It does not help with sorting or reduce the memory overhead, which are also big problems. Here's what I'm thinking of (if time permits). I'm considering using two types of filters: simple and composite. A simple filter will consist of the following: - A set of resources (selected / all / selected + children / working set / etc.) - A set of marker types to consider - For each marker type, a set of attributes and their possible values (unlike the current filters, there can be a different set of attributes to consider for each marker type) A composite filter will consist of the following: - A set of filters to include - A set of filters to exclude - Inclusion is computed first, so you can say "give me all error markers in the workspace except for markers in this known set of broken classes". As you can see, the filter will already include everything you were looking for except for sort order.
Status update: I'm currently working with Tod to push the MarkerView algorithm for deferred table updates into the JFace TableViewer class. It looks like a lot of people have strong feelings about the marker view, so I'm going to add further detail the generic marker view proposal page to get more feedback from the community. I know this PR is taking awhile, but I want to make sure that most users feel good about the change. I'll try to describe what the UI will look like and give a quick justification for it. BTW, I've heard good arguments for unifying the Problems and Tasks views since both are used to indicate things to do. However, the bookmarks view is intended for navigation, so it may not make sense to show bookmarks in the same list as problems/tasks. I personally like the idea of having one view for all marker types, but beyond my own personal asthetic sense, does anyone have any stronger arguments for unifying the bookmarks view with the other two?
No time left for 3.1.
+1 on making the new hierarchical Problems view replace the Tasks view. This is coming from the bias of using Mylar's Tasks view for managing the kinds of tasks that span resources, and using Task Tags for reminders of stuff to change in the source. Use cases of the latter seem identical to the Problems view, so it would be great to have this information inline with Problems and remove the need for a seperate view. There are some related comments on Mylar bug 114832.
There is no plan to do this.
I thought you had almost finished this problem. It seems like there is work already released in an experimental state. 3.2 has filter sets and a filters dialog (which makes the keybindings preference page look like an easy-bake oven). All that is left to do is present the filter sets on the view's local toolbar as a dropdown, similar to the window workingset toolitem.
I guess you can now mark this bug as FIXED in 3.4.
Reopening
Marking FIXED
Ooh! We have a unified view now? I can't wait to try it. I've really missed the task markers...
Verified in I20080323-2000
