Open nicolamori opened 10 months ago
I am having this issue on wayland under void linux on eclipse 2023-09
I confirm this issue on Ubuntu 23.10, Eclipse CDT 2023-12, with OpenJDK 21.0.1+12. Del key repeat works well in a Xorg session.
This is the last problem preventing me from switching to Wayland.
Where should that GDK_BACKEND=x11
be set?
In eclipse.ini
? Or where?
Where should that
GDK_BACKEND=x11
be set? Ineclipse.ini
? Or where?
It should be set as an environment variable. See this AskUbuntu question and answers for a few different ways to set it: https://askubuntu.com/q/144968/6537
I'm experiencing the same bug under X11 in dbeaver. (See https://github.com/dbeaver/dbeaver/issues/22581.) Obviously, setting GDK_BACKEND=x11
doesn't help. Assuming it's the same bug, this bug is not specific to Wayland. The other possibility is two different bugs both breaking the delete key in the same way.
I'm seeing this same issue on Fedora 39 and also saw it on F38 as well. Unfortunately, if I set GDK_BACKEND=x11 before starting eclipse, then I see this weird keyboard behavior such that, as I type characters every now and then the cursor will backup and delete the last character or two that I just typed, and then re-type them and then proceed like normal. I don't end up losing typed characters, but it is really annoying and just unacceptable to run that way.
Describe the bug In a Wayland session, holding the delete key does not produce repeated delete action in any editor. Other keys work fine. In other text element, e.g. search box, the delete key repeat functionality works.
To Reproduce
GDK_BACKEND
env variable tox11
Expected behavior Characters are continued to be deleted as long as the key is held.
Environment:
Select the platform(s) on which the behavior is seen:
Additional OS info (e.g. OS version, Linux Desktop, etc) ArchLinux with Plasma desktop and Wayland session
JRE/JDK version OpenJDK 21.u35 (ArchLinux package jre-openjdk 21.u35-8 from official repositories)
Version since Verified with 4.30.0, first reported on 4.10 (see below)
Workaround (or) Additional context Setting
GDK_BACKEND=x11
fixes the issue Original bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=544518