[Wayland Qt5 build] Pasting non-basic ASCII chars from some apps to CudaText doesn't work properly

[pintassilgo]

I use openSUSE Tumbleweed (bleeding edge rolling release) with Wayland.

If I copy a string containing only chars from basic ASCII table it works, like letters and numbers. But if I copy a symbol which is not part of the table, the pasted content is not correctly represented in CudaText depending on the app it was copied from. Examples:

• "Euro: €", copying this string from Firefox (Wayland by MOZ_ENABLE_WAYLAND=1) and pasting to CudaText produces "Euro: \u20ac".
• "coração" copying this from Firefox Wayland to CudaText produces "cora??o".

CudaText document is using UTF-8 encoding.

Depending on the origin app, it works. For instance, it's not an issue if I copy from Kate to CudaText. But I never had such issue copying from Firefox to anything else, that's why I believe it's CudaText/Lararus fault.

I use CudaText Qt5 because I use KDE Plasma.

If I start CudaText as a XWayland window instead of Wayland by running QT_QPA_PLATFORM=xcb ./cudatext then I can't reproduce the issue but others appear, for instance my compose keys don't work in XWayland. Supposing CudaText supports Wayland, I shouldn't use XWayland anyway.

Edit: I just tried CudaText Gtk2 and results are the same as running CudaText Qt5 as a XWayland window: pasting from Firefox works but has other issues e.g. my compose keys don't work. Firefox, for instance, is also a GTK app and my compose keys work fine in it.

[Alexey-T]

Can you repeat it with Lazarus IDE (can be installed by 2 clicks from fpcUpDeluxe)? Better use “trunk” Ide version.

[TTomas]

Do you check LC_ALL & LANG environment variables?
I have some problems when LC_ALL=C with some non ASCII chars.
LC_ALL=en_US.UTF-8 solve the problem.

[Alexey-T]

@pintassilgo Maybe @TTomas 's advice can help you?

[pintassilgo]

Those env are correct on my side.

As I said in #4996, turns out this is another bug affecting only the Qt5 build of CudaText. GTK2 is not affected.

I said in my initial comment the GTK2 build had issue with Compose keys not working, but I managed to fix that, it's not CudaText fault, it's just that GTK2 apps don't follow ~/.XCompose by default, so I need to set GTK_IM_MODULE=xim (after making sure to have xim installed, which in case of my distro openSUSE Tumbleweed is provided by the gtk2-immodule-xim package).

I can just use GTK2 CudaText and both this and #4996 go away. But you should know the Qt5 build suffers from at least these two bugs. I was using Qt5 because I use KDE Plasma and also because GTK2 is no longer maintained. But while the Qt5 build can't fix these issues I'll have to use GTK2 CudaText.

[pintassilgo]

One thing I just noticed that may help to find the root of the issue and the fix:

• I copy this char from Firefox Wayland: €

If I try to paste it in Qt5 CudaText, I get different results depending on the focused field:

• Editor: \u20ac (wrong)
• Options Editor Lite Filter field: \u20ac (wrong)
• Options Editor... Filter field: € (right!)

So why the Filter input in Options Editor plugin (v2.3.15) isn't affected by this bug? It's doing something right that other text fields like Options Editor Lite Filter do wrong. Cuda main editor is also wrong...

What's the difference in implementation of Options Editor "Field" input compared to Options Editor Lite "Field" input? The fix is probably there! Options Editor is the one doing it right.

[Alexey-T]

Options Editor (not Lite) has NATIVE input field, native to Qt5. While 'Lite' plugin has ATSynEdit-based (core of CudaText) input field.

[pintassilgo]

So native input field is right. On the other hand, ATSynEdit-based input field has something that is disturbing and causing this bug in the Qt5 build...

[Alexey-T]

ATSynEdit is using the OnUTF8KeyPress to get chars, and it delivers wrong text.

[pintassilgo]

I'll leave this here because I guess it's a related issue:

The default hotkey to open console, Ctrl+`, works for me on GTK build but not on Qt5, at least in a Wayland session.

I believe it's also related to #5002 which was indirectly fixed. I believe the issue is that ATSynEdit doesn't recognize dead keys, at least under some conditions.

[Alexey-T]

Do you paste via hotkey Ctrl+V or middle-click or both?

[pintassilgo]

Ctrl+V, but using right click > Paste has the exact same results.

I leave mouse_middle_click in its default 1 (show autoscroll circle button, not paste). And system-wise I disable middle-click pasting.

Despite Linux having two clipboard buffers and defaulting to copy on selection, I disable all of this because I'm used to be a Windows user, so I want to have just a single unified clipboard buffer and I don't like autocopy on selection.

[Alexey-T]

Laz developer made a fix. let's test.

http://uvviewsoft.com/c/

[pintassilgo]

Build is corrupted, can't launch:

Access violation.

Press OK to ignore and risk data corruption.
Press Abort to kill the program.

[Alexey-T]

Updated the beta. (I reinstalled the Laz)

[pintassilgo]

Still corrupted, unfortunately. Can't launch Cuda.

The same message from previous comment. Console also shows this:

[FORMS.PP] ExceptionOccurred 
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $000000000072CFBD
  $000000000072C36A
  $00000000007F2B78
  $0000000000674EEC
  $0000000000684550
  $0000000000689698
  $0000000000689EB8
  $00000000006814CB
  $00000000006892CE
  $000000000067DFA2
  $000000000068A486
  $0000000000901797
  $000000000067CF51
  $000000000067CA70
  $000000000067C0E7
  $000000000067D710
  $000000000067CB76

[Alexey-T]

I see the error IF I run it from portable dir. I will test now, before I send it again.

[Alexey-T]

Beta updated, same URL

[pintassilgo]

Now I can launch, but the issue wasn't fixed, same results. The native Qt5 dialog from Options Editor is the only input field (from the ones I tested) pasting € instead of \u20ac, pasting coração instead of cora??o and so on...

[Alexey-T]

Laz developer said that he has no time for qt5+wayland testing, and recommended to make qt6 build (qt6 is more optimized for wayland). in the next days, I may prepare the qt6 build.

[Alexey-T]

It seems my main PC with Ubuntu 20.04 cannot install Qt6
https://doc.qt.io/qt-6/linux.html
so if somebody can help to build Qt6 versions (Qt6 widgetset is in the 'trunk' of Lazarus), it's welcome.
@veksha are you interested?

[veksha]

@veksha are you interested?

not this week. sorry.

[Alexey-T]

I can now compile qt6 build, linux x64.
binary only:
cudatext.zip

See about libqt6pas!
https://wiki.freepascal.org/CudaText#Linux:_Qt5_and_Qt6_builds

@pintassilgo Pls try it.

[pintassilgo]

Thanks, but unfortunately same results, not fixed.

[pintassilgo]

I don't know technically, but for me it doesn't seem to be Qt5/6 issue, as we already know native Qt5 input field is not affected by this issue.

Also I have many Qt5 apps not affected, including Kate.

[Alexey-T]

@pintassilgo @veksha
after this IDE fix
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/11f4629097cb6370578d6c3f9d5974cee81465d5
let's test - situation changed?

qt5 binary 'cudatext', ver 1.198.
cudatext.zip

[pintassilgo]

Yes! I can confirm current release v1.198.0.0 still has the issue in Qt build on Wayland session, but the build above is not affected.

[Alexey-T]

Thanks for testing. Next Cud version will have this fix.