Community
Participate
Working Groups
In our RCP applications we have views that we do not want users to be able to open via the 'Show View' dialog. These views tends to rely on a given "input". For instance, we have some statistics that the user would like to see by selecting it in our tree. However, if they just open the view, then there is no statistic input so it is not showing anything. The Platform already does this filtering for the 'Welcome' view. You can refer to org.eclipse.ui.internal.dialogs.ViewContentProvider's method below. /** * Removes the temporary intro view from the list so that it cannot be activated except through * the introduction command. * * @param list the list of view descriptors * @return the modified list. * @since 3.0 */ private ArrayList removeIntroView(ArrayList list) { for (Iterator i = list.iterator(); i.hasNext();) { IViewDescriptor view = (IViewDescriptor) i.next(); if (view.getId().equals(IIntroConstants.INTRO_VIEW_ID)) { i.remove(); } } return list; } Thus, we would like a public way for RCP and plug-in developers to do something like the above. ;)
For views that accept input of some kind, the eclipse best practice is to have a default page (a la PageBookView) seen in the hierarchy or outline view. That being said, there's already a way to filter views from the show view dialog, activities/capabilities. A standard activity that is false should remove the view from the dialog but still allow it to be programmatically shown. Now, if you could convince me that activities is not good enough, I might consider adding a programmaticOnly flag to the view descriptor, so the only way to open a view would be to use IWorkbenchPage#showView(*) ... but it would have to be better than the checkbox at the bottom of the dialog :-) PW
(In reply to comment #1) > That being said, there's already a way to filter views from the show view > dialog, activities/capabilities. A standard activity that is false should > remove the view from the dialog but still allow it to be programmatically > shown. Well, you've convinced me it's good enough. The XML below should filter out a view, but calling showView won't magically cause it to start showing up in the dialog. <extension point="org.eclipse.ui.activities"> <activity id="forbiddenViewActivityId" name="Forbidden View Activity"/> <activityPatternBinding activityId="forbiddenViewActivityId" isEqualityPattern="true" pattern="org.eclipse.ui.views/org.eclipse.ui.views.ContentOutline"> </activityPatternBinding> </extension> Markus, this seems to work fine on our RCP product. Paul, feel free to close as WORKSFORME.
Actually, you didn't even need the 'isEqualityPattern' attribute, that can be deleted also.
Hi Paul, I would like to attempt to convince you that the activities API is unfortunately not good enough :-) We have an application in which we would like the ability for a certain view to ONLY be opened through a wizard. In specific, we have a CustomChartView whose chart we want users to have to configure before the view will be shown. I attempted to use the activities to remove the shortcut from the "Open View->Other" list (and was successful); however, in order to open the view programmatically, I had to wrap the code with a <code> rightsManager.grant("showChartView"); ...show view... rightsManager.revoke("showChartView"); </code> At first glance, this solution appeared to work, however, when the application is closed, a NullPointerException is thrown in ViewFactory#saveState(IMemento) due to the fact that ViewRegistry#find(String) consults WorkbenchActivityHelper#restrictUseOf(Object) to determine if the view should be allowed to be saved. I feel that this null pointer is a separate issue and I will enter it as a separate bug if requested, but I am in fact mis-using the API, so I don't know if it really counts as a bug. I cannot currently find another way to do this, but your "programmaticOnly" flag seems like the perfect solution. Do you have any other ideas of how to achieve this or do you have any arguments against my use case? Also, since this isn't a huge deal, we would definitely consider waiting until 3.5 for a solution if one is already available. Thanks very much for any responses! TF
(In reply to comment #4) > <code> > rightsManager.grant("showChartView"); > ...show view... > rightsManager.revoke("showChartView"); > </code> Just 2 things ... you need to allow your enabling condition to be valid for the entire time that your view is available. And there is no more time to add API in 3.5, so there's nothing that could be added that your code/XML could see. PW
Hi Paul, Thanks for the information. Your solution would work perfectly except that our view is allowed to have multiple instances. Since the "Open View" menu only takes into account the primary ID (as far as I can tell), it would still open a blank charting view. One of the primary selling points of our application is the ability to use custom charts, and everybody does, which means that the view would almost always still be available in the menu. When it comes to UI design, I prefer consistency over correctness. If it can't be perfectly correct all of the time, then it might as well be consistently wrong so that it doesn't confuse the user. For now, I guess it is acceptable to simply leave it where it is considering nobody has complained, but it would be nice to have some sort of solution eventually. Do you know if there is supposed to be a 3.6 or if they are jumping straight to e4? Thanks again for your help. TF
(In reply to comment #4) > ONLY be opened through a wizard. In specific, we have a CustomChartView whose > chart we want users to have to configure before the view will be shown. > > I attempted to use the activities to remove the shortcut from the "Open > View->Other" list (and was successful); however, in order to open the view > programmatically, I had to wrap the code with a > > <code> > rightsManager.grant("showChartView"); > ...show view... > rightsManager.revoke("showChartView"); > </code> This is strange. Our view could be opened from wizards or from a handler and we simply showed the view by calling showView on IWorkbenchPage. What is this 'rightsManager'?
(In reply to comment #1) > That being said, there's already a way to filter views from the show view > dialog, activities/capabilities. A standard activity that is false should > remove the view from the dialog but still allow it to be programmatically > shown. BTW, "CTRL + 3" allows user to open "hidden" Welcome view. So an "opt out" for some views would be nice.
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.
