Prevent error at creating Control nodes in threads

[KoBeWi]

This PR makes the Control skip theme cache initialization if it's created in a thread. The theme properties are not accessible anyway, so I think it's fine if they are not correct. We could maybe document that accessing theme in thread is not possible (but other properties should be fine).

Fixes #77764

[YuriSizov]

I don't think it's appropriate to allow creating incorrectly initialized GUI nodes under specific conditions. As far as I understand Juan, Control nodes are not supported outside of the main thread. So adding workarounds here just to suppress valid errors is wrong. It's also completely hidden from the user.

The theme properties are not accessible anyway

They are, from the project theme and from the default theme.

[KoBeWi]

I mean they are not accessible from the thread, because you will get the error that this PR prevents. The problem was that the blocked methods were called automatically, beyond user control.

[YuriSizov]

It's a part of the initialization logic, it's not supposed to be within user's control. It's there to ensure that nodes are correct and can be used. Same thing can happen with any other methods of GUI nodes during the initialization step. If GUI API is not supported in threads, then we should not expect the creation of such nodes to be allowed either.

I mean they are not accessible from the thread, because you will get the error

That said, I don't see why this shouldn't work from threads in principle.

[RandomShaper]

I don't think it's appropriate to allow creating incorrectly initialized GUI nodes under specific conditions. As far as I understand Juan, Control nodes are not supported outside of the main thread.

I think that's accurate.

That said, I don't see why this shouldn't work from threads in principle.

The problem is that the Control is caching stuff. If we allow a node to be written to within group (threaded) processing, the code must be updated for proper sync. For an example, see Node2D::_is_xform_dirty() and pull the thread from there.

[YuriSizov]

The problem is that the Control is caching stuff. If we allow a node to be written to within group (threaded) processing, the code must be updated for proper sync. For an example, see Node2D::_is_xform_dirty() and pull the thread from there.

Hmm, I see. Yes, theme property getters have a cache and can write to it in some cases. So these operations would need to be remade with MT in mind, and then calling get_theme_xxx from a thread should be possible?

As far as I understand, the biggest concern with threads in controls is computing sizing, and these methods aren't related to that.

[RandomShaper]

That's right.

However, my take is to keep GUI single-threaded for the time being, since, as you can see, otherwise the implications can start to grow big and we're not even done with adapting the elements that need it for the main use to MT.

I'm pretty sure @reduz's design choice also matches this idea.

[KoBeWi]

Closing in favor of #78000
It allows the user to intentionally enable unsafe code, and more importantly also fixes the error, so it's better.