build identifier: i20100403-1602

===== description =====
import window and edit chart window are truncated

==== environment =====
build level: 		i20100403-1602
component: 		birt
platform: 		sles11
jre: 			jre-1_5_0_22-windows-i586-p.exe (sun java 5)
affected locale(s): 	tchinese


===== expected result =====
the import window and edit chart window should be properly displayed

===== actual result =====
the import window and edit chart window are truncated.

reproducible: always

steps to reproduce:
===== steps to reproduce =====
1. open new project dialog from eclipse file menu, select business intelligence and reporting tools, and click next.
2. type any project name on report project dialog and click finish. open associated perspective dialog is displayed. 
    click yes to display birt perspective.
3. on navigator view, right click the project and select import, select file system, and select the test_report_chart_date_step.rptdesign. then, click finish.
4. double click the test_report_chart_date_step.rptdesign on navigator view. the report design is displayed. 
5. double click the data source and set the “select folder” to the path where orders.csv has been copied.
6. open edit chart dialog by double clicking the chart on the report layout.
created an attachment (id=164382)
screenshot 1
created an attachment (id=164383)
screenshot 2
created an attachment (id=164385)
csv and report template test data
hi, could you kindly help provide an update to this bug?

many thanks,

- steven.
hi, could you kindly help provide an update to this bug?

many thanks,

- steven.
susan, prakash, any idea why the dialog wouldn't either display the full width or provide scroll bars?

is it the dialog font calculations are off because of the chinese characters?

pw
hi paul,

a workaround is to change the resolution to 1280x1024.

the screenshots were captured under 1024x768

thanks,
cole chen
is there a possibility of having this bug fixed by this friday 4/23 ? thanks.
(in reply to comment #6)
> susan, prakash, any idea why the dialog wouldn't either display the full width
> or provide scroll bars?
> 
> is it the dialog font calculations are off because of the chinese characters?
> 
> pw

i have an idea for screenshot #2, not sure about the first one.
in screenshot #2, the cancel button is clipped, and note how large the buttons are.  i think the problem here is that the chinese font has a very large character width, so the minimum button width is computed to be very wide.  truncation occurs because of the way the layout is set up in the dialog framework.  once the button bar gets truncated, the layout stops shrinking the dialog area and both the button bar and the dialog area start clipping.  
i ran into a very similar problem with the about dialog in bug 269210, and the simplest fix was to adjust the initial dialog size to be larger. 

an explanation is in bug 269210 comment #3 (edited here)...

> when a dialog is being resized, the "dialog area" will be resized as the shell
> gets smaller.  
> the dialog area is only made smaller as the shell resizes
> *until* the button bar minimum size is reached.  at this point, the entire
> dialog contents is simply cropped.   the dialog area is no longer made smaller.
> so in dialogs where the button bar is rather lengthy, the width at which the
> "don't bother resizing the dialog area anymore" behavior kicks in happens much
> sooner. 

i'm not so sure about what's happening in the first screenshot, because it looks like the clipping starts before the buttons are clipped.  the best thing to do would be to resize the dialog and see at what point clipping occurs.  i would guess it's a similar problem.  the wide font calculation causes very large preferred widths to be calculated for the client area, and the dialog's preferred size is being computed based on some smaller composite (button bar?)
susan, can we apply the same workaround as bug 269210, use font-based metrics?  or should this be dup'ed to bug 269209 ?

pw
(in reply to comment #10)
> susan, can we apply the same workaround as bug 269210, use font-based metrics? 
> or should this be dup'ed to bug 269209 ?
> 
> pw

i cloned this bug and created bug 309839 to separate the birt chart issue from the file import issue.

the file import issue is now fixed.  see that bug for explanation.

moving this bug to birt.  please see screenshot #2 and read comment #9. 
based on the screenshot, i would suspect that the initial size of this dialog is being set explicitly using some pixel measurement.  so the dialog opens up at a size where the wizard buttons do not fit, which causes the clipping.  instead, the size should be determined using font widths that are large enough, or else the default size computation should be allowed to take place and "maxed" against whatever the original pixel size was.  this ensures that the wizard buttons will fit, and therefore the chart will not be clipped.
(in reply to comment #11)
> (in reply to comment #10)
> > susan, can we apply the same workaround as bug 269210, use font-based metrics? 
> > or should this be dup'ed to bug 269209 ?
> > 
> > pw
> 
> i cloned this bug and created bug 309839 to separate the birt chart issue from
> the file import issue.
> 
> the file import issue is now fixed.  see that bug for explanation.
> 
> moving this bug to birt.  please see screenshot #2 and read comment #9. 
> based on the screenshot, i would suspect that the initial size of this dialog
> is being set explicitly using some pixel measurement.  so the dialog opens up
> at a size where the wizard buttons do not fit, which causes the clipping. 
> instead, the size should be determined using font widths that are large enough,
> or else the default size computation should be allowed to take place and
> "maxed" against whatever the original pixel size was.  this ensures that the
> wizard buttons will fit, and therefore the chart will not be clipped.

i don't think it's birt bug. we extend jface dialog createbutton() to create buttons without setting any sizes, but apparently the button is too large compared to small fonts. chart wizard will compute the preferred size and get a large initial size because of the large buttons, so some of them will be truncated.
you see the eclipse's window (first screenshot) has the same issue. i think there should be something wrong with jface in linux
(in reply to comment #12)
> i don't think it's birt bug. we extend jface dialog createbutton() to create
> buttons without setting any sizes, but apparently the button is too large

for the cloned bug, the fix was needed in the wizard page, not the dialog itself.  how are you creating your pages?  are you using the jface wizarddialog to host it?  or is it part of the framework new/import/export wizard dialogs?

the reason it can be different on linux vs windows is they use different fonts with different sizes as their defaults.

pw
there is indeed an underlying jface bug (bug 269209) which causes the dialog area to get clipped when the buttons get clipped.  this will not be fixed in the short term.

most wizards/dialogs don't run into this problem because the initial size computation produces a wizard or dialog where the buttons are not clipped.

note in screenshot #2, the last button is clipped in the dialog.  i'm suggesting that there must be code somewhere in your dialog that is setting or computing a layout size for the dialog area, or else the shell, which causes the buttons (and therefore your chart) to get clipped.  you can test this by setting the dialog font to something very wide.

we've already fixed screenshot #1 by fixing an improper layout in the dialog area itself.
(in reply to comment #13)
> (in reply to comment #12)
> > i don't think it's birt bug. we extend jface dialog createbutton() to create
> > buttons without setting any sizes, but apparently the button is too large
> 
> for the cloned bug, the fix was needed in the wizard page, not the dialog
> itself.  how are you creating your pages?  are you using the jface wizarddialog
> to host it?  or is it part of the framework new/import/export wizard dialogs?
> 
> the reason it can be different on linux vs windows is they use different fonts
> with different sizes as their defaults.
> 
> pw

we extend traydialog and override method like this:
	protected void createbuttonsforbuttonbar( composite parent )
	{
		createbutton( parent,
				idialogconstants.back_id,
				messages.getstring( "wizardbase.back" ), //$non-nls-1$
				false );...

it's true that jface dialog to host these buttons. we didn't set size for it. usually it's framework creator to adjust size.
(in reply to comment #14)
> there is indeed an underlying jface bug (bug 269209) which causes the dialog
> area to get clipped when the buttons get clipped.  this will not be fixed in
> the short term.
> 
> most wizards/dialogs don't run into this problem because the initial size
> computation produces a wizard or dialog where the buttons are not clipped.
> 
> note in screenshot #2, the last button is clipped in the dialog.  i'm
> suggesting that there must be code somewhere in your dialog that is setting or
> computing a layout size for the dialog area, or else the shell, which causes
> the buttons (and therefore your chart) to get clipped.  you can test this by
> setting the dialog font to something very wide.
> 
> we've already fixed screenshot #1 by fixing an improper layout in the dialog
> area itself.

the fact that the second screenshot will be truncated is because there are the fifth button "apply". four buttons have enough space to display. we didn't use own algorithm to compute dialog size, just calling standard layout or pack.

could you try the similar page with 5 buttons? can it work as well?
steven - in screenshot #2, was the dialog as large as the screen?

if yes, then we can't fix this bug now.  the problem is that there are five buttons and the font "average char width" is so wide that the button size is made very large, so none of it fits, and everything is fixed.

if no, and one could resize the dialog large enough so that all buttons (and the chart) is visible, then i think the problem is in the layout or shell size setting in the birt code.
(in reply to comment #17)
> steven - in screenshot #2, was the dialog as large as the screen?
> 
> if yes, then we can't fix this bug now.  the problem is that there are five
> buttons and the font "average char width" is so wide that the button size is
> made very large, so none of it fits, and everything is fixed.

i meant to say "everything is clipped."

> 
> if no, and one could resize the dialog large enough so that all buttons (and
> the chart) is visible, then i think the problem is in the layout or shell size
> setting in the birt code.
(in reply to comment #17)
> steven - in screenshot #2, was the dialog as large as the screen?
> 
> if yes, then we can't fix this bug now.  the problem is that there are five
> buttons and the font "average char width" is so wide that the button size is
> made very large, so none of it fits, and everything is fixed.
> 
> if no, and one could resize the dialog large enough so that all buttons (and
> the chart) is visible, then i think the problem is in the layout or shell size
> setting in the birt code.

hi susan,

yes, the dialog is as large as the size of the screen. we can only change the resolution to 1280x1024 to see all the buttons.

thanks,
cole chen
(in reply to comment #19)
> hi susan,
> 
> yes, the dialog is as large as the size of the screen. we can only change the
> resolution to 1280x1024 to see all the buttons.
> 
> thanks,
> cole chen

in that case we can dup this bug to bug 269209.
unfortunately, that is not something we will fix this late in a release.
the user workaround would be to either:

- change to a higher resolution (as you mention)
- change the dialog font to a smaller font in the preferences
(in reply to comment #20)
> (in reply to comment #19)
> > hi susan,
> > 
> > yes, the dialog is as large as the size of the screen. we can only change the
> > resolution to 1280x1024 to see all the buttons.
> > 
> > thanks,
> > cole chen
> 
> in that case we can dup this bug to bug 269209.
> unfortunately, that is not something we will fix this late in a release.
> the user workaround would be to either:
> 
> - change to a higher resolution (as you mention)
> - change the dialog font to a smaller font in the preferences
> 
> *** this bug has been marked as a duplicate of bug 269209 ***

thanks susan,

in this case, could you kindly help document the work around and add a note to say the resolution to this fixed in future release?

thanks.