-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
env: Pass through locale & IM stuff #105
Conversation
c351db4
to
aefe126
Compare
LGTM, but please address @teohhanhui suggestion. |
Leaving the default C locale can break stuff that expect UTF-8, so pass through all the locale env vars and set a default C.UTF-8 locale if nothing is set. For input methods, it turns out that the old legacy XIM does work with our X11 passthrough solution (direct GTK/QT plugin methods will not, since they use side-channels to communicate with the IM server). So, force xim usage for GTK2/3 and QT4/5, which actually works with Steam (!) for CJK input if the system is configured properly. The future is Wayland protocols, which will work with GTK4 and QT6 once we have Wayland passthrough. Hopefully that means we never have to support input methods with the shared library mechanisms, which means our rootfs will never have to include IM-specific libraries and the input method user choice will happen entirely outside of muvm. Signed-off-by: Asahi Lina <[email protected]>
aefe126
to
1b1384b
Compare
Sorted. |
@WhatAmISupposedToPutHere had a commit in #54 to just pass almost everything through, required for binfmt to work seamlessly. Should we merge that one instead? |
Sure, maybe we should merge just that commit for now? @WhatAmISupposedToPutHere what do you think? I can rebase this PR on just that one commit and then add the xim / extra locale handling on top. |
Feel free to use that one. Sorry for getting distracted with shinier stuff and leaving that branch as is, it is somewhere on the yak stack and i will get back to it one day. |
That kinda makes me nervous. Haha... The chances of some software misbehaving and messing up something in the user's home directory seems non-negligible? |
I do not think it is that likely, most /home contents are arch-independent, and we already allow writing there. |
TBH I don't see how the situation is different from today. Env vars aren't particularly special..? |
Turns out I can't cherry-pick that commit cleanly since it's passing through all env vars to the process handler, it doesn't do it to the VM itself... and that whole idea depends on earlier commits. Maybe we can just merge this one for now? |
Ack, let's merge this one and work later on #54 |
Leaving the default C locale can break stuff that expect UTF-8, so pass through all the locale env vars and set a default C.UTF-8 locale if nothing is set.
For input methods, it turns out that the old legacy XIM does work with our X11 passthrough solution (direct GTK/QT plugin methods will not, since they use side-channels to communicate with the IM server). So, force xim usage for GTK2/3 and QT4/5, which actually works with Steam (!) for CJK input if the system is configured properly.
The future is Wayland protocols, which will work with GTK4 and QT6 once we have Wayland passthrough. Hopefully that means we never have to support input methods with the shared library mechanisms, which means our rootfs will never have to include IM-specific libraries and the input method user choice will happen entirely outside of muvm.