Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 340268 - [Import/Export] Button label truncation on Import/Export Preferences dialogs
Summary: [Import/Export] Button label truncation on Import/Export Preferences dialogs
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.7 M7   Edit
Assignee: Prakash Rangaraj CLA
QA Contact: Prakash Rangaraj CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 344453 440093
  Show dependency tree
 
Reported: 2011-03-17 00:45 EDT by Kit Lo CLA
Modified: 2014-07-23 06:12 EDT (History)
2 users (show)

See Also:

Attachments
Import Preferences (45.37 KB, image/pjpeg)
2011-03-17 00:45 EDT, Kit Lo CLA 		no flags Details
Export Preferences (53.38 KB, image/pjpeg)
2011-03-17 00:47 EDT, Kit Lo CLA 		no flags Details
Patch v01 (1.85 KB, patch)
2011-03-24 03:18 EDT, Prakash Rangaraj CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kit Lo CLA 2011-03-17 00:45:32 EDT 
Created attachment 191375 [details]
Import Preferences

Button label truncation on Import/Export Preferences dialogs

If you replace the "Select All" & "Deselect All" button labels with some longer translations, you can see that they are truncated.
Comment 1 Kit Lo CLA 2011-03-17 00:47:01 EDT 
Created attachment 191376 [details]
Export Preferences
Comment 2 Prakash Rangaraj CLA 2011-03-23 07:22:32 EDT 
In the screenshots the text of all the controls are appended with G[ and ends with ] How did you get to this state?
Comment 3 Kit Lo CLA 2011-03-23 07:42:08 EDT 
I generated and used some "pseudo translation language packs". You probably can see the same problem if you replace "Deselect All" with "D e s e l e c t  A l l"
Comment 4 Prakash Rangaraj CLA 2011-03-24 03:18:00 EDT 
Created attachment 191808 [details]
Patch v01
Comment 5 Prakash Rangaraj CLA 2011-03-24 03:18:55 EDT 
Patch v01 released to HEAD
Comment 6 Dani Megert CLA 2011-03-28 05:00:19 EDT 
Prakash, why did you inline the button creation code and leave the createButton(...) unused, given this is internal code?
Comment 7 Prakash Rangaraj CLA 2011-03-28 07:48:17 EDT 
(In reply to comment #6)
> Prakash, why did you inline the button creation code and leave the
> createButton(...) unused, given this is internal code?

      Its not exactly inlining the code. The createButton() method first calls the setButtonLayoutData() and  then calls setText(). So the widthHint is not correctly set. The new code will setText() first and then call setButtonLayoutData(). I didn't want to change this logic in createButton() (or remove it), as I was not sure of whether its been used any clients above and its too late in the cycle to break them.
Comment 8 Dani Megert CLA 2011-03-28 07:53:52 EDT 
(In reply to comment #7)
> (In reply to comment #6)
> > Prakash, why did you inline the button creation code and leave the
> > createButton(...) unused, given this is internal code?
> 
>       Its not exactly inlining the code.
Yep, I saw that, but it's adding code duplication for which createButton(...) had been added to avoid this.

>I didn't want to change this logic in createButton() 
Is the current behavior of it useful or would they also suffer from the bug? Given it's an internal class a fix in there seems more appropriate.
Comment 9 Prakash Rangaraj CLA 2011-04-26 10:36:54 EDT 
Verified in I20110425-1800
Comment 10 Dani Megert CLA 2011-05-02 09:28:39 EDT 
My argument is that the current createButton(...) method can't work for anyone. If people worked around that bug by resizing/layouting after calling that method then their code would still work even after fixing the code in said method.

I've created a follow-up bug to clean this up during 3.8 (bug 344453).