[DisplayServer] Add method to check if window transparency is supported and enabled.

[bruvzg]

Adds method to check is transparency is usable, see #91333

[LunarTides]

To me, "is_window_transparency_enabled" reads like "is_window_transparency_currently_enabled" which might cause confusion. Maybe rename it to something like "is_window_transparency_supported"?

[Riteo]

is_window_transparency_supported

The issue with this proposal is, IMO, that it clashes a bit too much with DisplayServer::has_feature. I guess that, in a way, it is "currently" enabled.

Perhaps is_window_transparency_available would be a good middle-ground? It still feels a bit conflicting with DisplayServer::has_feature(FEATURE_WINDOW_TRANSPARENCY) but not as much.

[LunarTides]

I guess that, in a way, it is "currently" enabled.

I am not exactly sure how the display server handles transparency, but based on its name and description in the documentation: "Returns true if the window background can be made transparent", it seems like more of a "is this feature supported/available" rather than "is this feature enabled". Or at least it would seem that way had I looked at its documentation, although I may be misunderstanding what this function is for, or maybe the phrasing is just throwing me off.

Edit: On second thought, I think this is just a phrasing issue. English is not my native language, so it was hard to understand. But I still think it should be renamed for clarity.

[akien-mga]

Thanks!

[RandomShaper]

I know I'm late, but I'd like to support the idea of this being checked via has_feature(FEATURE_WINDOW_TRANSPARENCY).

I'm aware the new function added here checks if both supported and enabled. However, that's something that projects could check anyway via has_feature() and the display/window/per_pixel_transparency/allowed project setting.

If this new function is really important as a shortcut (which I'm not very sure about), it could be implemented in such terms.

[Riteo]

@RandomShaper I like that idea too! The only issue is that, IMO, the use of that method is a bit ambiguous.

I think that DisplayServer::has_feature is supposed to fetch only "compile-time enabled" features, a bit like with other engine features, so it would not be a good fit for that, but that's my interpretation.

[RandomShaper]

That's indeed how it's being used at the moment for the most part. However, the method is not described as not able to perform checks at runtime. DisplayServerWeb is an example of something we already have that isn't following such a constraint, by making runtime checks for features such as FEATURE_IME.

We could maybe specify the method as being runtime-constant (instead of compile-time constant).

[Riteo]

DisplayServerWeb is an example of something we already have that isn't following such a constraint, by making runtime checks for features such as FEATURE_IME.

Oh wow, I didn't know that. TBH, I'd be in favour. There are already a bunch other "dynamic" features that come to mind, especially for the Wayland platform, which is build extensively on global objects that theoretically could disappear and reappear at any moment.