Community
Participate
Working Groups
After updating to 3.5RC1 I noticed that the section header labels in the Mylyn Task Editor where cut off (see screenshot). Once I reflow the form, e.g. by toggling one of the sections, all labels appear with the full text. Not sure if this is a bug in Forms or in SWT.
Created attachment 136609 [details] section header (should be "Description")
What version were you using before you upgraded?
I was running 3.5M7. We are not seeing this problem on other platforms or older versions.
Nothing has change in UI forms between 3.5M7 and now except for the busy indicator. It's conceivable that a change in another component could have triggered this although it still seems that the problem is most likely in UI forms. There used to be a problem of miscalcualating the width required for the header of a form but that has long been fixed. Do you have a test case or a way that I can reproduce the problem on my own machine.
Strange, I consistently see thi in my self-hosted environment on Ubuntu 8.04 with Gtk 2.12.9 but not if I run an installed EPP package. I'll let you know if I find steps to reproduce the problem.
I was able to reproduce this on Linux using I20090518-2000 and downloading Mylin from the Galileo update site. I'll see if I can see anything obviously wrong although it would still be easier with a smaller test case.
I just checked out org.eclipse.ui.forms, set the sources to version v20090429-1800, the same as was in 3.5M7 and launched a new run time workbench. The truncation problem is still there, so this is not due to any recent change in ui.forms.
Created attachment 136753 [details] scrollbar
I have noticed another oddity in Mylyn that may be related: You can see in the screenshot that the hyperlink in the Task List header pushes the scrollbar of the screen whereas in on other Eclipse versions the hyperlink would be cut off and not affect the width of the Task List
Please ignore comment 8 and 9, these problems are caused by entirley unrelated changes in the Task List code.
Steve, can you think of anything that has changed in platform UI between M7 and RC1 that could affect how a editor lays out its components, or when layout is called? I have checked out of CVS org.eclipse.mylyn.tasks.ui to debug the problem but I don't see too many clues as to what is causing the problem. The title is stored in a Label widget and the Mylin code is setting the title on the next line after the constructor for the section is called. I don't see this problem in any other code that uses sections, such as the help view or org.eclipse.ui.forms.examples. I'll continue to debug this to see if I can come up with any insights.
> in platform UI Paul can answer this.
I have some more information from debugging this and putting breakpoints in some of the functions in org.eclipse.swt.widgets.Label. When the editor is initially laid out and computeSize() is called for the label "Attributes" it comes back with a width of 63, which is too short. When I maximize the editor and the size is recomputed for that label the width comes back as 74, which is correct. My first guess was that the font size had changed however I did not see any calls to Label.setFontDescription() on that label between the first and second time the size was computed. Something is happening between the first and second time that computeSize() is called which is affecting the result but I don't know what it is. Is the Mylin task editor doing anything unusual with fonts?
We use the standard fonts for the section headers. The only thing that may be different about the task editor is that is disabled redraw on the form in createFormContent() but that shouldn't affect the calls to layout. Chris, you might want to take a look at the changes made for to this platform bug. It may affect the computSize() of the label: 236808: Errors/Warnings preference page wraps label on linux when it should not https://bugs.eclipse.org/bugs/show_bug.cgi?id=236808
I just tried importing the 3.5M7 version of the org.eclipse.sdk plug-in into my workspace but it did not make the problem go away. It seems that when the size is computed incorrectly it is the same incorrect value for each of the labels that gets truncated. "Atrributes","Description" and "Personal Planning" all get truncated to the same length. How sure are you that this is a regression since 3.5M7?
I consumed some of the 3.5 SDK milestones by updating through P2 therefore I can't be a 100% sure that it properly updated all plug-ins and features along the way. When I ran RC1 from a freshly installed SDK I noticed the problem for the first time.
I'm not sure what to do next, there is very little time left in Eclipse 3.5 and we still don't know which component the problem is in, let alone have a fix. I would like to understand why this has recently started failing and see if there is a workaround. If you can create a smaller test case that would help a lot.
I can reproduce the problem with this snippet: public class FormLabel { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Form form = new Form(shell, SWT.NONE); form.getBody().setLayout(new GridLayout()); FormToolkit toolkit = new FormToolkit(display); Section section = toolkit.createSection(form.getBody(), ExpandableComposite.TWISTIE); section.setText("Attributes"); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
If I run the snippet on 3.5M7 the layout is okay. If I run it on Eclipse 3.5RC1 the label is cut off. The version of org.eclipse.ui.forms does not make a difference. If I revert changes made for bug 236808 in SWT the problem goes away. I'll reopen that bug.
Reassigning to SWT since this regression was introduced by a change in SWT. I have confirmed that the problem occurs with an RC1 or later version of org.eclipse.sdk.gtk.linux.x86, the M7 version works fine. I will join Steffen in requesting that SWT back out the fix for bug 236808 (assuming that this was the bug that caused the regression). I have also raised the priority because this is a regression which causes existing UI to not display correctly and will likely affect more users.
Bogdan, did you ever track this down?
Yes - the new code in Label.computeSize is OK, but we need to call forceResize to get GTK to update to the current label size before attempting to measure the text length. I'll attach a patch here.
Created attachment 137211 [details] Label patch
Created attachment 137218 [details] Updated patch
Fixed in HEAD > 20090526
This appears to work with: I20090526-2000
Verified in I20090526-2000. I was able to bring up the task editor and it displayed correctly. This was on the same machine where I had reproduced the bug using I20090518-2000.
*** Bug 276402 has been marked as a duplicate of this bug. ***
*** Bug 276613 has been marked as a duplicate of this bug. ***
*** Bug 277575 has been marked as a duplicate of this bug. ***
