Cura: Broken keyboard layout under Wayland

[quasipedia]

Running 3.1.0 on Fedora 27 64bit (Gnome wayland) via Appimage.

Cura simply ignores my keyboard layout. I use Colemak, but when in cura it seems it maps keys to some other layout (a qwerty one, but I wouldn't know which one).

Let me know if you want me to do some further testing.

[alekseisasin]

@quasipedia I am not sure how we can help you in this case. I tried Colemak in Ubuntu and Cura works fine. Probably it is related to the Fedora.

[quasipedia]

I am not sure how we can help you in this case

@alekseisasin - A good starting point would be trying to replicate the issue as described! ;)

I have read on the intertubes that after years of wasting their energy Canonical is finally dropping MIR/Unity in favour of Wayland/Gnome (same as Fedora), but my understanding is that _current_ releases of Ubuntu still run on their own in-house stack, in which case testing in Ubuntu is just worthless, for this bug.

I am by far not an expert on this, but my hunch is that Cura assumes somewhere the presence of (or certain behaviours typical of) XKB, and this - of course - may not be the case with modern, wayland-based systems.

Again: I know close to nothing on the issue, which may perhaps also have to do with the use of Appimages rather than proper packages relying on the system's stack, but in case it helps for inspiration/to see how they don't have the same issue, another FLOSS app offering Appimages, but that has a working keyboard configuration for me is FreeCAD (https://github.com/FreeCAD/FreeCAD/releases).

Again: let me know if you need some further input from my part. :)

[quasipedia]

Indeed, I managed to find a machine running my same system but using X sessions, and the layout works correctly there. I can confirm that Cura is the only Appimage that got this wrong that I know of, so you could copy keyboard management either from FreeCAD (see above) or from Slic3r Prusa edition, both working great (and - BTW - booting in a fraction of the time that takes to Cura).

[alekseisasin]

The bottleneck of your request for now we don't have installed Fedora OS ( Note: yes, it is simple to install, but still takes time), so far as I know. For this reason I don't know how fast we can apply keyboard management (FreeCAD uses C++ for GUI c++ Python for Mods, which is different from Cura) and test it.

[quasipedia]

I understand. It's not a big deal as cura is not really the piece of software where you spend a lot of time typing letters (and numbers - AFAIK - are placed the same in all layouts). Yet, at least from a cursory google search, it seems Ubuntu is switching to Wayland starting 18.04, so the risk is that pretty much all of your linux users will incur into this at that point.

\
You could also do yourself a favour and switch to Fedora permanently, instead of doing it for testing purposes only! :trollface:
\

[Ghostkeeper]

Ubuntu is already on Wayland starting from 17.10, which I use on my work laptop. I'm using US International with Sticky Keys there (and the sticky keys work properly). I suppose I can give it another try with a completely different layout when I'm back at work on Tuesday.

There is also X in there for backwards compatibility though. I don't know which one is used.

[quasipedia]

Thank's @Ghostkeeper! Let me know if you need any other input from my side (as in: testing stuff on my system for diagnostic purposes). Happy new year BTW! 🎉 🎆

[Ghostkeeper]

I switched my keyboard layout to Russian and made a custom profile. It properly named my profile "Цшылш", so that keyboard layout worked.

So maybe it's something specific to Fedora? Or something that Canonical patched?

[awhiemstra]

I just checked this on my personal laptop, which runs Arch with Plasma on Wayland. I can reproduce the keyboard layout issue on that system. @Ghostkeeper did you check the AppImage or running from source?

[quasipedia]

@Ghostkeeper - I am not sure how Russian and British Colemak relate, nor how different charsets and different layouts relate to each other from an implementation perspective. It would be probably helpful to check with my same layout probably (Colemak UK)?

As I said, the problem only occurs with Cura AppImage, other AppImages run just fine, so if I had to pick a specificity, I would look no further than this very repo! ;)

[Ghostkeeper]

I ran from source.

I would've tried Colemak but it doesn't seem to be available for selection in the settings. I tried Polish (which is available) and that seems to work fine as well.

[quasipedia]

@Ghostkeeper - https://colemak.com/Unix (I think it's US Colemak though, while I run UK Colemak). But I think the issue is not necessarily with Colemak, but really with the way the layout is managed in AppImages.

Again: I would suggest you investigate your AppImage pipeline. Chances are you are implicitly relying on some Xorg specific feature that breaks on Wayland. I don't know how your system is set up, but unless "running from source" means statically linking against the same libraries you ship in the AppImages, the two way of running Cura may diverge significantly.

As an additional piece of information (maybe related, maybe not). With Cura 3.1.0 the AppImage started to take forever to load (I averaged 5 seconds for the splash screen to appear and 61 for the actual interface to be shown). Before it was not noticeably slower than any other AppImage I run (a couple of seconds). top shows 100% CPU load (so, single core bottleneck?) and the splash screen spins (very very slowly on "loading machines...").

Again: let me know if there is anything you want me to test for you. :)

[Ghostkeeper]

When running from source, some things are definitely different. The font rendering system is completely different for one. Usually it doesn't matter much.

In this case you're right though. When running the AppImage, the keyboard layout had no effect at all. Russian keyboard layout just created Latin characters. In fact, the dead keys didn't work either with US-Intl + dead keys. Normally I don't notice that because you don't type much text in Cura.

With Cura 3.2 we considerably improved the start-up speed again. Hopefully this time for good. There is indeed a single core bottleneck because we are limited by the CPython GIL.

[Ghostkeeper]

Our project manager shifted this off our planning because no update was made to the ticket for several weeks. We probably won't get around to fixing it soon. Maybe later.

[quasipedia]

Not really sure what the rationale is there. The ticket has already all the information it needed. I could have nagged you more, sure... but what I am hearing is that you prioritise according to "who scream louder", which does not seems very logic, and reinforces bad habits among users...

[speendo]

I seem to have the same problem on Debian with a German Keyboard layout.

[Ghostkeeper]

An approach to fix this sort of thing should be to either:

• not include any keyboard daemon in the AppImage, so that it falls back to the one on the user's OS, or
• include a properly working one that respects the preferences in the user's OS.

The first approach seems much more plausible to me, but I don't know how to exclude the keyboard manager from the AppImage or why it's using a custom one.

[Ghostkeeper]

They seem to have had the same problem in Keepass: https://github.com/keepassxreboot/keepassxc/issues/1439.

They have solved it by including an additional Qt plug-in: https://github.com/keepassxreboot/keepassxc/pull/1534/files#diff-574ff71ed7753249ba0fcb98b4a7a315R66

Only currently we don't build that plug-in yet. We should add that to our cura-build-environment repository then.