Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313556

Summary: [project explorer] Labels always assume groups are enabled
Product: [WebTools] JSDT Reporter: Nitin Dahyabhai <thatnitind>
Component: GeneralAssignee: Nitin Dahyabhai <thatnitind>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: normal    
Priority: P3 CC: cmjaun, david_williams
Version: 3.2Flags: thatnitind: pmc_approved? (raghunathan.srinivasan)
thatnitind: pmc_approved? (naci.dai)
thatnitind: pmc_approved? (deboer)
thatnitind: pmc_approved? (neil.hauge)
thatnitind: pmc_approved? (kaloyan)
david_williams: pmc_approved+
cmjaun: review+
Target Milestone: 3.2 RC2   
Hardware: All   
OS: All   
Whiteboard: PMC_approved
Attachments:
Description Flags
proposed patch
none
grouped appearance
none
current flat layout
none
intended flat layout none

Description Nitin Dahyabhai CLA 2010-05-19 11:42:03 EDT
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".
Comment 1 Chris Jaun CLA 2010-05-19 15:00:42 EDT
Fix looks simple and safe.

I assume the call to delegeteLabelProvider.getText(element); returns correctly when flat layout is being used?
Comment 2 Nitin Dahyabhai CLA 2010-05-19 15:06:45 EDT
Yes, that's the prior behavior.
Comment 3 Nitin Dahyabhai CLA 2010-05-19 15:35:21 EDT
Created attachment 169201 [details]
grouped appearance
Comment 4 Nitin Dahyabhai CLA 2010-05-19 15:35:39 EDT
Created attachment 169202 [details]
current flat layout
Comment 5 Nitin Dahyabhai CLA 2010-05-19 15:35:56 EDT
Created attachment 169203 [details]
intended flat layout
Comment 6 Nitin Dahyabhai CLA 2010-05-19 17:59:10 EDT
* 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.
Comment 7 David Williams CLA 2010-05-19 20:17:57 EDT
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).
Comment 8 Nitin Dahyabhai CLA 2010-05-19 20:41:16 EDT
(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.
Comment 9 Nitin Dahyabhai CLA 2010-05-19 21:06:25 EDT
Committed.