feat: QQmlExtensionPlugin::initialize_engine

[rubdos]

This introduces initialize_engine, such that plugins can register e.g. image providers (might file a PR for that too, but I've been using that with cpp! macros for now for a long time). These need access to the engine, and that can be done through this "callback".

This is 100% unsound, and doesn't compile (because Rust QmlEngine != C++ QQmlEngine etc), but filing to start the discussion. The problem is that QmlEngine, the Rust side, assumes ownership of the pointer. We could leak the pointer after using it, but if we then panic in the initializeEngine override, the pointer will get cleaned up. It's not ideal, and would love some suggestions.

GPT 5.4 suggests introducing a QmlEngineRef type, but that gets ugly quite fast because you need to duplicate all the methods (or break interface and call AsRef all the time), and it just doesn't feel right. Maybe we can track an "owned" flag in the struct, but that neither feels great. Any ideas, @ratijas / @ogoffart ?

[ogoffart]

Perhaps it would help to also have example/tests to see how this is meant to be used.

I'd say there could be a ManualyDrop<QQmlEngine> and only pass references to it, or something like that so that the Rust code doesn't take ownership, and only pass `&QQmlEngine from the function

IMHO all the function on QQmlEngine should probably take &self anyway instead of &mut self that was a design mistake as i didn't understand rust when i did that.

[rubdos]

I think the main problem here is that in a QQmlExtensionPlugin, we just don't have the QApplication/QQuickView to pass around, so we can't even construct the QmlEngineHolder / QmlEngine. Creating the additional QQmlEngine wrapper will make it more confusing...

Is it worth to break API (since we were talking about that anyway), and to rename Rust's QmlEngine to "QmlEngineApplication" or "QmlEngineHolder" directly (the C++ name), and impl Deref<Target=QQmlEngine> for QmlEngineHolder?

[ratijas]

Is it worth to break API (since we were talking about that anyway), and to rename Rust's QmlEngine to "QmlEngineApplication" or "QmlEngineHolder" directly (the C++ name), and impl Deref<Target=QQmlEngine> for QmlEngineHolder?

Whatever suits you, I guess. It's not like there is a ton of users to care about porting. As long as version is bumped

[rubdos]

Is it worth to break API (since we were talking about that anyway), and to rename Rust's QmlEngine to "QmlEngineApplication" or "QmlEngineHolder" directly (the C++ name), and impl Deref<Target=QQmlEngine> for QmlEngineHolder?

Whatever suits you, I guess. It's not like there is a ton of users to care about porting. As long as version is bumped

When I wrote that, I didn't yet notice that QmlEngine != QQmlEngine. The current patch works, and only slightly breaks the API... I'm not even sure if it really breaks it; I moved a bunch of methods to the Deref'd implementation, and I suppose this only breaks when literally referring to e.g. QmlEngine::set_property instead of calling the function itself.