I finally have CudaText running native Wayland. Qt offers many environment variables. I tried them to no avail. What finally did the trick was a cli switch:
# not enough:
QT_PLUGIN_PATH="/usr/lib/qt6/plugins"
QT_QPA_PLATFORM_PLUGIN_PATH="/usr/lib/qt6/plugins/platforms"
QT_QPA_PLATFORM="wayland"
# did the trick:
-platform "wayland"
GTK3 in Lazarus 5.0 will do native Wayland for that widget set. I prefer GTK over Qt, but now run Qt6 for Wayland. Lazarus-based Double Commander has this discussion: https://github.com/doublecmd/doublecmd/discussions/1097
The same cli switch runs Double Commander in native Wayland. I like how Double Commander ships libQt6Pas.so.6 out of the box. I wish Cud would do the same. Thanks!
If I understand the question, it asks what is wrong requiring users to download and install the Qt Pascal lib to the sys dir.
* The user must have admin privs; not likely in multiuser (and/or thin client) corporate settings.
* Some Linux distros don't package Qt Pascal libraries. Void only packages qt5pas; no qt6pas exists in Void repos. So the option to install per Linux methods will not help everyone. Even when Linux does package something, it is not always the most recent release.
* The user must know what he is doing. Modifying system libraries is not something normally asked of users.
* System hygiene. I used LD_LIBRARY_PATH in a launch script. Even pro users and devs do not like modifying sys dirs behind the OS.
* Some future Cud version needs an updated lib, but the user thinks he already did the step, so Cud won't work. In other words, the requirement is not one-time. Eventually Qt7 will come. Shipping the lib with Cud makes it always work, out of the box.
* Making the user's life easier, not harder, is good practice, and spreads Cud popularity.
* Bundling the Qt5 and Qt6 Pascal libs with the respective Cud tarballs is almost no added work, just packaging logistics.
* Bundling the lib makes Cud a "portable app" on Linux. Copying the folder to another computer will "just work."