cxx-qt-lib: Add binding for QQmlApplicationEngine::loadFromModule #1141
Conversation
|
This will fall into the same fallacy as described here: #1140 (comment) due to using QAnyStringView. |
redstrate
force-pushed
the
work/josh/add-loadfrommodule-binding
branch
from
3232bc3 to
88c6b25
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1141 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 71 71
Lines 11967 11967
=========================================
Hits 11967 11967 ☔ View full report in Codecov by Sentry. |
| include!("cxx-qt-lib/qanystringview.h"); | ||
| type QAnyStringView<'a> = crate::QAnyStringView<'a>; |
There was a problem hiding this comment.
you need the cfg flags also here, although unsure if they work on include macros?
As this is a cxx::bridge rather than a cxx_qt::bridge I think the cfg flag should work on an extern block. It's only CXX-Qt bridges where we have the limitation of support only on certain items #1133
There was a problem hiding this comment.
I tried a ton of solutions, and it doesn't seem like extern blocks support cfg macros. It would get rid of the include, but still try to parse the type. I have looked into substituting a dummy type which kinda works, but it's working around missing functionality that should really be in CXX..
There was a problem hiding this comment.
Aha, as part of #1168 we improved CXX-Qt's side but found some issues with CXX itself. One of them we fixed as cfg attributes not working on type aliases ( dtolnay/cxx#1464 ).
Can you try this again with the newer CXX version and with the following i think it might work now 🙏
unsafe extern "C++" {
#[cfg(any(cxxqt_qt_version_at_least_7, cxxqt_qt_version_at_least_6_5))]
include!("cxx-qt-lib/qanystringview.h");
#[cfg(any(cxxqt_qt_version_at_least_7, cxxqt_qt_version_at_least_6_5))]
type QAnyStringView<'a> = crate::QAnyStringView<'a>;
}
4cb63ec to
1178956
Compare
This function was added in Qt 6.5, as an alternative from loading files by file path.
redstrate
force-pushed
the
work/josh/add-loadfrommodule-binding
branch
from
1178956 to
6d4dc03
Compare
This adds a Rust setup for the Kirigami tutorial. The idea is that we'd have an introductory setup in the Kirigami tutorial and a more complete tutorial in a new section "Rust with Kirigami". This MR is fairly complete regardless, but I intend to simplify it and move the more complex things to the new section later. Unfortunately there are two problems, although I don't consider them blockers: * the current cxx-qt QmlModule doesn't quite match what we do in this tutorial (where we only have an entrypoint and load a QML file, without exposing anything from business logic to QML), so it required a dummy struct and QObject, which is a workaround * engine.load() is, expectedly, very very very long and I can't wait for KDAB/cxx-qt#1141 tbh This tutorial **doesn't** use the full cxx-qt CMake API mentioned in https://kdab.github.io/cxx-qt/book/getting-started/5-cmake-integration.html, opting instead for just basic CMake to keep things simple and focused on the necessary install / ECM stuff. New devs wanting to make a Qt Rust app won't really care about using C++ stuff (they'll use cxx-qt for their Qt needs and cxx-kde-frameworks for their KDE Frameworks needs once we make a tutorial for it), and they'll certainly find it weird to initialize the app with a C++ main.cpp for a Rust-only app. We can use the cxx-qt CMake API if it somehow allows to fix the first problem listed above, though.
This function was added in Qt 6.5, as an alternative from loading files by file path.