Add support for Copy/Cut/Paste keys
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.
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 1b9667c0. ± Comparison against base commit a4793774.
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
…
:recycle: This comment has been updated with latest results.
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!
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., https://github.com/eclipse-platform/eclipse.platform.swt/commit/23befcda0878b2fbc44b215a8d81fe7fe4e58a4b.
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.
Currently the SWT bundle (
org.eclipse.swt) and the OS-specific fragments (org.eclipse.swt.gtk.linux.x86_64and others) are at version3.131.100. Since this introduces new API, it requires a minor version bump, i.e., a bump to3.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
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
@HeikoKlare Do you think that the PR is in a compiling and tooling-compatible state? Also who can review the actual change? Thanks!
I think the Javadoc should state prominently that those events are currently only supported on GTK.
@mickaelistria I just added it