Bugzilla – Full Text Bug Listing
| Summary: | [ActivityMgmt] TVT36:TCT175: HUN - Truncated buttons | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | CDE Administration <cdeadmin> | ||||||||||||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||||||||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Paul Webster <pwebster> | ||||||||||||||||
| Severity: | minor | ||||||||||||||||||
| Priority: | P3 | CC: | camle, kitlo, susan, vivkong, xuanchen | ||||||||||||||||
| Version: | 3.6 | Flags: | susan:
review?
(pwebster) |
||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Windows 7 | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
CDE Administration
Created attachment 167350 [details]
06.000.212_failed.jpg
<cde:tctdetail> Testcase: 06.000.212 Project: WSW36 Component: Xfer - CDT/cdt-build Priority: 3 Subject: HUN - Truncated buttons Article ID: 175 Originator: 74018713@hu.ibm.com </cde:tctdetail> Capabilities preference page is a Platform preference page. <response_by> Kathy Li at 2010.05.07.08.48.13 </response_by> Must-Fix: Yes This is the org.eclipse.ui.activities.ActivityCategoryPreferencePage, I believe. Susan, any insight? PW <response_by> Kathy Li at 2010.05.10.13.15.07 </response_by> Change this to Priority 2 as it's marked as Must-Fix from testers. <cde:tctdetail> Testcase: 06.000.212 Project: WSW36 Component: Xfer - CDT/cdt-build Priority: 2 Subject: HUN - Truncated buttons Article ID: 175 Originator: 74018713@hu.ibm.com </cde:tctdetail> (In reply to comment #5) > This is the org.eclipse.ui.activities.ActivityCategoryPreferencePage, I > believe. Susan, any insight? > > PW The problem here is that the page is calling setButtonLayoutData before it sets up the proper font in the buttons. So the button size is being computed based on the default font as set in the button, and then later Dialog.applyDialogFont is called to set the font. I suspect we have this same problem in almost any dialog that uses both setButtonLayoutData and applyDialogFont. The old pattern (before Dialog.applyDialogFont) was that every time a control was created, it grabbed the font of its parent. So in dialogs where the button font is being cascaded down the widget tree as widgets are created, calling setButtonLayoutData works without a problem. But in dialogs that call this method and then apply the font at the end, the calculation is going to (potentially) use the wrong fontmetric, depending on the user's font settings in the platform and in eclipse. To reproduce this, I set my font to a very wide one (Courier New 14) and changed the strings in the button to be very long. In practice we don't see this problem a lot because either: - the system default font and the JFace font are the same, so the timing problem doesn't matter OR - the string is short enough that the "minimum size" computed with the wrong font happens to be large enough for the string in the correct font. I can attach a patch. The proper fix probably belongs in DialogPage.setButtonLayoutData (or even Dialog.setButtonLayoutData) but we have no way of knowing if this would break existing clients. (It would definitely change the layout...hopefully for the better, but...???) So for now we would probably just fix it locally (and consider offering a new utility method in Dialog and/or DialogPage that sets the font before doing the layout). Created attachment 168003 [details]
patch that sets dialog font before doing button layout calculations
Paul, can you review? I think the patch is plenty safe, and it fixes the problem I reproduced as described above. I "assume" it fixes the problem observed. I looked at senders of setButtonLayoutData and there are plenty that are using Dialog.applyDialogFont, so this problem likely exists elsewhere (if the translations make the string fairly long). Created attachment 168004 [details]
screen shot showing fix...
Susan, We have a similar problem, and it seems this approach does not work well in our case. Please refer to bug 312171. Thanks. (In reply to comment #12) > Susan, > > We have a similar problem, and it seems this approach does not work well in our > case. Please refer to bug 312171. Thanks. I don't have the platforms under which the failure occurs so I can't speak to the problem. This fix solved the problem in English with a non-default font setting, but I wasn't sure if it would solve the problem observed. If Eclipse is using the system's default font for dialogs, then this fix wouldn't really change anything, because applying the font would make no difference. At that point I would suggest resetting the dialog font in the eclipse preferences and seeing if the problem presents on all fonts on the platform, or only certain fonts. Created attachment 168140 [details]
On linux not truncated.
Susan, could you try it out with the hu language pack from http://download.eclipse.org/technology/babel/babel_language_packs/galileo.php and -nl hu on windows (before and after your fix). The language packs just go in your dropins. PW Created attachment 168311 [details]
on win 7/default font - not truncated
Without the fix, I don't see a problem.
I'm running Win7, Build id: I20100511-0800.
I'm not too surprised by this, because the default font is the dialog font and therefore the timing problem described doesn't matter.
The problem easily presents if I change the font to something larger than the default in the jface preferences. To know if this fix would matter,we need to know what the jface dialog font is set to be on the platform where the problem presents, and how this compares to the font used for buttons in other applications. If the eclipse fonts seem different than the platform's default font, then I theorize that the proposed patch would solve the problem. If the default dialog font used by other applications is the same as that used by the JFace preferences, then I can only assume that there is some kind of problem with the text measuring code for that particular font, such that the size computed for the font is believed to be different from the "minimum button size." One way to test this theory would be to remove the code that tries to ensure a minimum button size, let the platform decide on the button size, and see if that helps. (In reply to comment #17) > If the default dialog font used by other applications is the same as that used > by the JFace preferences, then I can only assume that there is some kind of > problem with the text measuring code for that particular font, such that the > size computed for the font is believed to be different from the "minimum button > size." I didn't say that very well. If there is a bug such that the text width of "A really really long string" is believed to be smaller than it actually is on a paritcular font, and the minimum button size was presumed to be bigger, then we would set the button size to the minimum button size. Then the button would clip because the size we chose was too small. I've seen these problematic fonts in the past (years ago, on some DBCS platforms, don't remember the details). We would determine that the text width measuring simply wasn't accurate, and we would use the jface font properties files to ensure that problematic fonts were not chosen as our default font. I suspect this could be the problem, and the solution would be to change fonts. The reason that some apps wouldn't exhibit the problem in the problematic font, is that applications that don't try to size their controls (and just let the OS do it) wouldn't be affected. Only those apps that try to measure text and make decisions about the answer are affected. It's our efforts to ensure a minimum/pleasing size for buttons that cause this kind of issue. Can we please be told which font is causing the problem? PW Created attachment 168373 [details]
screen capture
Problem resolved in latest build (Eclipse I20100429-1549, NL Build 20100509-1500). Tester, please verify.
<response_by> Kathy Li at 2010.05.13.17.02.11 </response_by> Please use latest build to verify : 20100512-1300 In our case, the font used is the system font, which in this case (Korean) is Tohoma 8 (I assumed it is decided by Dialog Font in Preferences -> General -> Appearance -> Colors and Fonts). Created attachment 168544 [details]
screen capture for the font setting preferences
No comment yet if the tester can reproduce the initial problem. if this is still a problem for Hungarian in the RC1 build, please re-open. PW <response_by> rewagner at 2010.05.21.13.44.19 </response_by> I just tested this and it no longer seems to be truncated. I will ask the tester to verify it for themselves. Thanks, Ross <response_by> Manuel Ferro at 2010.05.31.12.21.47 </response_by> It's fine, for portuguese, in build 20100520-0200 Regards, Ricardo <response_by> cema tester 13 at 2010.06.07.10.55.45 </response_by> Closed. |