Community
Participate
Working Groups
Open up two files from the Navigator, and enable the "Properties" view. Notice that as you click on each file in the Navigator, the Properties view is updated with the properties for that file, and the editor for that file comes to the front, as expected. However, if you click on the editor tabs for each of those files, the Properties view does NOT update (though the highlighted file DOES change in the Navigator window as expected); instead, the last file clicked in the Navigator is still shown in the Properties view.
Investigating as candidate for 2.1.1, in conjunction with another bug: bug 36501.
The Properties View adds itself as a selection listener for the workbench page. However, the Properties View will only update itself when the Resource Navigator is active (i.e., has focus). When selecting editor tabs, the ResourceNavigator is not active, so no updates for the Properties View occur. This is how the selection service for the Workbench Page is set up to work. Should defer this until after 2.1.1 because any fix would not be simple.
Since this is not a regression from 2.0.3, we have decided to defer this. Should address for R3.0 by tracking editor inputs, not just selection. (This must be done in a generic way, not tied to IResource.)
I'm not sure I understand the difficulty here. The Navigator window updates the "selected" resource when you switch editor tabs, so can't the properties view update based on the IResource selected in the Navigator, even when it isn't in focus?
Marking as LATER please respond if you think this is critical for 3.0
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
This is something we should simply fix. For editors we could use the editor input as fallback if there's not structured selection.
I didn't understand as much about the Workbench back in 2002/2003 when I opened this bug, but I think I get the difficulty now. The Properties View is populated by the active View in the workbench. For example, if you open up two Java source files, and switch between those resources in the Navigator or Package Explorer, you will see the Properties update for the selected Resource. If you then click on the different Java methods listed in the Outline View, you will see the Properties update for the selected method. If you then click on either of the Java Source Editors, the Properties View doesn't update at all (it keeps the previous contents). This is because the ViewPart (EditorPart) that corresponds to each of the editors isn't updating the Properties View by default. So what Daniel says makes sense -- if the editor doesn't have a StructuredSelection to provide to the Properties View, the default behavior for the EditorPart would be to query the EditorInput for the IResource being edited (if one exists), and provide that resource's properties to the Properties View, instead of continuing to show outdated information.
Sounds good to me. If we make the text editor a property source that would get us most of the cases (many of the non-text editors like GEF are already providing properties so they wouldn't have any issues).
>If we make the text editor a property source What would that mean? Would it help if text editors provide
>>If we make the text editor a property source >What would that mean? Would it help if text editors provide I love bugzilla (do I?). Does the framework query IPropertySourceProvider on selection changed - I'm not positive on this? One remaining issue is that the properties view does not nicely deal with post selection changed events (see bug 162079).
*** Bug 73552 has been marked as a duplicate of this bug. ***
*** Bug 43085 has been marked as a duplicate of this bug. ***
Still an issue.
*** Bug 190355 has been marked as a duplicate of this bug. ***
In fact, as the editor has focus and the Java editor does not provide properties, the properties view should show the default (empty) properties page and not follow the selection in the navigator. This behavior can be observed when using the project explorer (when the package explorer is closed). This bug seems to be caused by the package explorer.
(In reply to Rolf Theunissen from comment #16) > This bug seems to be caused by the package explorer. I'd say this is 99% wrong. If you disagree, please provide sound proof of your accusations.
(In reply to Dani Megert from comment #17) > (In reply to Rolf Theunissen from comment #16) > > This bug seems to be caused by the package explorer. > > I'd say this is 99% wrong. If you disagree, please provide sound proof of > your accusations. Sorry, my conclusion was per-mature. In fact, after a closer look, the problem might result from the PropertiesView only handling IStructeredSelection, in its default page. And this page is shared by all parts that do not provide a custom PropertiesViewPaga. See, PropertySheetPage line 554: if (selection instanceof IStructuredSelection) { ... } If it is not a IStructuredSelection, the selection is ignored, the previous selection is still being displayed. As a result, the default properties page shows the last selected IStructuredSelection. Doing something sane (instead of ignoring) like the snippet below, does update the default properties page selection. // change the viewer input since the workbench selection has changed. if (selection instanceof IStructuredSelection) { sourcePart = part; viewer.setInput(((IStructuredSelection) selection).toArray()); } else { sourcePart = part; viewer.setInput(new Object[] { selection }); } However, I have no clue what the side effects of this code might be, or if this behavior makes any sense.
New Gerrit change created: https://git.eclipse.org/r/133028
(In reply to Eclipse Genie from comment #19) > New Gerrit change created: https://git.eclipse.org/r/133028 With this patch, the behavior as described in option 1 of Bug 57901 comment 4 is implemented: > 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. Also, the default properties view will show the properties for the current file that is edited in the active editor, if no other structural selection is provided.
Gerrit change https://git.eclipse.org/r/133028 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3f86f44d634a9b9c56a3904b041673b498e1e948
(In reply to Eclipse Genie from comment #21) > Gerrit change https://git.eclipse.org/r/133028 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=3f86f44d634a9b9c56a3904b041673b498e1e948 I found one regression with this, multiple property views are not correctly ignored when selected. This results in a stackoverflow error. I will push a fix as after git is accessible over https again.
New Gerrit change created: https://git.eclipse.org/r/144122
Gerrit change https://git.eclipse.org/r/144122 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=fd56006e07b9bb5e1ed83acd67b991a60bba20c0
I think this one is fixed now. The properties view will change for any important part change. If any issues occur as a result of this new behavior, I suggest to open new bugs to solve them.
Thanks, Rolf for working on this ancient issue.
Created attachment 281461 [details] NullPointerException trace in TabbedPropertySheetPage.createTabComposite. After applying the patch for this fix, I still have NullPointerException in TabbedPropertySheetPage.createTabComposite.
(In reply to Georgiana Ecobici from comment #27) > Created attachment 281461 [details] > NullPointerException trace in TabbedPropertySheetPage.createTabComposite. > > After applying the patch for this fix, I still have NullPointerException in > TabbedPropertySheetPage.createTabComposite. This Bug and fix are unrelated to the TabbedPropertySheetPage, please create a new bug report for this issue. Include the precise version of Eclipse you are using. And how to reproduce it, that is which editors are you using when the NPE occurs.
