Summary: | [PropertiesView] Unneeded Properties View page switch | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Randy Giffen <randy_giffen> |
Component: | UI | Assignee: | Rolf Theunissen <rolf.theunissen> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | bugs.eclipse.org, cernst, rodrigo, rolf.theunissen |
Version: | 3.0 | ||
Target Milestone: | 4.13 M1 | ||
Hardware: | PC | ||
OS: | All | ||
See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=23862 | ||
Whiteboard: | |||
Bug Depends on: | 23862 | ||
Bug Blocks: |
Description
Randy Giffen
2004-04-08 10:49:39 EDT
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. |