Community
Participate
Working Groups
See Bug 530188, the update of the line ruler depends incorrectly on the layout() call in the ProgressIndicator class. To verify: Replace the layout calls in ProgressIndicator with requestLayout calls. Now use the example from Bug 530188 with the simple class below: ---------------- public class C { } ---------------- Open Java editor on this class. Place cursor after "C" and Ctrl+1 -> Rename in Workspace -> "D". After confirmation, the line numbers are gone from editor forever. To see them again, one need to re-open the editor. This works fine if the "Rename" is executed as a context menu from Package Explorer. Expectation: Line ruler update should not depend on the layout call of the ProgressIndicator.
New Gerrit change created: https://git.eclipse.org/r/136030
I think I haven seen this problem occur even with a regular layout() in ProgressIndicator -- probably caused by some other operation which deferred a layout on the same Shell. I created a Gerrit change which fixes the problem (using requestLayout in ProgressIndicator now works fine). The fix seems reasonable to me, especially since the javadoc on method layoutTextViewer says that the ruler is also layed out. I suspect that the fact that requestLayout() just marks the Widgets to be in a deferred state causes different behavior for a layout(). Interestingly, changing the layout(true, true) to requestLayout() in CompositeRuler does *not* fix the problem alone. But also calling requestLayout on the LineNumberRulerColumn$2 canvas itself does. I guess there is no equivalent to layout(true,*true*) requestLayout() which also marks all children for deferred update. Is there something else going on (maybe like bug 497812)?
Gerrit change https://git.eclipse.org/r/136030 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=9514180ac316af59f7489832eaf88ffad6ddfc5d
Thanks, Sebastian.
