Community
Participate
Working Groups
I tried using following API to toggle between projects and working sets, but it did not work, need mechanism to get it working. boolean groupingState =stateModel.getBooleanProperty(WorkingSetsContentProvider.SHOW_TOP_LEVEL_WORKING_SETS); stateModel.setBooleanProperty(WorkingSetsContentProvider.SHOW_TOP_LEVEL_WORKING_SETS, !groupingState); Also, is there API to enable/disable working sets in common navigator?, i need that if one doesn't exist. Please also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=227329
I don't feel such a thing would be appropriate in the core "CommonNavigator" class... because not all Common Navigators will be based on Resources or Working sets. In fact, many more than you'd expect may have nothing at all to do with resources or working sets. Perhaps a more specific subclass of Common Navigator could be created that would enable support for such things. But most of the Common Navigators I've worked on creating would not benefit from such a thing at all and I don't believe it would be at home in the CommonNavigator default implementation.
Is there doc or any other resources which i can use to implement the functionality i am looking for on the navigator based on common navigator ?
Rob, I think I disagree with you on this. I'm not sure but isn't WorkingSet's resource agnostic ? I believe workingsets can be more than just basic resources? And which views are not really "groupable" by workingsets (e.g. there is also a "Not in workingset" workingset so things are still visible) ? I at least miss the working set feature in the "Project Explorer"/"Navigator" views.
Oh yes it should definitely be in the Project Explorer. I'm just disagreeing with the idea that everything that should be in the package explorer should also be in the framework as a whole. At some point you need to involve some class heirarchies. CommonNavigator could be extended / subclassed to provide the added functionality that Project Explorer would need. I also think having a mandatory subclass would help ensure that the proper fields have the proper visibility in CommonNavigator... perhaps more fields and methods should be protected rather than private so that subclasses have more access. If it turns out working sets apply to other things, too, then perhaps I don't have a problem with adding working sets, so long as they're hideable.
Francis, could you please look into this defect ?, I am extending Common navigator and this defect is preventing me from making progress.
Is this something that will get fixed in 3.4.2?
If this ends up involving adding API it cannot go into a maintenance release.
I have written a test case that tests setting the properties to change the state and changing the properties currently seems to have no effect, so I have been able to reproduce your problem (and it will be part of the CNF junit tests). That is something I intend to fix for 3.4.2 (hopefully will have a patch very soon), so you should be able to use the non-API mechanism as you outline below. For 3.5 we might want to consider a real API to make this happen, and I think it's certainly something that belongs in the CommonNavigator (I'm going to disagree with you on this point Rob) as it's not specific to resources. Notwithstanding the current code for changing this is done through the part of the CNF that is related to resources. More soon...
Created attachment 118974 [details] Example of how to properly use the properties (should work in 3.4) The last test case in this file shows how to alter the properties to show the top-level elements. The important thing is to make sure the WorkingSetsContentProvider is actually loaded (that's the point of the getContentProvider() call). If it's loaded, then it will respond to the property changes. And you must refresh the viewer yourself.
Updated test cases released to HEAD (3.5M4)
My current thinking for the API support (for 3.5) is two things: 1) Move the and generalize the extensions related to working sets to be available in the org.eclipse.ui.navigator project (rather than navigator.resources). They would be made active only with the Project Explorer as present, but they would be defined in the .navigator project because they would apply to non-resource uses of working sets. 2) Make some convenience methods either on CommonNavigator or some other class that would allow the manipulation of the working set support if the working set related extensions were in fact active. I welcome comments.
(In reply to comment #9) > Created an attachment (id=118974) [details] > Example of how to properly use the properties (should work in 3.4) > > Neeraj, does this work for you in 3.4.x? If so we need to move this bug to 3.5 PW
(In reply to comment #12) > > Neeraj, does this work for you in 3.4.x? If so we need to move this bug to 3.5 Ooops, nevermind this has already been dealt with. PW
Although this would be nice, it's possible to do what is requested with the existing APIs, pushing this past 3.5.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
