Fix PaintListener for GTK3 Table and Tree widgets

[akurtakov]

GTK3 emits two draw-related signals:

• EXPOSE_EVENT_INVERSE (after=false) → before GTK draws items
• EXPOSE_EVENT (after=true) → after GTK draws items

SWT historically dispatched SWT.Paint during EXPOSE_EVENT_INVERSE.

For widgets like Table and Tree, GTK draws all rows/cells after this point.
Result: anything drawn in a PaintListener was immediately overwritten.
Fixes #3285

[Copilot]

Pull request overview

This PR addresses GTK3-specific paint ordering for Table and Tree so that SWT.Paint listener drawing occurs after GTK has rendered rows/cells, preventing listener output from being overwritten (fixing #3285).

Changes:

• On GTK3, stop dispatching the inherited gtk_draw() paint path for Table/Tree and instead defer SWT paint handling.
• Invoke an explicit GTK3 paint dispatch (gtk3_paintEvent(...)) from windowProc(...) on EXPOSE_EVENT (after GTK item drawing).
• Add a shared-by-copy helper method in each widget to construct the GC and fire SWT.Paint with proper bounds/clipping.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java	Defers GTK3 SWT.Paint firing until after GTK renders tree items by adding an explicit paint dispatch in windowProc.
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Table.java	Defers GTK3 SWT.Paint firing until after GTK renders table items by adding an explicit paint dispatch in windowProc.

[github-actions]

Test Results (linux)

   94 files  ±0     94 suites  ±0   14m 23s ⏱️ +10s
4 597 tests ±0  4 373 ✅ ±0  224 💤 ±0  0 ❌ ±0 
3 383 runs  ±0  3 308 ✅ ±0   75 💤 ±0  0 ❌ ±0 

Results for commit a360eeb. ± Comparison against base commit 24b4c49.

[akurtakov]

@tmssngr I would appreciate your testing of this one.

[tomaswolf]

Regarding that checkScaleFactor: I think the AI meant

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Control.java

Line 3834 in 24b4c49

if (checkScaleFactor) {

. Don't know if there's really an issue, or if the AI was truly making things up.

[akurtakov]

Regarding that checkScaleFactor: I think the AI meant

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Control.java

Line 3834 in 24b4c49

if (checkScaleFactor) {

. Don't know if there's really an issue, or if the AI was truly making things up.

Checking scale factor before returning without doing anything more totally doesn't make sense to me.

[tmssngr]

Looks good so far (I see my drawn text).

[tmssngr]

However, by painting just a rectangle with the sizes of the clientArea it seems that getClientArea() returns incorrect values. But that's another issue, probably.

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

public class PaintOverTable {

	public static void main(String[] args) {
		final Display display = new Display();

		final Shell shell = new Shell(display);
		shell.setLayout(new FillLayout());

		final Table table = new Table(shell, SWT.BORDER | SWT.V_SCROLL | SWT.H_SCROLL);
		final TableColumn column = new TableColumn(table, SWT.LEFT);
		column.setText("Column");
		column.setWidth(100);
		table.setHeaderVisible(true);

		table.addListener(SWT.Paint, event -> {
			final Rectangle clientArea = table.getClientArea();
			event.gc.drawRectangle(clientArea);
		});

		shell.setSize(400, 300);
		shell.open();

		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) {
				display.sleep();
			}
		}

		display.dispose();
	}
}

[akurtakov]

Calculating client area is totally different problem. I'm merging this one .