Community
Participate
Working Groups
Created attachment 169141 [details] proposed patch The labels under the JavaScript Resources node always use the abbreviated form intended for when the folder layout is "Grouped", even when it's set to "Flat".
Fix looks simple and safe. I assume the call to delegeteLabelProvider.getText(element); returns correctly when flat layout is being used?
Yes, that's the prior behavior.
Created attachment 169201 [details] grouped appearance
Created attachment 169202 [details] current flat layout
Created attachment 169203 [details] intended flat layout
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. The labels in the common navigator omit namespace information when settings say it should be shown. The other value in the settings intentionally hides that information. Together, that means the information is never available to the user, which makes working on large code bases very difficult to organize. Attachment 169201 [details] shows the layout in "Group" mode. Attachment 169202 [details] shows the current labels in the "Flat" layout mode, erroneously still not showing the namespace information and appearing to ruin the sorting of the content. Attachment 169203 [details] shows the intended labels in the "Flat" layout mode with the name-spaces in the labels. * Is there a work-around? If so, why do you believe the work-around is insufficient? None. The "flat" mode should show the information, but it's hidden in both layout modes. Only the status line will show the full type name, but that requires selecting the type in the tree. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested by Chris and myself, no JUnit. * Give a brief technical overview. Who has reviewed this fix? Reviewed by Chris. The label provider already includes the code for either omitting the name-space information itself or falling back to the original label provider, which does include it in the label. It just needs to check in which layout mode the view is to act correctly. * What is the risk associated with this fix? Low. The change only makes it so that the layout mode is properly checked.
Seems important to be a "well behaved" eclipse view. I approve either way, but will just ask you to double check if 'delegeteLabelProvider' could ever be null? (Sounds like it, from its name ... but I didn't apply and look at whole method).
(In reply to comment #7) > I approve either way, but will just ask you to double check if > 'delegeteLabelProvider' could ever be null? (Sounds like it, from its name ... > but I didn't apply and look at whole method). No, the lifecycle of the label provider should include its implementation of ICommonLabelProvider#init(ICommonContentExtensionSite) being called before it's used, and that's where delegeteLabelProvider is created.
Committed.
