https://bugs.kde.org/show_bug.cgi?id=506095
--- Comment #5 from gray-aids-sw...@duck.com --- # Remarks Simply concluding that "it doesn't work" with applications running via XWayland and leaving it at that is an act of abandoning a permanent hardship. Therefore, I will add some workarounds. # Ways 1. Migrate to Wayland This is a desirable option for the future. In practice, if the application is based on Electron, it can be resolved by using OzonePlatform and similar methods. 2. Modify the application's source code to support Wayland In theory and principle, this is possible. However, it takes time. 3. Temporarily switch to X11 This is based on the assumption that, since Fcitx5 can handle X11 natively, switching to X11 may resolve the issue. 4. Launch Fcitx5 as a standalone process only for applications running via XWayland This is possible, but it is not suitable for multitasking. Incidentally, when switching back to the Wayland environment, you need to first kill the standalone version, then turn off the virtual keyboard from the KDE Plasma settings app, switch to "Fcitx5 Wayland", and finally open the input method settings — this resolves the issue. The logic behind this is unclear, but it actually works. Why simply opening the input method settings automatically launches Fcitx5 is unknown, but it is likely a reset triggered by the virtual keyboard change. 5. Switch to the GitHub master version (untested) It is unknown whether anything will change by using the master version. However, there is a possibility that the issue is resolved in the master version. This is not an assumption but a speculation. 6. Use copy and paste In KDE Plasma, some widgets (such as the search bar) allow text input. You can open such a widget temporarily using a shortcut key, input the desired text there, copy it, close the widget, return focus to the target application, and paste the text — this is a realistically feasible procedure. This is the exact method I personally use. It is the simplest and most realistic one — though it is laborious and stressful. 7. While temporarily resolving the issue using one of the above methods, continue investigating the root cause and contribute to the KWin development team, thereby accelerating the solution What is critically important is this: even if we complain, it contributes nothing to solving the problem. I myself have never seen the KWin source code; I simply inferred the root of the issue at low cost by gathering various pieces of information. Only the KWin developers — those who know the source code and can efficiently trace and fix the logic — can actually perform the fix. Therefore, wouldn't it be most desirable for us to provide those developers with information gained through trial and error in real usage scenarios, as our current contribution? # Remarks To add a supplement to this: the UX is significantly degraded, so this is truly undesirable. It is reasonable to conclude that this is something that **needs to be resolved**. The existence of workarounds must not justify leaving the problem unaddressed. Workarounds are not solutions — and problems exist in order to be solved. Issues and bugs are **never** merely items on a to-do list. This is important. -- You are receiving this mail because: You are watching all bug changes.
