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

Bug 226155

Summary:	FilteredTree assumes parent uses GridLayout
Product:	[Eclipse Project] Platform	Reporter:	Shawn Minto <shawn.minto>
Component:	UI	Assignee:	Dani Megert <daniel_megert>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	achmetow84, adrian.wilkins, andy-eclipsebugs, daniel.rolka, daniel_megert, emoffatt, mik.kersten, pwebster, remy.suen
Version:	3.4	Keywords:	helpwanted
Target Milestone:	4.3 M6
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	325788

Description Shawn Minto

2008-04-08 13:00:10 EDT

A FilteredTree assumes that the layout of the parent composite is a GridLayout which can cause errors when this is not the case.  We discovered this in Mylyn when trying to add a FilteredTree to an AbstractTextSearchViewPage.  This worked on 3.3, but on 3.4, the view now uses a FillLayout.  There should be a way to specify what layout data should be used when creating the FilteredTree.

Comment 1 Timur Achmetow

2013-02-20 02:30:20 EST

I had the same problem, if you want to change the layout, you have to extend the FilteredTree and override the *createTreeControl* method. But that is not so nice. 

My suggestion: 
Extend the FilteredTree by a new constructor where a layout can be specified. 
This layout could be a class field which would be set in the method createTreeControl, if this field is null, than the old GridLayout can be set. 

Other suggestions? I could provide a patch for Gerrit, if someone is interested in this problem.

Comment 2 Paul Webster

2013-02-21 16:22:20 EST

Why not just remove the first setLayoutData(*) in createControl(*)?  Isn't that the one that's causing the problem?

PW

Comment 3 Timur Achmetow

2013-02-21 16:32:05 EST

(In reply to comment #2)
> Why not just remove the first setLayoutData(*) in createControl(*)?  Isn't
> that the one that's causing the problem?
> 
> PW
Yes, in my Opinion that's the one problem for this layout issue.

Comment 4 Dani Megert

2013-02-22 06:30:07 EST

(In reply to comment #2)
> Why not just remove the first setLayoutData(*) in createControl(*)?  Isn't
> that the one that's causing the problem?
> 
> PW

That would break existing clients. There are two possible fixes here:

1) we only set it when the parent uses grid layout
2) we extract this into a new method #setLayoutData()

I'd prefer 1) since it does the trick without adding new API and still allows clients to set their own layout data.

Comment 5 Paul Webster

2013-02-22 06:42:13 EST

(In reply to comment #4)
> 
> That would break existing clients. There are two possible fixes here:
> 
> 1) we only set it when the parent uses grid layout

I agree, that's the best course.

PW

Comment 6 Dani Megert

2013-02-22 06:43:37 EST

(In reply to comment #5)
> (In reply to comment #4)
> > 
> > That would break existing clients. There are two possible fixes here:
> > 
> > 1) we only set it when the parent uses grid layout
> 
> I agree, that's the best course.
> 
> PW

OK, I'll take care of it.

Comment 7 Dani Megert

2013-02-22 06:53:18 EST

Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c9e5e2d2d0c28bcc0fef48dcca2be87cc429db51

Comment 8 Daniel Rolka

2013-03-12 08:59:01 EDT

Verified in the build: I20130311-2000-win32-x86_64

Comment 9 Adrian Wilkins

2015-05-01 07:09:47 EDT

*** Bug 310073 has been marked as a duplicate of this bug. ***