[FEATURE] Added the possibility to hide the frame of the window

[FriscPlusPlus]

Hi!
So I added the possibility to hide the frame of the window. Such feature we have it in basically all frameworks to create desktop apps, and also it is useful in case you would like to make your own bar to have a fully customized UI that integrates with the rest of the style.

API

Windows

In windows hide_frame, I change the window style by calling SetWindowLong and changing the window style to styles that have no border.

GTK (Linux, and BSD)

For gtk what I do is to use gtk_window_set_decorated and simply set the decorated window to false.

macOS

For Mac, it was not this straight forward, as the window has to be created with no frame and can not be changed afterward.
What I did is to create an attribute called m_hide_frame with default value false, if the hide_frame is called it will be set to true, then i when we call create window I check if m_hide_frame is true and if it is, I set the window style to NSWindowStyleMaskBorderless.

I also added the unit test and the created a no_frame test program.

For any change, please let me know and I will work on it asap.

[FriscPlusPlus]

Hi @justjosias, sorry for the tagging, i would like to know if i have to change anything for the PR to get approved!
Thanks and let me know!

[justjosias]

Hey @FriscPlusPlus! Thanks for your contribution. I've approved running tests. The Linux tests are currently failing.

This seems like a potentially useful feature. @SteffenL, do you have any thoughts on this?

[SteffenL]

Thank you for this PR!

While I haven't reviewed the code yet, my first thought is that I would like a way to toggle frame/decoration styles/visibility.

To make this more reusable it might be nice to have a function that sets window decorations using flags. That way one can specify flags to show or hide decorations, show/enable or hide/disable buttons such as minimize, maximize and close, etc.

There's also an existing issue with the way the library initializes itself with default values that may not be the defaults users of the library want. I haven't checked the behavior of this PR. It would be a good idea to think about what happens when users want to hide decorations early, preferably before the window is displayed. Keep in mind that WebView2 takes a bit of time to initialize on Windows, and the window may by default be visible for about a second or more with default appearance (size, decorations, etc).

Any thoughts on that?

[SteffenL]

One more thing to think about regarding "fully customized UI", which I interpret as something like custom decorations within the webview widget, is how to allow the window to be resized, moved, etc, using the mouse and/or keyboard as if native decorations were there and just working.

That's not something that has to be done along with the work in this PR, but something to think about when we're on the topic of customizing the window decorations.

[FriscPlusPlus]

Hi @justjosias and @SteffenL, thanks a lot for running the checks. Is there something I have to do on my side? I checked the error, and it is not fully clear to me. It seems that the last PR also has the same error. @SteffenL I did not try to execute the method once the window is already shown, you are making a good point, I am honestly not sure if it will even work for some platforms. I will test it and come back to you once i ASAP, kinda busy with work this week, it's that time when a new project needs to be started, but the holidays are close, so everyone is freaking out ahaha!

[SteffenL]

I can't immediately tell what's going on with the build error but something has changed since the last commit in master, and has broken future builds. I'll try to take a look at it within the next few days.

[SteffenL]

A fix/workaround for the build issue is now in master.

[MliKiowa]

@SteffenL , I think this feature is very good, but there are still some issues. I wanted to ask if you have any thoughts on this, and whether it’s necessary to push it further.