[FEAT]: Notifications (OSD) always on top

[RunningDead89]

Rules

• [X] I made myself familiar with the README.
• [X] I checked closed issues for similar ones and did not find a similar feature request mentioned before.
• [X] I understand that, if insufficient information was provided, my issue will be closed without an answer.

Version

2.17.0 BETA 3

OS

Windows 11 22H2 Dev Build 23550.1000

Device

Legion 5 Pro 16IAH7H

Is your feature request related to a problem?

I'm quoting here something from the user "ᴅεᴠιℓ'ѕ нυηтєя" from the beta thread in Discord.

He means it would be sick if the OSD-notifications were always on top regardless which app/game is running.

As this isn't beta relevant, I advised him to post this here. However he doesn't yet so i post it.

How would you like the problem to be solved?

The OSD-notifications from dis- or enabling touchpad, capslock, numpad, etc. should be always on top of any app, so they are visible in any app/game. At least it would be nice to have an option for this to decide for yourself if you want to have the notification always on top or in background to see it ingame or not.

What alternatives have you considered?

---

Additional information

[BartoszCichecki]

Thanks for reporting. Currently, the notification is a "window" in terms of how windows sees it, which is not show while in windowed-fullscreen mode to avoid issue with taking away the focus from the app that is in full screen.

This can be probably worked around with GDI+, but I am not that proficient with it to provide a good solution.

[Ace-Radom]

TBH, this is a really tricky one. A Form can be created without taking focus from others, but the thing is as far as I know, Windows doesn't provide a public super-topmost flag for creating window. Once a window gain topmost state, other windows won't be shown even if TopMost flag has been set. Raymond Chen also explained why in this article.

So we need to try sth different. We can hook the OSD into graphics APIs, or we need to dig out some private APIs Windows uses. I'm working on this but I don't know if I'm able to do that & how long it would take. If there's any new progress I'll let u know.

Plus: even if I'm able to achieve that, the OSD definitely won't look so nice, and all texts would be removed due to techical issues with GDI+. But there's no way to keep a nice-looking Form AoT in any case, as I said.

[Ace-Radom]

Okay I know how to do that in C++...Will find some bitmaps for the OSD and port my code from C++ to C#.

[BartoszCichecki]

Great, ideally that would be an option in Notification settings, something like "Always on top". IF we could render the existing NotificationWindow into a bitmap (it is possible I think with WPF to render a view into a bitmap) and just show that bitmap using GDI that would be ideal. If not, let's see what options we have.

[BartoszCichecki]

PS: but if you prepare the code for drawing bitmaps with GDI, I can take care of the "WPF" part.

[Ace-Radom]

Great, ideally that would be an option in Notification settings, something like "Always on top". IF we could render the existing NotificationWindow into a bitmap (it is possible I think with WPF to render a view into a bitmap) and just show that bitmap using GDI that would be ideal. If not, let's see what options we have.

That would be nice. I'll first make this GDI-drawn OSD useable, and then we can see if we could make it same as the OSD we have for now.

[Ace-Radom]

@BartoszCichecki Can u accept that the AoT OSD class is written in C++ and wrapped to C# through CLI? It uses too many native methods & I'm not so proficient in P/Invoke, sth like memory pin I don't know a lot.

It's just a question, writting these function in C++/CLI is way easier for me, but if u think all codes must be kept in C# I'll still try my best to port them.

[BartoszCichecki]

Yeah, sure, I might just migrate it to P/Invoke later if needed.