Bugzilla – Full Text Bug Listing
|
Description
Eric Williams
The commit which causes the bug is the following: https://github.com/GNOME/gtk/commit/d22fd7223c75f4720ddb982c659efb0d8d7543c4 *** Bug 508599 has been marked as a duplicate of this bug. *** New Gerrit change created: https://git.eclipse.org/r/116370 Update: I filed a bug upstream with GTK and they have told this issue is WONTFIX. The drawing model in GTK3.10 changed such that only native (toplevel) windows are receiving expose (draw) events. This means setRegion() is non-functioning for most widgets except for Shell. We can bypass this on X11 using gdk_window_ensure_native() but it breaks a lot of stuff (like Button click events) and other important functionality. On Wayland this doesn't work at all so it's even less ideal. Another option is to clip the Cairo contexts provided with gtk_draw() to literally shape the widget. I am investigating this approach right now to see whether it's feasible or not. Gerrit change https://git.eclipse.org/r/116370 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f4d292bc19c8e894a4caa26ef5d113d800ad7b6b (In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/116370 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=f4d292bc19c8e894a4caa26ef5d113d800ad7b6b I've merged the drawing portion of this bug. A creative solution will be needed for input handling and events. New Gerrit change created: https://git.eclipse.org/r/120388 Created attachment 273398 [details]
Image showing problem when drawing ControlDecoration's hover
I'm seeing a slight visual bug that I believe was caused by commit f4d292bc19. When I hover over a ControlDecoration, the hover graphics that are shown look incorrect. I've attached an image from the "New Java Class" wizard that demonstrates. You can see the square box containing the text, and at the bottom there's the "V" shape that is supposed to make the box look like it's sort of popping out of the area where you're hovering. However you can see the area to the left and right of the "V" part of the shape are filled in with the background color of the text area.
(In reply to Daniel Wille from comment #8) > Created attachment 273398 [details] > Image showing problem when drawing ControlDecoration's hover > > I'm seeing a slight visual bug that I believe was caused by commit > f4d292bc19. When I hover over a ControlDecoration, the hover graphics that > are shown look incorrect. I've attached an image from the "New Java Class" > wizard that demonstrates. You can see the square box containing the text, > and at the bottom there's the "V" shape that is supposed to make the box > look like it's sort of popping out of the area where you're hovering. > However you can see the area to the left and right of the "V" part of the > shape are filled in with the background color of the text area. I can reproduce the issue you describe on 4.7.3, so it cannot be caused by that commit. I briefly investigated and the issue seems to happen only on Wayland, as 4.7.3 with X11 doesn't exhibit the bug. Please file a separate bug report with bug 516841 as a blocker. > I can reproduce the issue you describe on 4.7.3, so it cannot be caused by
> that commit.
>
> I briefly investigated and the issue seems to happen only on Wayland, as
> 4.7.3 with X11 doesn't exhibit the bug. Please file a separate bug report
> with bug 516841 as a blocker.
That's interesting. My guess would be that this has just always been broken on Wayland. In my case I'm working with CentOS 7.4 / GTK 3.22 / X11 and it definitely doesn't manifest until the changes in Control.setRegion(Region) are introduced. ControlDecoration calls Shell.setRegion(Region), which in turn calls Control.setRegion(Region) in order to affect the shape of its Shell (the code refers to it as a "hover with an arrow pointer"). Reverting the changes to Control.setRegion(Region) does restore the previous behavior for me.
Is the GTK behavior change perhaps only applicable for Control's, and not necessary for Shell's? Perhaps the previous code should be maintained in Shell.getRegion(Region) in place of a call to super.getRegion(Region)?
(In reply to Daniel Wille from comment #10) > That's interesting. My guess would be that this has just always been broken > on Wayland. In my case I'm working with CentOS 7.4 / GTK 3.22 / X11 and it > definitely doesn't manifest until the changes in Control.setRegion(Region) > are introduced. ControlDecoration calls Shell.setRegion(Region), which in > turn calls Control.setRegion(Region) in order to affect the shape of its > Shell (the code refers to it as a "hover with an arrow pointer"). Reverting > the changes to Control.setRegion(Region) does restore the previous behavior > for me. My apologies, you are correct! I really do have to wonder, why is this decoration a Shell modified with setRegion, when we have tooltips? Seems like more work than necessary. > Is the GTK behavior change perhaps only applicable for Control's, and not > necessary for Shell's? Perhaps the previous code should be maintained in > Shell.getRegion(Region) in place of a call to super.getRegion(Region)? I'll have to investigate. This bug isn't closed yet because there is still some work to be done, but this regression will come first. New Gerrit change created: https://git.eclipse.org/r/120655 Gerrit change https://git.eclipse.org/r/120655 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6186fb3eb3c00dde36a5ef7b90a15abcb46b5dcf (In reply to Eclipse Genie from comment #13) > Gerrit change https://git.eclipse.org/r/120655 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=6186fb3eb3c00dde36a5ef7b90a15abcb46b5dcf This fixes the issue with ControlDecorations from comment 8. New Gerrit change created: https://git.eclipse.org/r/120949 Gerrit change https://git.eclipse.org/r/120949 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f6cd30d358f78f2fea020a56b9310faf02b437da (In reply to Eclipse Genie from comment #16) > Gerrit change https://git.eclipse.org/r/120949 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=f6cd30d358f78f2fea020a56b9310faf02b437da Second commit that fixes drawing for widgets that are children of Scrollable and such. Gerrit change https://git.eclipse.org/r/120388 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=7ac153d75bbe583d855662ea077c9ab158c18169 (In reply to Eclipse Genie from comment #18) > Gerrit change https://git.eclipse.org/r/120388 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=7ac153d75bbe583d855662ea077c9ab158c18169 Input handling fixes in master now. Verified in I20180507-2205. |