Community
Participate
Working Groups
1) Select something in the resource navigator and note that its properties are shown in the properties view. 2) Open an editor which contrbutes a property sheet page and select something in it (I think the example readme editor does this). 3) The properties view page from the editor is shown properly in the Properties view 4) Select the tasks view (which is grouped with the properties view) 5) Select the properties view again without doing anything else - Note that you see the properties from the selection in the resource navigator The properties view keeps a map of workbench parts to "pages". If a part does not contribute a page, the defualt page is used. In this case clicking on tasks caused the defualt page to show (the task view does not supply any input so the input form the navigator is still visible). However the task view does not supply a selection that provides a property source so the input for the default page is not changed. Clicking back on the properties view does not change its page or input until you click on the editor. Fundamentally the problem is that the editor is sharing the properties view with other views. However, I think Eclipse could be slightly smarter here. - When the property sheet is informed that a workbench part has been activated, if the part does not supply a custom page, the property sheet should check if the part supplies a seletion that is an IPropertySource. If it doesn't then the property sheet should not explictly switch to the default page. In otherwords only flip pages if there is a reason to do so.
Randy, no work is planned for the Properties view for 3.0 except for critical bug fixes. If you think this is important, would you be willing to contribute a fix?
One issue here is the case of an empty selection in a view that normally provides an IProperySource. For example if the navigator becomes active but has no selection, shouldn't the property sheet show the default page empty? The proposed fix would cause it to continue to show its current contents.
I'm OK with it showing the current contents in that case. The fact the Navigator became active was not an explicit user selection (since in the Navigator you should select one or more resources to work with).
I think the Properties view needs to follow one of two possible models in order to be explainable. 1. It shows properties for the last active part, if any (excluding the Properties view itself). Optionally, check the active editor if the active view provides no properties. 2. It shows properties for the last part that provided properties. In both cases, it should check for an IPropertySheetPage, and if not provided, look for an IPropertySource on the selected object(s). Option 1 has the advantage of it always being easy to explain where the properties came from: either the active view or the active/frontmost editor. The disadvantage is that this will leaves the properties view empty when clicking between parts that have properties and those that don't. Option 2 is more stable, but you need to know the part navigation history in order to explain where the properties came from. Currently we follow option 2, which seems OK. I don't think anybody has ever complained that they can't understand where the properties view got its contents (although I just managed to confuse myself while playing with it -- turns out the search view provides properties and I wasn't expecting it to). Based on this, the original problem reported here is just a bug. It should not have switched to the default page -- it should have kept showing the page from the editor until another part that provides properties was activated. Also following this logic, I think it's OK to ignore views that don't provide a page and whose selection is empty.
Reassigning bugs in component areas that are changing ownership.
Bug 216786 - [PropertiesView] Properties tab should ignore focus on help tab, is at least related to this bug, if it is not a duplicate.
With the fixes of Bug 23862, each parts gets its own properties view, if a part could (potentially) provide properties. This should be option 1 as mentioned in Comment 4. When a view does not provide properties, the properties will show an message that no properties are available. With this design, the properties view will always change when a part is changed, unless the part is marked not important, see the 'org.eclipse.ui.propertiesView' 'excludeSources' extension point. With this, I consider this bug fixed. Please open bugs against specific parts, if they do not play well in this new design.
