Community
Participate
Working Groups
Created attachment 253667 [details] Broken cursor rendering with GTK3 Using GEF from a Marc RC1 package, GEF version: 3.10.0.201505170205 (Build id: 3.9.100.201404071359), under Ubuntu 15.04 (64 bits), Java 1.8 and org.eclipse.swt.internal.gtk.version=3.14.12. Steps to reproduce: 1. Install the GEF Logic example. 2. Create a new Logic diagram and a "Flow Container" in it. 3. Select the "Connection" tool in the palette. 4. Move the mouse cursor over the green area on the left of the container. When using GTK3 under Linux (the default now), the transparency of the decorated cursor is broken (see attached screenshot). When running the same scenario on the same Eclipse with SWT_GTK3=0, the cursor rendering is fine (I'll attach the screenshot for reference). I'm not sure this is GEF/Draw2D-specific or directly a problem in SWT; feel free to move where appropriate.
Created attachment 253669 [details] Correct cursor rendering with SWT_GTK3=0
This is an SWT problem (as its platform specific).
Can you still reproduce this with Oxygen?
Created attachment 271939 [details] New screenshot using Oxygen.1a and Ecore Tools 3.3 Yes, still reproducible using: Oxygen.1a (Build id: 20171005-1200) with: * java.runtime.version=1.8.0_151-8u151-b12-1~deb9u1-b12 * org.eclipse.swt.internal.gtk.version=3.22.11 See the new attached screenshot. This is under Debian 9.2 "stretch" (stable), using plain X11 (no Wayland) and GNOME Shell. I had to use Ecore Tools (which is based on Sirius, itself based on GEF Legacy), as the GEF examples I used in the original steps to reproduce seem broken (by bug #522575).
This issue is still reproducible using Photon M4 (with Ecore Tools), under Debian 9 with GNOME.
Can you come up wiht pure SWT snippet showing the issue?
(In reply to Alexander Kurtakov from comment #6) > Can you come up wiht pure SWT snippet showing the issue? I'll try, but not sure I'll have the time to look at this. From what I've seen it seems related to the use of custom cursors built using org.eclipse.swt.graphics.Cursor.Cursor(Device, ImageData, ImageData, int, int) with BMP file as the image and a GIF for the mask as in https://github.com/eclipse/gef-legacy/blob/master/org.eclipse.gef/src/org/eclipse/gef/SharedCursors.java.
Created attachment 272336 [details] Sample SWT program to try to reproduce the issue I tried to reproduce the issue with a plain SWT program (attached), but got a very strange result that I don't understand: with this sample, the cursor is *correct* when using Gtk3 (v3.22.11 to be precise) but the bug can be seen when switching to Gtk2 (v2.24.31). This is the complete opposite of what I see, on the same machine (I checked again), when in the contexte of GMF diagram/canvas.
Created attachment 272337 [details] Result of the sample program when run with SWT_GTK3=0
Created attachment 272338 [details] Result of the sample program when run with SWT_GTK3=1
I've just fixed this in my own codebase and indeed, if you take a look at the code of the SharedCursors class: https://github.com/eclipse/gef-legacy/blob/master/org.eclipse.gef/src/org/eclipse/gef/SharedCursors.java#L46 You will notice that the code passes the image data and mask data in reverse order when it creates the static cursors with the createCursor(surceName, maskName) call: CURSOR_PLUG = createCursor("icons/plugmask.gif", "icons/plug.bmp"); while: private static Cursor createCursor(String sourceName, String maskName) This was probably a GTK2 specific error that was mistakenly fixed this way. That's why you are seeing correct behavior with GTK3, while incorrect on GTK2 if you test it with a proper call. Long story short, this may need to be fixed in SWT's GTK2 code path (however I doubt they will do that now. And also it must be fixed in GEF so it would work properly on GTK3. I doubt that GEF3 will be released/fixed for this also as it's a legacy code now... What I did, was that copied out the cursor files and fixed the issue with the creation in my own code and then set my own default icons for the tools i needed. (on connection tool, the editpart's drag tracker components and on some tools in the palette).
Sounds like this is a bug in GEF, running the attached SWT snippet on GTK3 worked perfectly for me. GTK2 won't be fixed as SWT-GTK2 isn't in active development any more.
*** Bug 507938 has been marked as a duplicate of this bug. ***
(In reply to Eric Williams from comment #12) > Sounds like this is a bug in GEF, running the attached SWT snippet on GTK3 > worked perfectly for me. GTK2 won't be fixed as SWT-GTK2 isn't in active > development any more. Update: GTK2 support for SWT is being dropped in Eclipse 4.10 / SimRel 2018-12 release. See the following mail for more info: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html
(In reply to Eric Williams from comment #14) > (In reply to Eric Williams from comment #12) > > Sounds like this is a bug in GEF, running the attached SWT snippet on GTK3 > > worked perfectly for me. GTK2 won't be fixed as SWT-GTK2 isn't in active > > development any more. > > Update: GTK2 support for SWT is being dropped in Eclipse 4.10 / SimRel > 2018-12 release. > > See the following mail for more info: > http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html Marking this as WONTFIX as per this comment.
*** Bug 471461 has been marked as a duplicate of this bug. ***
