-
Notifications
You must be signed in to change notification settings - Fork 36
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
feat: language provider (windows only) #85
feat: language provider (windows only) #85
Conversation
Ay this is awesome, thank you 🙏 A big improvement that could be made is removing the interval altogether and instead listening to Re. |
packages/client-api/src/providers/language/create-language-provider.ts
Outdated
Show resolved
Hide resolved
I'll give it a try when I find some more time, hopefully this weekend :) Re pnpm dev, it was a bit of a user error (guess I can't read above headlines :) ), just noticed that git bash or wsl was required, and I was using powershell. Now it kind of works, although no providers seems to work, getting the error below for all of them (I assume all of them at least), can't get any of the default providers in "group/right" to work. This also happens if I try to run it from main. Want me to move the "problem discussion" to an issue, to not clutter the PR further? :) |
fixed cfg(windows) in variables fixed copy paste typos in create-language-provider
Ah thanks for catching this - was a regression introduced by a recent refactor. There's a fix in |
It does seem like the WM_INPUTLANGCHANGE only is being sent to the focused window and then it's being swallowed. If I create a visible window and do a language change, the message is received. But regardless of what I seem to do, I can't get it to be sent to a background window. So not sure how to proceed, other than cleaning up my polling version or wait for someone that might know the windows api intricacies better than me to figure it out. I tried to listen for the WM_INPUTLANGCHANGE in the glzr code base as well with the same result. |
Damn, that sucks. Most From an SO post, there's a more reliable alternative via COM:
There's actually one example of using #[implement(
Windows::Win32::UI::TextServices::ITfLanguageProfileNotifySink
)]
struct LanguageProfileNotifySink {
lang_change_tx: mpsc::Sender<u16>,
}
#[allow(non_snake_case)]
impl LanguageProfileNotifySink {
fn new() -> (Self, mpsc::Receiver<u16>) {
let (lang_change_tx, lang_change_rx) = mpsc::channel::<u16>(1);
(Self { lang_change_tx }, lang_change_rx) // listen to the returned `lang_change_rx` in the provider
}
fn OnLanguageChange(&self, _langid: u16) -> windows::core::Result<BOOL> {
Ok(true.into())
}
fn OnLanguageChanged(&self) -> ::windows::core::Result<()> {
self.lang_change_tx.send(0).unwrap();
Ok(())
}
} COM is used extensively within Tauri, so it should be totally fine to use in this case |
I've tried implementing it using the ITfLanguageProfileNotifySink, but haven't been able to get it to work with zebar, I did make a small application where I've gotten it to work, but it seems to have the same issue as the WM_INPUTLANGCHANGE event, it's only sent to the application in focus. According to this, it seems like that's how it's supposed to be. https://stackoverflow.com/questions/74468291/itflanguageprofilenotifysinkonlanguagechange-only-reporting-when-the-window-is Doesn't seem like this feature can be done in a nice way unfortunately. |
replaced with #[cfg(windows)]
That's super unfortunate that Just a heads up, I'm working on a v2 rework of Zebar currently. There'll be a bunch of merge conflicts once it's merged (#99) - you cool with me committing to your branch directly to fix these up afterwards? One other thing is I'm keen to rename the provider + variable from |
You can modify and change it however you like. :) I should have fixed the compilation error for arm64-windows (the workflow that failed) |
Provider for getting current OS language and keyboard language.
Only Windows support, developed the same thing for the c# version of glazewm.
Haven't been able to run it,
pnpm dev
fails with the error below. So it's untested.