Community
Participate
Working Groups
If setRedraw is called while grabbing a control, the grab is lost and all subsequent mouse events are not delivered to the grabbed control. This was introduced as part of the fix for Bug 290395. Here is a snippet: import org.eclipse.swt.SWT; import org.eclipse.swt.events.MouseAdapter; import org.eclipse.swt.events.MouseEvent; import org.eclipse.swt.events.PaintEvent; import org.eclipse.swt.events.PaintListener; import org.eclipse.swt.widgets.Canvas; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Event; import org.eclipse.swt.widgets.Listener; import org.eclipse.swt.widgets.Shell; public class RedrawSnippet { public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(display); final Canvas c = new Canvas(shell, SWT.NONE); c.setBackground(display.getSystemColor(SWT.COLOR_BLUE)); final Canvas c2 = new Canvas(shell, SWT.NONE); c2.setBackground(display.getSystemColor(SWT.COLOR_RED)); c.addMouseListener(new MouseAdapter() { public void mouseUp(MouseEvent e) { System.out.println("Mouse up"); } public void mouseDown(MouseEvent e) { c.setRedraw(false); c.setRedraw(true); } }); shell.addListener(SWT.Resize, new Listener() { public void handleEvent(Event event) { c.setBounds(shell.getClientArea()); c2.setBounds(shell.getClientArea()); } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
The original bug fix for Bug 290395 was hiding and showing the window and this caused the grab to be lost. The reason we needed to hide/show the window is that GTK is not sending out a visiblity notify event when the window becomes unobscured. We depend on that event to optimize the drawing of completely obscured widgets (GTK still sends the paint events for obscured widgets). This patch turns off this optimization for GTK > 2.17.11. Note that this is not a good final solution as it will introduce considerable performance degradation for Eclipse given that there are many obscured editors and perspectives. On a side note, we believe that this will fix Bug 333965. Paul, could you give this a spin on your home machine?
Created attachment 193191 [details] Test patch
Hi, did this fix the issue?
Fixed > 20110421
(In reply to comment #4) > Fixed > 20110421 Thank-you! I shall test it when the I build is available.
Did this make it into the weekend I builds? I still have Bug 333965 in org.eclipse.swt.gtk.linux.x86_64_3.7.0.v3730 PW
The changes released last week were just addressing the GEF bug. We weren't sure at the time that the attached patch was correct. We have since confirmed that the patch is right and have released it to HEAD. It will be available for testing in tomorrow's I-build.
I tested this on build eclipse-SDK-I20110425-1800-linux-gtk. In GEF Editors it is now possible to drag the palette splitter as detailed in Bug 321560. The only downside is that there are repaint issues as mentioned above. Dragging the palette splitter from left to right leaves a trail of slow repainted image sections. The "monkey patch" submitted in a comment to Bug 321560 actually works better.
