Feature/language flyout

[bropines]

Summary

Added the Language Flyout feature

Motivation

I just wanted the flyout to appear when the keyboard layout is changed as well.

Closes #607 #83

Type of Change

• Feature
• Bug fix
• Refactor (no functional changes)
• Style (formatting, naming)
• Other

What Changed

• Developed the Language Flyout itself
• Added to the settings
• Translated into two languages at once: Ru and En
• The system language uses the system's primary color; for other languages, the HUE offset is applied relative to the primary color.

Additional Information

---

Checklist

• Code changes are manually tested and working.
• Formatting and naming are consistent with the project.
• Self-review of changes is done.

• AI tools were used (if yes, I reviewed and fully understand the changes myself).

[bropines]

Slightly updated the animations, made the dimensions static, and increased the smoothness

[unchihugo]

Hi @bropines, thanks for the contribution.

Instead of creating a new Window, I think we should re-use the LockWindow. This is because functionality wise (looking at the code) and design wise, the new window shares basically the exact same purpose/code as LockWindow. Also, new WPF windows take a lot of RAM if hardware acceleration is on, and if we re-use LockWindow, we would eliminate that extra usage from initializing new windows.

[bropines]

Hi @bropines, thanks for the contribution.

Instead of creating a new Window, I think we should re-use the LockWindow. This is because functionality wise (looking at the code) and design wise, the new window shares basically the exact same purpose/code as LockWindow. Also, new WPF windows take a lot of RAM if hardware acceleration is on, and if we re-use LockWindow, we would eliminate that extra usage from initializing new windows.

Thanks for your answer. Yes, in general I realized that it is better to use ready-made windows instead of generating new ones. I did as you asked and tested. I ALSO put the logic into a separate file LockWindow.Language.cs and imported it as a class. Unfortunately, I have little experience in animation (and Gemini is crap), and I think it turned out janky. If you can do better, I'll be glad

[bropines]

I also don’t understand how to normally intercept win+space... If in alt+shift(ctrl+shift) it intercepts every press of shift, then in win+space it only intercepts the release of both keys

[bropines]

@unchihugo I think I updated the code based on your comments...

[unchihugo]

Hi @bropines, thanks for keeping up the changes. Before we can start finalizing the feature, I believe that there are a lot of changes unrelated to the scope of this PR that make it difficult to continue, for example:

1. WindowHelper code changes that aren't really relevant to the PR. They could be addressed in another PR.
2. The new FluentFlyoutWPF/Windows/LockWindow.Language.cs file has functionality that weren't discussed in the PR and add considerable amount of code, like the color system.
3. A lot of changes in LockWindow.xaml.cs that weren't discussed before and are unrelated to the PR as well.

Please be aware that while AI assistance is utilized for code submission, my review process is conducted manually. The inclusion of unrelated changes in pull requests complicates the review and makes it more challenging to focus on the intended improvements.

[bropines]

Hi @bropines, thanks for keeping up the changes. Before we can start finalizing the feature, I believe that there are a lot of changes unrelated to the scope of this PR that make it difficult to continue, for example:

1. WindowHelper code changes that aren't really relevant to the PR. They could be addressed in another PR.
2. The new FluentFlyoutWPF/Windows/LockWindow.Language.cs file has functionality that weren't discussed in the PR and add considerable amount of code, like the color system.
3. A lot of changes in LockWindow.xaml.cs that weren't discussed before and are unrelated to the PR as well.

Please be aware that while AI assistance is utilized for code submission, my review process is conducted manually. The inclusion of unrelated changes in pull requests complicates the review and makes it more challenging to focus on the intended improvements.

Based on my experience with Python, I’m used to writing all the logic from scratch in order to depend as little as possible on maintainers (in 90% of cases, the libraries did not have important functions that the community has been asking for for a long time). But since I want this module to become part of the project, I will remove unnecessary parts of the code, making it more dependent. Sorry, I'll clean everything today

[unchihugo]

No worries! Thanks for clearing that up, I totally get where you're coming from.

[bropines]

No worries! Thanks for clearing that up, I totally get where you're coming from.

Together with AI, we stripped out all the unnecessary changes and rebased everything cleanly on top of upstream to keep our diff as minimal as possible. Everything is working as expected now. I kinda lost the battle with the animations, but I'm sure you will be able to polish them up even better...

[unchihugo]

Hi @bropines, looks much better now. Looking at MainWindow, instead of polling every 75ms and listening to Alt + Space, we can actually swap to listen to the WM_INPUTLANGCHANGE message (0x0051) in the following method:

FluentFlyout/FluentFlyoutWPF/MainWindow.xaml.cs

Line 1515 in 9fa7448

private nint WndProc(nint hwnd, int msg, nint wParam, nint lParam, ref bool handled)

This will be similar to how we detect media or volume changes in newer versions.

You can then display the language change that way instead of listening to Alt + Space or a timer!

[bropines]

I changed it to a system listener. It works less efficiently when switching languages quickly, but I think this is an unnecessary feature to regulate for quick switching. Thanks for the tip. I was looking for such a feature before, but it seems I wasn't looking for it correctly.

[unchihugo]

Looks much better now! Just a question: during testing, have you seen if the code below is redundant?

https://github.com/unchihugo/FluentFlyout/pull/737/changes#diff-1dc2a643641d41f9375d1d0eaccc42727996fa317cc8a151618c7f81d682978aR860-R879

The detection in WndProc() might be enough already, and doesn't require checking the foreground window, which would also remove the need for new native methods.

Please let me know!

[bropines]

The detection in WndProc() might be enough already, and doesn't require checking the foreground window, which would also remove the need for new native methods.

I tested removing it, but unfortunately Windows only sends WM_INPUTLANGCHANGE directly to the active window that currently has keyboard focus (like Chrome or Notepad). Since MainWindow is a background window, WndProc() alone doesn't receive layout change messages from other applications. The lightweight check in HookProc is necessary so it triggers whenever the input layout changes anywhere in Windows.

Gemini and I tried to simplify the logic as much as possible. If you have any ideas on how to implement this differently, I'm ready to make changes.

[unchihugo]

I tested removing it, but unfortunately Windows only sends WM_INPUTLANGCHANGE directly to the active window that currently has keyboard focus (like Chrome or Notepad).

Interesting, thanks for testing it out.

If the code is currently only checking after Win + Space is pressed, you should also include the other keybinds:

Ctrl + Shift and Left Alt + Shift are the most important ones, I don't think anyone would use ` to change language.

[bropines]

Ctrl + Shift and Left Alt + Shift are the most important ones, I don't think anyone would use ` to change language.

The current implementation isn't bound to specific shortcuts (like Win + Space). Instead, it checks if the active input layout (hkl) has actually changed for the foreground window whenever key events occur.

This means it automatically supports all layout switching shortcuts — including Ctrl + Shift, Left Alt + Shift, Win + Space, or any custom keybind — without needing to hardcode specific key combinations!

msedge_Sycc1beCmq.mp4

[unchihugo]

Sorry, you're right about that, as the code is simply comparing the keyboard layout to the previous recorded state. Thanks for demonstrating.

For maintainability, I think we will definitely need to look into sharing methods between LockWindow.Langage.cs and LockWindow.xaml.cs, so we don't have functions like animations in two separate files. I'll look into this.

[bropines]

Sorry, you're right about that, as the code is simply comparing the keyboard layout to the previous recorded state. Thanks for demonstrating.

For maintainability, I think we will definitely need to look into sharing methods between LockWindow.Langage.cs and LockWindow.xaml.cs, so we don't have functions like animations in two separate files. I'll look into this.

Regarding the animations...

A while ago, I was looking for a more "stable" way to adapt to different language names. The problem is that some language names (and regions, if displayed) are quite long, so they overflow beyond the standard bounds I originally tested against:

• |Russian (Russia)__________|
• |English (United States)___|

If I just set the flyout to its maximum size, there’s too much empty whitespace and it ruins the aesthetics.

I also couldn't figure out how to transition cleanly and smoothly between language codes like "RU" and "EN"... I'm honestly terrible at animations :)

Other than that, I think you'll be much better at adapting this to your project's code style than I am. Thanks for the review!