eclipse-platform / eclipse.platform.swt Goto Github PK

The getZoomForAutoscaleProperty returns 100 or 200 if the autoscaleValue is not set. This results in images are only 100% when windows scaling is smaller than 175% or 200% when windows scaling is higher than 175%. Using this for pictures results in blurry images or lost information when the images are stretched or reduced in their size. It also takes the opportunity to use swt with other technologies which do scaling correctly. since it leads to cut offs. Using the "autoscale property feature" results in other problems which is shown in another issue. Below example shows what happens if you use HTML Rendering (uses AWT as technical layer) and SWT together:

The SWT Text and the HTML Text should be the same size. but when using 150% windows scaling, we get different sizes for the text. Also the boxes which are drawn by swt, are to small since they got autoscaled down to 100% when using 150% windows scaling, leading to cut off on the text.

@SyntevoAlex : on Linux, I see now compiler error: Type mismatch: cannot convert from GdkRGBA to int in org.eclipse.swt.tests.manual.Issue0021_HdcLeak_ImageCreateGdipImage

Originally posted by @iloveeclipse in #22 (comment)

Introduced in #22.

Continuing porting of Clipboard to GTK4 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=574949).

Rich text in GdkClipboard needs a GValue with type GTK_TYPE_TEXT_BUFFER. This constant isn't returning the correct value through JNI, so a constant with the correct value in OS.java is needed.

Tracked in #228

As discussed in the https://bugs.eclipse.org/bugs/show_bug.cgi?id=574412 we need to provide support to customize the selection background (focused and unfocused) colors for tree and tables to support more modern UI themes like vscode. Depending on OS colors for these UI element cause lot of mismatches in the color mixing for themes.

Bug 493455 accidentally removed device.internal_dispose_GC(hDC, null) from Image.createGdipImage() on win32, which now leaks one HDC per image created. Note that GC.drawImage() may create the image internally.

As the leak grows, Windows get slower. When leak reaches 10000 (default maximum for one process), SWT will begin to throw SWT.error() and UI begins to malfunction.

I'll provide a patch.

On a pure SWT application we used the SWTs gc with drawText, draw Rectangle and draw String method. When using scalings with different values you see that the text and the drawing of the rectangle are not scaled the same way. So the text is sometimes to small or cuts the rectangle. So SWT is not usable for custom drawings (like drawing a table) since the customers do get texts which are cut off or cells wich have much lost space which is not used.

In the above picture you can see how icons lose information when they are scaled down, which also happens to images (1). The title areas are adapted to their height at each scaling but the width is only extended when you go above or blow the 175% (2). The height and the width of the shell on which is drawen is also only adapted on 175% scaling changes (3). But the biggest problem is that drawing with drawText or drawString and using the draw Rectangle method, leads to text which does not fit into the drawen rectangles at different zooms (4)
The following snippet delivers the results seen on the picture when starting it with different scalings.
`
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
try {
shell.addPaintListener(new PaintListener() {

    @Override
    public void paintControl(PaintEvent e) {
      e.gc.drawText("Long Test Text", 20, 40);
      e.gc.drawRectangle(20, 40, 95, 30);
      e.gc.drawString("Long Test Text", 20, 75);
      e.gc.drawRectangle(20, 75, 95, 30);
    }
  });
  shell.setMinimumSize(400, 450);
  shell.pack();
  shell.open();
  while (!shell.isDisposed()) {
    if (!display.readAndDispatch()) {
      display.sleep();
    }
  }
} finally {
  display.dispose();
}

}
`

macOS 12.3.1
M1 Mac Mini
Eclipse Version: 2022-03 (4.23)
Eclipse Build id: I20220308-0310

1. Launch child Eclipse
2. Set a font in Preferences
3. When the FontDialog opens this is written to the log:

java[3258:51770] It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.

It occurs at line 178 in org.eclipse.swt.widgets.FontDialog:

panel.orderFront(null);

Not sure if this is an indication of something important or not. Thought I'd open an issue, just in case.

Currently it say:

• Note that a Button can display an image and text simultaneously
• on Windows (starting with XP), GTK+ and OSX. On other platforms,
• a Button that has an image and text set into it will display the
• image or text that was set most recently.

As we only support these platform we can re-write it to: * Note that a Button can display an image and text simultaneously.

As per the latest SWT Windows JUnit report, we notice one failure:
https://download.eclipse.org/eclipse/downloads/drops4/I20220417-1800/testresults/html/org.eclipse.swt.tests_ep424I-unit-win32-java11_win32.win32.x86_64_11.html

Thanks @sravanlakkimsetti for pointing to the exact log with more details on the failure:
https://download.eclipse.org/eclipse/downloads/drops4/I20220417-1800/testresults/ep424I-unit-win32-java11_win32.win32.x86_64_11/org.eclipse.swt.tests.junit.AllNonBrowserTests.txt

Raised this issue to capture bug highlighted in below test Snippet seen StyledText widget:
#37 (comment)

If a FileDialog is created with SWT.OPEN but setFilterPath is not used to set a path other than the default empty string, the error: "The folder contents could not be displayed" "Operation not supported" is shown.

This does not happen with FileDialog created with SWT.SAVE or if setFilterPath sets the path to something valid.

Tested using Snippet72 and commenting out all relevant lines that set filter related fields.

Tracked in #228

I am using the current Windows 11 Insider Build from the Beta Channel (22H2 - 22581.100) that was released a few days before.

Since this build using Eclipse (2022-03) is more or less not possible anymore. Clicking around the package explorer or debugging causes the entire IDE to freeze for up to a few minutes.

I attached a profiler to Eclipse and found out that getting the selection from a tree is horrible slow. Seems that the win32.OS.SendMessage call that is done by the tree is now magnitudes slower as before. See attachments

Can someone from the SWT team check and report back with some more details what is causing the issue. If caused by recent changes in Windows i can submit some feedback with more details so that they can have a look.

A user of SmartGit 21.2 (which uses SWT 4946r10) reported following exception:

java.lang.ArrayIndexOutOfBoundsException: Index 4 out of bounds for length 4
	at org.eclipse.swt.widgets.Table._getItem(SourceFile:209)
	at org.eclipse.swt.widgets.Table.sendMouseEvent(SourceFile:3650)
	at org.eclipse.swt.widgets.Display.applicationSendTrackingEvent(SourceFile:5401)
	at org.eclipse.swt.widgets.Display.applicationNextEventMatchingMask(SourceFile:5370)
	at org.eclipse.swt.widgets.Display.applicationProc(SourceFile:5765)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper
	at org.eclipse.swt.widgets.Widget.callSuper(SourceFile:235)
	at org.eclipse.swt.widgets.Widget.mouseDownSuper(SourceFile:1146)
	at org.eclipse.swt.widgets.Table.mouseDownSuper(SourceFile:2132)
	at org.eclipse.swt.widgets.Widget.mouseDown(SourceFile:1138)
	at org.eclipse.swt.widgets.Control.mouseDown(SourceFile:2631)
	at org.eclipse.swt.widgets.Table.mouseDown(SourceFile:2103)
	at org.eclipse.swt.widgets.Display.windowProc(SourceFile:6120)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper
	at org.eclipse.swt.widgets.Widget.callSuper(SourceFile:235)
	at org.eclipse.swt.widgets.Widget.windowSendEvent(SourceFile:2150)
	at org.eclipse.swt.widgets.Shell.windowSendEvent(SourceFile:2487)
	at org.eclipse.swt.widgets.Display.windowProc(SourceFile:6244)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper
	at org.eclipse.swt.widgets.Display.applicationSendEvent(SourceFile:5488)
	at org.eclipse.swt.widgets.Display.applicationProc(SourceFile:5631)
	at org.eclipse.swt.internal.cocoa.OS.objc_msgSend
	at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(SourceFile:117)
	at org.eclipse.swt.widgets.Display.readAndDispatch(SourceFile:3880)

It is not reproducible for him. This bug seems to be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=567703 or https://bugs.eclipse.org/bugs/show_bug.cgi?id=456602

It is assumed that a null layout data implies the center region, but BorderLayout.getTotal is not aware of this and throws:

Caused by: java.lang.NullPointerException
	at org.eclipse.swt.layout.BorderLayout.lambda$4(BorderLayout.java:233)
	at java.base/java.util.stream.ReferencePipeline$4$1.accept(ReferencePipeline.java:212)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.IntPipeline.reduce(IntPipeline.java:491)
	at java.base/java.util.stream.IntPipeline.sum(IntPipeline.java:449)
	at org.eclipse.swt.layout.BorderLayout.getTotal(BorderLayout.java:233)
	at org.eclipse.swt.layout.BorderLayout.computeSize(BorderLayout.java:147)
	at org.eclipse.swt.widgets.Composite.computeSizeInPixels(Composite.java:269)
	at org.eclipse.swt.widgets.Control.computeSize(Control.java:837)
	at org.eclipse.swt.widgets.Control.pack(Control.java:1609)
	at org.eclipse.swt.widgets.Control.pack(Control.java:1584)

Originally reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=573274

I have an Event handler (reacting to mouse move/click) and add the following:

System.out.println(event.stateMask + " --> " + (event.stateMask & SWT.MODIFIER_MASK));

the result is always 0 if I hold down the 'Alt Gr' key. Pressing Alt, Strg, Shift results in a non null value as expected.

Interestingly event.stateMask is 0 for mouse move and 524288 for mouse clicks.

When using the swts Display class it has different methods which take care about the zoom. The Display class should not have the zooms, only the devices should have the zoom. When you call the getMonitor method of the display class, the zoom to the devices is set to the ones of the primary monitor on windows versions above 8.1:

As you see this can not happen since the else case can not be reached on windows 8.1. And even if the dpi is used you do not get the results which are helping. When you have dpi unaware, the dpi is always 96 pixels, if you have dpi aware application mode than you get the one from the primary monitor and if you have the per monitor (v2) you get the correct dpi. But the last mode can not be used since the dpi awareness only works on the main window and its direct child. The other controls like tabs and so on are not taking part in the per monitor awareness.

Windows 10
Eclipse 4.23 and 4.24

This seems to be a regression as this is working in Eclipse 4.22 but not in 4.23 and 4.24.

In the SWT as used in Eclipse 4.22 and earlier, a FileDialog would remember the last open directory. In the SWT in Eclipse 4.23 and later it reverts to the root "Computer" directory on Windows.

Run the snippet below against a target of Eclipse 4.22 and compare with a target of 4.23. Click the "Open" button, navigate to a file and open this. Repeat. On Eclipse 4.22 target the previous directory is remembered. Not on 4.23 target.

import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.FileDialog;
import org.eclipse.swt.widgets.Shell;

public class FileOpen {

    public static void main(String[] args) {
        Display display = new Display();
        Shell shell = new Shell(display);
        shell.setLayout(new GridLayout());
        shell.setSize(300, 200);
        
        Button button = new Button(shell, SWT.PUSH);
        button.setText("Open");
        button.addSelectionListener(new SelectionAdapter() {
            @Override
            public void widgetSelected(SelectionEvent e) {
                new FileDialog(shell, SWT.OPEN).open();
            }
        });
        
        shell.open();

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

The device zoom in the DPIUtil is a static field which is only set once to the device zoom of the primary monitor. So using any method from DPIUtil delivers wrong values on multi monitor environments where the scaling differs between the primary and any other monitor. Moving a window from primary monitor with a scaling value of 125% to a secondary monitor with 250% results in bitmap scaling and blurry text.

The text should not get blurry.

Here's an example from our app:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=493455 has been fixed on Windows and closed. This issue tracks the bug on Mac.
Please see bug for description and snippet.
This causes the test failure seen in #30

During eclipse-pde/eclipse.pde#53 is see terrible hotspots in

• org.eclipse.swt.widgets.Synchronizer.addLast ()
• org.eclipse.swt.graphics.Device.isDisposed ()
• org.eclipse.swt.widgets.Synchronizer.asyncExec ()
• Display.findDisplay ()

while the amount of messages in org.eclipse.swt.widgets.Synchronizer.addLast(RunnableLock) was > 1million.

All those functions show "synchronized" blocks, which could be probably avoided with the usage of appropriate classes of java.util.concurrent.

Sampling of SWT Thread:

And asyncExec() seen in a sampling of a background thread:

When using FontMetrics.getHeight or GC.textExtents method you get strange results. If we use different scaling. the table shows +25% scaling raises the height by 5 Pixels but the width is one time extends by 20 pixels and the other time by 16 pixels.. Using 125% scaling and 250 scaling almost delivers the same results, but the height is 1 pixel different. This shows that the texts are not scaled proportionally which does not fit to the drawing of the boxes. (This does not fit to the draw rectangle methods which are scaled proportionally).

Moving the bug from bugzilla Bug 579460 - Keyboard shortcuts for radio buttons don't work anymore

I discovered in 2 dialogs, that the following shortcut keys for the radio buttons do not work anymore since Eclipse 4.23

<Alt>-A in the review licenses dialog

<Alt>-K in the encapsulate field dialog

I originally reported this on https://bugs.eclipse.org/bugs/show_bug.cgi?id=579665, but then I got the information that you likely check github issues more often than the bugzilla entries. Feel free to close either one as a duplicate...

After creating one or several o.e.swt.custom.CTabItem for a o.e.swt.custom.CTabFolder, no tab will be selected by default and thus, the content will be "blank". This is a difference to the behavior of o.e.swt.widget.TabFolder where the first created o.e.swt.widget.TabItem will be selected by default.

Is there any reason why the first CTabItem is not selected by default?
The user of the class can still override if needed...

The below snippet is based on Snippet76.java:

/*******************************************************************************
 * Copyright (c) 2000, 2011 IBM Corporation and others.
 *
 * This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License 2.0
 * which accompanies this distribution, and is available at
 * https://www.eclipse.org/legal/epl-2.0/
 *
 * SPDX-License-Identifier: EPL-2.0
 *
 * Contributors:
 *     IBM Corporation - initial API and implementation
 *******************************************************************************/
package org.eclipse.swt.snippets;

/*
 * TabFolder example snippet: create a tab folder (six pages)
 *
 * For a list of all SWT example snippets see
 * http://www.eclipse.org/swt/snippets/
 */
import org.eclipse.swt.SWT;
import org.eclipse.swt.custom.CTabFolder;
import org.eclipse.swt.custom.CTabItem;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.TabFolder;
import org.eclipse.swt.widgets.TabItem;

public class Snippet76 {
	public static void main (String [] args) {
		Display display = new Display ();
		final Shell shell = new Shell (display);
		shell.setText("Snippet 76");
		shell.setLayout(new GridLayout());

		createTabFolder(shell);
		createCTabFolder(shell);
		
		shell.setSize(400, 400);
		shell.open ();
		while (!shell.isDisposed ()) {
			if (!display.readAndDispatch ()) display.sleep ();
		}
		display.dispose ();
	}

	private static void createTabFolder(Composite parent) {
		TabFolder tabFolder = new TabFolder (parent, SWT.NONE);
		tabFolder.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true, 1, 1));
		tabFolder.setLayout(new GridLayout());
		for (int i=0; i<6; i++) {
			TabItem item = new TabItem (tabFolder, SWT.NONE);
			item.setText ("TabItem " + i);
			Button button = new Button (tabFolder, SWT.PUSH);
			button.setText ("Page " + i);
			item.setControl (button);
		}
	}

	private static void createCTabFolder(Composite parent) {
		CTabFolder tabFolder = new CTabFolder (parent, SWT.NONE);
		tabFolder.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true, 1, 1));
		tabFolder.setLayout(new GridLayout());
		for (int i=0; i<6; i++) {
			CTabItem item = new CTabItem (tabFolder, SWT.NONE);
			item.setText ("CTabItem " + i);
			Button button = new Button (tabFolder, SWT.PUSH);
			button.setText ("Page " + i);
			item.setControl (button);
		}
	}
}

This is how it will be rendered on Windows 10:

The problem does not appear if "Shell#setSize(int,int)" is replaced by "Shell#pack()".
I first saw the issue in a view inside the Eclipse IDE, so I suppose it's the setSize variant that is generally used there and not the pack variant.

This test fails on Linux, it is a regression from #24.
https://download.eclipse.org/eclipse/downloads/drops4/I20220406-0600/testresults/html/org.eclipse.swt.tests_ep424I-unit-cen64-gtk3-java11_linux.gtk.x86_64_11.html

Test_org_eclipse_swt_widgets_Button | test_traverseCheckButton | Failure | N/A
java.lang.AssertionErrorat org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertTrue(Assert.java:53)
at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Button.test_traverseCheckButton(Test_org_eclipse_swt_widgets_Button.java:448)

Originally posted by @iloveeclipse in #24 (comment)

See https://github.com/eclipse-platform/eclipse.platform.swt/runs/6323264272?check_suite_focus=true

Error:  Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:3.0.0-SNAPSHOT:compile (default-compile) on project org.eclipse.swt.tests.win32: Compilation failure: Compilation failure: 
Error:  D:\a\eclipse.platform.swt\eclipse.platform.swt\eclipse.platform.swt\tests\org.eclipse.swt.tests.win32\JUnit Tests\org\eclipse\swt\widgets\Test_org_eclipse_swt_widgets_Display.java:[24] 
Error:  	boolean xMouseActive = display.isXMouseActive();
Error:  	                               ^^^^^^^^^^^^^^
Error:  The method isXMouseActive() is undefined for the type Display
Error:  1 problem (1 error)
Error:  -> [Help 1]

The attached snippet renders a gray rectangle on the right side of the tree (e.g. to optional show further information). On Windows, scrolling horizontally works as expected - the gray rectangle stays at the right side. Not so on macOS where it scrolls with the content
TreeSelectionDrawing.java.zip




.

The "lock.notifyAll()" in org.eclipse.swt.widgets.Synchronizer.runAsyncMessages
causes a little overhead of further ~50ms in BenchmarkSwtMultithreading.
When messages have been enqueued for async execution there is no thread waiting anyway.

I enabled the execution of tests on the three "latest" platforms of github:

• Windows: windows-2022
• Linux: ubuntu-20.04
• Mac: macos-11

Unfortunately some of the browser tests fail on these

https://github.com/eclipse-platform/eclipse.platform.swt/runs/6346732956

1 issue that theme have to resolve is that when there are multiple CTabFolders on the same window (eg the workbench), it's not clear which current folder has the focus and which actual tabs has focus. The default CTabFolderRenderer should try to resolve that issue, maybe with some option; by applying some color or border to better identify the current focus in case multiple CTabFolders are shown on the same window.

When i open my eclipse commiter workspace it takes some seconds till everything is shown and i can finally search for a type (ctrl shift T).
I sampled a bit and (beside that the files are refreshed - i understand that need) the longest time (6sec) is spend in
org.eclipse.swt.internal.win32.OS.GetCharacterPlacement[native] ()
inside BidiUtil.resolveTextDirection().

I don't even need any Bidi support so that feels just bad. Is there a way to turn bidi support of or a chance of less costly detection of bidi characters (without native calls for every single character)?

according to the source that bidi feature was added in 2015 https://bugs.eclipse.org/bugs/show_bug.cgi?id=467463
but is only recently used in this context since 2022-04 https://bugs.eclipse.org/bugs/show_bug.cgi?id=579626
@niraj-modi

Please run the attached snippet on Windows 10 and move the mouse over the tree items. The occurring popup a) shows a pink left stripe and b) this hides the begin of the "L"
TreeSelectionDrawing.java.zip



.

The changes made on https://bugs.eclipse.org/bugs/show_bug.cgi?id=565526 caused RTL texts to be rendered incorrectly on TextLayout.

Currently one could only apply a spacing between regions that then applies to all regions directly.

For creating nice layouts it would be useful to control this a bit more fine grained, similar to css the org.eclipse.swt.layout.BorderData should support for a given region:

• paddingLeft
• paddingRight
• paddingTop
• paddingBottom

Please run the attached snippet. It will show the colors reported by the different SWT.COLOR_TITLE_* constants. As you see, they obviously differ from the title color.

TitleColor.txt

Concurrency could be challenging, especially when it comes to UI and responsiveness. And even more with the single-threading model of SWT (and other UI frameworks as well) as one easily could block the UI then.

Java for several year contains some where useful tool with the concurrency framework but it is quite hard for users to interact with that as SWT does not offer some basic primitives (most notable Executors and CompletableFuture.

My proposal is to add some basic glues to allow a seamless integration of SWT with then concurrency framework so allow users more save, modern and easy to use calls into the SWT framework that hopefully leads to less blocking calls as it becomes incredible easy to use.

I have prototypesd such components in the past two years in an RCP application and will contribute some patches to integrate this directly in SWT.

Hi folks, I am transferring this issue from EPP where it was reported (https://bugs.eclipse.org/bugs/show_bug.cgi?id=579816):

There appears to be an issue with HiDPI on Ubuntu 22.04 where (perhaps) there is some bad interaction with built-in scaling and Eclipse's scaling, quoting from the bug:

when I increase resolution and scale on "ubuntu's Displays settings", the application goes blinking and does not work as expected. otherwise, the font is too small to be read.

As SWT has platformspecific code it would be good to check the compile on each of those.

I have started creating one (see https://github.com/laeubi/eclipse.platform.swt/actions/workflows/maven.yml) but running into trouble find out what are the right parameters, I used https://wiki.eclipse.org/SWT/Developer_Guide#Build_SWT but it is not very informative (or I don't understand it) in regards to expected build parameters.

While I can get those from the CI build for linux I had to guess them for mac/windows, but it seems my guess is wrong I always get:

Error: Cannot resolve project dependencies:
Error: You requested to install 'org.eclipse.equinox.p2.iu; org.eclipse.swt.tests.fragments.feature.feature.group 0.0.0' but it could not be found

The buildfile could be found here: https://github.com/laeubi/eclipse.platform.swt/pull/1/files

it creates a matrix and defines the following for each:

• { os: ubuntu-latest, native: gtk.linux.x86_64 }
• { os: windows-latest, native: win32.win32.x86_64 }
• { os: macos-latest, native: cocoa.macosx.x86_64}

what the is passed to the build as -Dnative=${{ matrix.config.native }} but it seems either the id is wrong or I need to setup something for the other environments.

I just learned about this Github feature (https://tech.people-doc.com/using-github-codeowners-file.html). I think it would help a lot if we set it up for SWT per port. My proposal would be:

• GTK - */gtk/ - @sravanlakkimsetti @akurtakov
• Cocoa - */cocoa/ - @lshanmug someoneelse?
• Win32 - */win32/ - @niraj-modi someoneelse?
  What do you think?

Part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=574949. Currently TextTransfer does not work which was tested by using ClipboardExample.

Tracked in #228

All our target platforms are at Gtk 3.22 https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_24.xml#target_environments%20plan so no issue from that side.
Why? In order to start building GTK 4 port officially a builder with Gtk 4.x is needed. CentOS 7.x and 8.x don't have GTK 4 so we have to jump on CentOS Stream 9 which has Gtk 3.24 and newer glib/glibc. Moving to 3.22 now is one step at a time approach to ease migrations by not requiring too big jumps.

This error is caused by calling swt_fixed_remove with fixedHandle == 0. The fix is to check if the widget to be destroyed is a GtkWindow, and then calling the appropriate gtk_window_destroy() call.

Tracked in #228

Originally reported at https://bugs.eclipse.org/bugs/show_bug.cgi?id=573275

I have a mouse up/down event handler but when I hold down [alt] key no event is generated (instead gtk tries to move my window around when I hold the mouse button pressed).

I have enabled os specific tests now, unfortunately the Printer test fails on windows-2022:

https://github.com/eclipse-platform/eclipse.platform.swt/runs/6346732956

java.lang.AssertionError: printer list contains items even though there are no printers expected:<0> but was:<2>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_printing_Printer.test_getPrinterList(Test_org_eclipse_swt_printing_Printer.java:170)

Open "New untitled editor" and paste this exception stack below.
After that put cursor on first line and try to toggle "Word Wrap" in the main toolbar.
Error with the same exception is logged in the log, line numbers disappear from line number ruler.

Same happens with almost every Java editor opened on a non trivial Java file that has longer lines. I haven't found smallest possible text that causes the error yet.

Either some StyledText change broke the editor, or some changes in text framework, I haven't bisected that yet.

Update: to reproduce, editor should have scrollbars and should scroll at least once down and back.
I see it back to 4.19, so regression is somewhere there, 4.18 is OK. OMG.

org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:113)
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:99)
	at org.eclipse.jface.text.Position.<init>(Position.java:65)
	at org.eclipse.jface.text.AbstractDocument.getPositions(AbstractDocument.java:1608)
	at org.eclipse.core.internal.filebuffers.SynchronizableDocument.getPositions(SynchronizableDocument.java:246)
	at org.eclipse.jface.text.source.AnnotationModel.getRegionAnnotationIterator(AnnotationModel.java:716)
	at org.eclipse.jface.text.source.AnnotationModel.getAnnotationIterator(AnnotationModel.java:678)
	at org.eclipse.jface.text.source.AnnotationRulerColumn.doPaint(AnnotationRulerColumn.java:642)
	at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:548)
	at org.eclipse.jface.text.source.AnnotationRulerColumn.lambda$1(AnnotationRulerColumn.java:274)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5794)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1529)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1555)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1538)
	at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3882)
	at org.eclipse.swt.widgets.Scrollable.gtk_draw(Scrollable.java:365)
	at org.eclipse.swt.widgets.Composite.gtk_draw(Composite.java:496)
	at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:174)
	at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2409)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:6832)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:6114)
	at org.eclipse.swt.internal.gtk3.GTK3.gtk_main_do_event(Native Method)
	at org.eclipse.swt.widgets.Display.eventProc(Display.java:1552)
	at org.eclipse.swt.internal.gtk3.GTK3.gtk_main_iteration_do(Native Method)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4474)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1440)

I have ran into an issue on the 2021-09 release where BrowserFunctions are sometimes undefined in the window when using the Edge browser. This looks to be caused by some sort of race condition that occurs when a Browser has BrowserFunctions registered and its URL is set quickly after it is constructed. When more time is added between the construction of the Browser instance and registering browser functions/setting the URL, the error occurs far less frequently. This issue is unique to Edge as the code works without issue when using IE.

From briefly looking over the code and documented changes, this looks to be related to execute(String script) no longer being synchronous when using the Edge browser implementation. When adding a browser function to the window, createFunction(BrowserFunction function) calls nonBlockingExecute(String script) to execute the JS used to define the browser function in the window. The browser's own implementation of execute(String script) is then called to run the script. This then asynchronously adds the browser function to the window.

It might be possible to correct this by adding an override implementation of createFunction(BrowserFunction function) to Edge.java and using a similar strategy as the Edge evaluate(String script) does to wait for the callback to report completion before continuing.
A good alternative would also be adding support for Window.postMessage() as mentioned in the Potential API addons. With asynchronous options being commonly preferred in web development the synchronous behavior of browser functions will likely become harder to maintain and less desired as time goes on.

During #78 is see a hotspots in readAndDispatch for the costly checks for system messages. We could avoid those if we handle multiple internal messages before polling OS again.
To avoid unresponsiveness to OS we could limit that internal message handling to a duration of for example 1ms.

This improves the BenchmarkSwtMultithreading handling from ~ 190ms to ~ 88ms on my Windows computer.
WDYT?
I know it is against the javadoc which clearly states readAndDispatch() will "Reads an event " which sounds like single event.

test_bug493455_drawImageAlpha_srcPos fails on both MAC platforms

See

• https://download.eclipse.org/eclipse/downloads/drops4/I20220406-1800/testresults/html/org.eclipse.swt.tests_ep424I-unit-mac64-java17_macosx.cocoa.x86_64_17.html
• https://download.eclipse.org/eclipse/downloads/drops4/I20220406-1800/testresults/html/org.eclipse.swt.tests_ep424I-unit-macM1-java17_macosx.cocoa.aarch64_17.html

expected:<RGB {0, 255, 0}> but was:<RGB {255, 255, 255}>

java.lang.AssertionError: expected:<RGB {0, 255, 0}> but was:<RGB {255, 255, 255}>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:120)
at org.junit.Assert.assertEquals(Assert.java:146)
at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_graphics_GC.test_bug493455_drawImageAlpha_srcPos(Test_org_eclipse_swt_graphics_GC.java:681)

Originally posted by @iloveeclipse in #12 (comment)

When using the autoscale exact flag, the texts are not blurry and images are scaled more correctly. But you get new problems. Tha damage areas are not correct, so you see artifacts when moving around.
When using draw2d for example:

Or you create custom menus, the do not stop at the end of the screen (position and widths calculations seem to be wrong). Usually the menus are moved to the left that you can read the whole text when reaching the right border of the desktop and there is no monitor further to the right:

Or you get blinking lines between custom drawn tables or on eclipse tooltips:

or you lose your icons again:

So using the exact flag is not solution for the unsufficient swt high dpi support.