Draft: Tracking issue for new possible changes for 0.5

[ahayzen-kdab]

Discussions

• Use traits to define inheritance impls Use traits to define inheritance impls #270
• C++ property types for setter/getter ? C++ property types for setter/getter ? #278
• Defining C++ methods and Q_INVOKABLES from Rust Defining C++ methods and Q_INVOKABLES from Rust #279
• Defining nested objects (probably two types to consider, owned by C++/Qt and owned by Rust)

General

• Remove std uses in Rust where possible and use core or alloc etc
• Ensure C++ is correctly namespaced in all places (eg ::std) and includes are fully qualified (eg <QtCore/QString>)

cxx-qt-gen improvements

• Have the ability to declare a #[property(getter = "...", setter = "...", notify = "...")]
• Have an attribute on signals to say that that signal already exists ? enum Signal { #[existing_name="data_changed"] DataChanged } which is then matched to the existing name on the base class and prove with static asserts or cxx bridge typing
• Have a cxx_qt_lib::prelude!() to define a unsafe extern "C++" block with all the types in it
  • if we can define in cxx_qt_lib (nested macros are tricky?) we could have cxx_qt_lib::qtcore::prelude!() and cxx_qt_lib::qtgui::prelude!() etc and then cxx_qt_lib::qtcore::qstring::include!()
• Support having a namespace on further objects, such as on the struct for the QObject
• Do we still need the cxx_type and return_cxx_type ? If they can be removed then signal emits don't need a wrapper. And macro attribute parsing may be simpler

cxx-qt-lib improvements

• Add features to cxx-qt-lib to be able to split QtCore and QtGui
  • Split the folders in src/qtcore/T.rs rather than src/types/T.rs ?
• Decide on more useful types to add from QtCore/QtGui (eg QByteArray, QModelIndex, QVector2d, QHash, QVector etc)
• Decide on useful crates to add as integration features to cxx-qt-lib
  • serde as a feature then impl (de)serialise for types
  • rgb (?) as a feature for QColor
  • etc

Stretch improvements

• Support multiple macro mod blocks
• Support multiple QObject's being defined in one block cxx-qt-gen: add support for multiple QObjects in writer/cpp #216 cxx-qt-gen: add support for multiple qobjects in rust writer #250
  • we need to avoid the create_rs etc colliding on the Rust side (we already namespace on the C++ side) but we either need one of these fixed in CXX to support it...
    • allowing for reusing the same Rust type across bridges (so that we could have a mod ffi and a mod internals_my_object sharing the same type but splitting the create_rs module placement) Extern "Rust" types that are nonlocal dtolnay/cxx#496
    • being able to define static methods so we could have MyObjectRust::create_rs() Distinguish static member function on shared structs dtolnay/cxx#447
    • or we mangle the names ourselves so they don't collide, but having static method support in CXX would be useful in both directions and avoid the extra namespace etc.
• Consider if we can define our own structure for parsing - https://docs.rs/syn/1.0.98/syn/parse/index.html#example this might make it easier to define the syntax ?
• Split macros into cxx-qt-macro then reexport in cxx-qt so that we can cxx_qt::QObject a struct in the cxx_qt definition (see https://users.rust-lang.org/t/solved-is-it-possible-to-reexport-a-proc-macro/16864 )

Anything else left over from 0.4 #157

[ahayzen-kdab]

Moved into separate issue on the 0.5 milestone https://github.com/KDAB/cxx-qt/milestone/4