Bugzilla – Full Text Bug Listing
| Summary: | [Perspectives] [RCP]Standalone view does not divide space in proper ratio with reference when added to IPageLayout with showTitle parameter false | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Raj Saini <rajsaini> |
| Component: | UI | Assignee: | Nick Edgar <n.a.edgar> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dev, dpwegener, michaelvanmeekeren, mlists, pwebster, sxenos |
| Version: | 3.1 | Keywords: | helpwanted |
| Target Milestone: | 3.1.2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 118659 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Raj Saini
Created attachment 18121 [details]
StandaloneView added at the bottom with showTitle parameter set to true
Created attachment 18122 [details]
StandaloneView added at the bottom with showTitle parameter set to td false
Created attachment 20226 [details]
Screenshot of Mail-App-Sample generated with Eclipse 3.1M6 RCP Wizard
This screenshot also shows the problem that the standalone view does not access
the full size of the view.
The sample app is generated with the plugin wizard in 3.1M6 (RCP Mail
template). When you maximize the window than this behavior occurs.
See comment above. If you move the divider between the two views then the left standalone view gets the correct full size of the underlying part. Yes, probably a dup of bug 85654, but I'll leave it open just in case. Do you have this fixed in CVS? No, not yet. This is a dup. *** This bug has been marked as a duplicate of 85654 *** The behavior that was described in the initial bug report is still occuring in the 3.1 final release. The problem is that the initial size assigned to a stand alone view is much more than it should be. If you look closely at the first two image attachments, you will notice the the size assigned when showTitle is false is 3-4 times the size assigned when showTitle is true. I am encountering the same behavior in an RCP application that I am developing. The stand alone view without the view tab is 3-4 times the size of a view with a view tab. Also, you are not able to make the view without the tab smaller. The divider bar won't move any farther down. This seems to be a problem with the minimum size that is being calculated for the view without the view tab. After doing some tracing, it appears as though TabbedStackPresentation.computePreferedSize is calling EmptyTabFolder.computSize. The EmptyTabFolder is calculating the size on childControl. However, this Control doesn't have any children which results in a size of 0,0 being calculated. This gets converted to the DEFAULT_WIDTH of 64 and DEFAULT_HEIGHT of 64. The result is that the prefered size gets set to 64 and you can't reduce the size below this value. The childControl that is being used appears to be the wrong Control. EmptyTabFolder has a Composite called control that appears to contain the view components. Should the size be based on control instead of childControl? Reopening and marking for consideration in 3.1.1. after the investigation in comment #10, would you be able to provide a patch with your suggested fix? If not I don't see this happening for 3.1.1 If a patch is going to be provided, is should be released before the RC2 build on Sept 23rd. After that, the likelihood of this being fixed for 3.1.1 decreses significantly. I was never able to solve the problem. My initial thoughts of using control instead of child control didn't work. I got stuck in a native call to getChildren or something similar. I'm not sure how to debug into native calls. Marking as 3.2 Filed bug 118659 for issues with Composite.computeSize (the 64x64 default) and issues encountered with GridLayout.computeSize while investigating an attempted fix to this bug using a GridLayout with 0 margins on the contentProxy in PresentablePartFolder. Created attachment 30876 [details]
Proposed patch
Stefan, would you be able to review this patch? It's not ideal, but I can't think of a better way to work around the limitations of Composite.computeSize, other than maybe subclassing it. But I'm not sure if having a specialized implementation for the content proxy in PresentablePartFolder would work in general. I'd like to put this into 3.1.2. don't see any comments from Stefan yet. Paul could you also take a look at this patch? I've run a couple of tests on 3.1.2, the patch is pretty straight forward and fixes the problem. If the tests all run, I'd say release the patch. PW I've released the patch in both the 3.1.2 and 3.2 (HEAD) streams. verified on Motif. I created a simple perspective with a standalone view with and without the title and it takes on the same (correct) size. that was on Version: 3.1.2 Build id: M20060109-1200 for Motif verification Verified on Win2K by running modified browser example against build M20060109-1200. |