Community
Participate
Working Groups
I have the following issue with Luna M5 on GTK3, in any circumstances (can be views, wizards...). When a TreeItem gets expended so that the Tree is bigger than its container and requires scroll, display becomes crazy so that: * Things get drawn out of the Tree parent * The TreeItem are not displayed any more inside the Tree widget (blank, see only expand buttons).
This is to be still happening with build I20140204-0800 In order to reproduce it, the conditions are: * Tree must fit inside its parent when item are collapsed * You can expand items without any issue while they still fit in the parent * Whenever you expand an item which make the Tree bigger that the parent and the parent need to add Scrollbars, you see the issue
This may be a consequence of bug 427511
GTK >= 3.10 erases a tree area when scrolling the tree. I suppose the issue has been caused by the changes in the scrolling code described in http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/ I have made a temporary fix that forces native painting. The patch: https://git.eclipse.org/r/#/c/25758 Requirement: https://git.eclipse.org/r/#/c/25668
Definetely improves the current situation significantly. Let's push it.
Arun, as there is already the review would you please push if you agree with it?
(In reply to Alexander Kurtakov from comment #5) > Arun, as there is already the review would you please push if you agree with > it? Link to the git commit - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cc78900f837ae57b63ebd7ad5fb7e94c20673c8f
Snjezana, I think the same work around needs to be applied to Table. I see a very similar issue when doing Open Type (Ctrl+shift+T), doing content assist, etc. As soon as there is a scollbar necessary, the content disappears. Patch: https://git.eclipse.org/r/26471
(In reply to Marc-Andre Laperle from comment #7) > Snjezana, I think the same work around needs to be applied to Table. I see a > very similar issue when doing Open Type (Ctrl+shift+T), doing content > assist, etc. As soon as there is a scollbar necessary, the content > disappears. > > Patch: > https://git.eclipse.org/r/26471 I can reproduce the issue you are talking about. The patch fixes it.
Review +1 for Marc's patch too (aka the flag still true) as stated in gerrit too.
(In reply to Marc-Andre Laperle from comment #7) > Snjezana, I think the same work around needs to be applied to Table. I see a > very similar issue when doing Open Type (Ctrl+shift+T), doing content > assist, etc. As soon as there is a scollbar necessary, the content > disappears. > > Patch: > https://git.eclipse.org/r/26471 Pushed - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2958e16615b4d5e0811266d64a0c720c35a392bf
*** Bug 427487 has been marked as a duplicate of this bug. ***
Alexander, Arun, I think we can mark this bug as resolved.
Marking as fixed now.
Created attachment 251230 [details] Small SWT + Jface program This snippet reproduces the bug, after reverting http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2958e16615b4d5e0811266d64a0c720c35a392bf
(In reply to Marc-Andre Laperle from comment #14) > Created attachment 251230 [details] > Small SWT + Jface program > > This snippet reproduces the bug, after reverting > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=2958e16615b4d5e0811266d64a0c720c35a392bf (In order to fix bug #446075,) I've been looking at this bug and how it was fixed. As a little test I stopped overriding the GtkCellRendererClass.render function (in Display.rendererClassInitProc) and let the individual GtkCellRenderers render themselves... and everything displays correctly. I had a look around lots of Eclipse dialogs and couldn't see any Table/Tree out of place. Looking back at the history, this class function was overridden a long time ago with little clue left as to why. Maybe I'm missing something important here and it would break some common use case, but could it be removed?
(In reply to Jonny Lamb from comment #15) > Maybe I'm missing something important here and it would break some > common use case, fwiw, bold text doesn't seem to work.
I believe this caused Bug 461251
