This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 423495 - ElementTreeSelectionDialog unnecessarily hinders using styled label providers
Summary: ElementTreeSelectionDialog unnecessarily hinders using styled label providers
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.4   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.4 M5   Edit
Assignee: Paul Webster CLA
QA Contact: Paul Webster CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-07 08:30 EST by Rüdiger Herrmann CLA
Modified: 2014-01-21 14:24 EST (History)
1 user (show)

See Also:


Attachments
Example for an ElementTreeSelectionDialog that uses a styled label provider (3.96 KB, application/x-zip-compressed)
2013-12-16 03:49 EST, Rüdiger Herrmann CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rüdiger Herrmann CLA 2013-12-07 08:30:11 EST
The constructor of ElementTreeSelectionDialog only accespt ILabelProvider instances. This prevents clients from using an IStyledLabelProvider.

I suggest to change the constructor to accept IBaseLabelProvider. This would also enable styled label providers.
Comment 1 Paul Webster CLA 2013-12-07 14:38:35 EST
But doesn't the dialog itself need to understand the label provider protocol to make use of it?

And this dialog needs a getText/getImage which aren't in the base label provider.

PW
Comment 2 Rüdiger Herrmann CLA 2013-12-08 10:30:51 EST
(In reply to Paul Webster from comment #1)
> But doesn't the dialog itself need to understand the label provider protocol
> to make use of it?
> 
> And this dialog needs a getText/getImage which aren't in the base label
> provider.
> 
> PW

I can't find where the dialog itself uses the label provide. The 'fLabelProvider' field that gets assigned the label provider in the constructor is only used in createTreeViewer().

Moreover, I currently have a hack in place to enable styled labels and can't find any bad side effects: I pass a dummy label provider (getText() would always return "") to the constructor and set the styled label provider in an overridden createTreeiewer() after the super implementation created the viewer. If the label provider was used elsewhere in the dialog that would have become apparent.
Comment 3 Paul Webster CLA 2013-12-13 09:52:32 EST
Can you provide a sample plugin where you pass in a IStyledLabelProvider and it does something to the list?

PW
Comment 4 Rüdiger Herrmann CLA 2013-12-13 18:16:40 EST
(In reply to Paul Webster from comment #3)
> Can you provide a sample plugin where you pass in a IStyledLabelProvider and
> it does something to the list?
> 
> PW
I'm afraid, I don't understand you. The constructor wouldn't accept an IStyledLabelProvider. What exactly do you want me to do?

BTW, this is about the *ElementTreeSelectionDialog*, there is no 'list', it is a tree.
Comment 5 Paul Webster CLA 2013-12-13 21:45:42 EST
I'm asking for an example where you change the method signature and then an example that shows it being used.

PW
Comment 6 Rüdiger Herrmann CLA 2013-12-16 03:49:27 EST
Created attachment 238364 [details]
Example for an ElementTreeSelectionDialog that uses a styled label provider

(In reply to Paul Webster from comment #5)
> I'm asking for an example where you change the method signature and then an
> example that shows it being used.

The attached zip contais a plug-in with a SampleHandler and a command that contributes to the main menu.
The SampleHandler opens an ElementTreeSelectionDialog that shows the local file system where each file is decorated with its size.
Comment 7 Paul Webster CLA 2013-12-18 11:28:27 EST
Rüdiger, thanks for the sample that clarifies things.

This looks risky.  Just changing the constructor is binary incompatible, which is a no go.  Adding a second constructor appears to work, but I'm concerned about source incompatibilities (possible complaints about ambiguous calls)?

https://git.eclipse.org/r/19992

Rüdiger, does the change set do what you expect?

PW
Comment 8 Rüdiger Herrmann CLA 2013-12-30 14:19:18 EST
(In reply to Paul Webster from comment #7)
> Rüdiger, thanks for the sample that clarifies things.
> 
> This looks risky.  Just changing the constructor is binary incompatible,
> which is a no go.  Adding a second constructor appears to work, but I'm
> concerned about source incompatibilities (possible complaints about
> ambiguous calls)?
> 
> https://git.eclipse.org/r/19992
> 
> Rüdiger, does the change set do what you expect?
> 
> PW
Yes, the change set would serve my needs. I played around a bit trying to provoke the compiler to complain about ambiguous calls. From what I understand this isn't an issue here.
Comment 10 Paul Webster CLA 2014-01-21 14:24:14 EST
In 4.4.0.I20140120-2000

PW