Add support for Copy/Cut/Paste keys

[yaslama]

These keys are present in some old unix keyboards, but more importantly, their keycodes can be mapped to physical keys in modern programmable keyboards.
Using them in Linux is a way to be able to have the same keys for copy/pasting in GUI apps and in terminal apps instead of switching between ctrl-c/ctrl-v and ctrl-shift-c/ctrl-shift-v.

[github-actions]

Test Results

104 files   -    14  104 suites   - 14   6s ⏱️ - 10m 17s
 76 tests  - 4 356   76 ✅  - 4 334  0 💤  - 17  0 ❌  - 5 
223 runs   -    75  223 ✅  -    66  0 💤  -  4  0 ❌  - 5 

Results for commit 1b9667c. ± Comparison against base commit a479377.

This pull request removes 4356 tests.

AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_dollarSign
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_emptyString
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letterA
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16LE_null
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_AsciiLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_Asciiletter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_LotsOfLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letters
…

♻️ This comment has been updated with latest results.

[HeikoKlare]

Some hints on the API errors:

• The @since tag does not use the SWT bundle version but an Eclipse release version. It should be something like 3.132 together with a minor version increment of the SWT bundle and fragments to 3.132 because of the API additions.
• The change is effectively a breaking API change, which is why API tooling complains that a major version increment is required (see "Add API Field" at https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/Evolving-Java-based-APIs-2.md#evolving-api-classes). Since adding such a constant usually does not break any compatibility, it is often accepted even though theoretically breaking API compatibility. In such a case, you need to add an API filter for it. The IDE should show you a quick fix for that at the introduced constants if you have set up your workspace with an Oomph setup as described in the contribution information.

[yaslama]

Thanks @HeikoKlare. I tried to follow your instructions. Can you please check again? The only thing that wasn't clear to me was "together with a minor version increment of the SWT bundle". Thanks!

[HeikoKlare]

The only thing that wasn't clear to me was "together with a minor version increment of the SWT bundle".

Currently the SWT bundle (org.eclipse.swt) and the OS-specific fragments (org.eclipse.swt.gtk.linux.x86_64 and others) are at version 3.131.100. Since this introduces new API, it requires a minor version bump, i.e., a bump to 3.132.0. The according change should look similiar as, e.g., 23befcd.
For "ordinary" changes that require such a version bump, a GitHub bot automatically creates them. So what you could theoretically do is to add any kind of ordinary change that requires a minor version bump, so the according version bump commit gets auto-generated, then fetch that additional commit and revert the original change. But it's probably easier to just do it on your own.

Also note that all my comments are only related to producing a compiling and tooling-compatible state. I have not evaluated the actual change so far, which I am also not fully able to as I am not on Linux. So someone else should have a look on that as well. Another questions is whether this could/should also be extended to the Windows and MacOS implementations.

[yaslama]

Currently the SWT bundle (org.eclipse.swt) and the OS-specific fragments (org.eclipse.swt.gtk.linux.x86_64 and others) are at version 3.131.100. Since this introduces new API, it requires a minor version bump, i.e., a bump to 3.132.0. The according change should look similiar as, e.g., 23befcd.
For "ordinary" changes that require such a version bump, a GitHub bot automatically creates them. So what you could theoretically do is to add any kind of ordinary change that requires a minor version bump, so the according version bump commit gets auto-generated, then fetch that additional commit and revert the original change. But it's probably easier to just do it on your own.

Thanks for the explanation. I just force-pushed a commit with these changes. I hope that it's ok now

[yaslama]

Another questions is whether this could/should also be extended to the Windows and MacOS implementations.

From what I understand, these keys are not supported in Windows/MacOS, but I am no 100% sure as I use only Linux

[yaslama]

@HeikoKlare Do you think that the PR is in a compiling and tooling-compatible state?
Also who can review the actual change? Thanks!

[mickaelistria]

I think the Javadoc should state prominently that those events are currently only supported on GTK.

[yaslama]

@mickaelistria I just added it