Tracking issue for new API changes for 0.4

[ahayzen-kdab]

Design

There are discussions open discussing the change of design of API so that we can become closer to a superset of CXX and allow to mix and match between. Some of the latest design points are in #156

Main Steps

And while doing these consider any general refactoring that can occur :-)

• Rename make_qobject to cxxqt::bridge macro: rename make_qobject to cxx_qt::bridge #158
• Move current definition to be inside an extern "Qt" block WIP: syntax: move to using an extern Qt block #159
• Remove C++ namespace prefix cxx-qt-build: remove the option to specify a custom namespace prefix #160
• Add namespace support into the macro attribute cxxqt::bridge(namespace = "rust::object") cxx-qt-gen: use namespace = "A::B" from cxx_qt::bridge #194
• Change extract_qobject / extract_extern_qt to respond with a vector and also have the passthrough contents for extern "C++" / "Rust" etc
• Remove handle_property_changed as it won't be used anymore cxx-qt: remove handle_property_change instead rely on QML/C++ #151
• Remove QQmlExtensionPlugin helpers for now qmlextensionplugin: remove helpers and require developer to write C++ #152
• Rearrange the generation so that the mod ffi is removed and we move the Qt code to another mod (see the discussion) gen_rs: use CXX as module and move CXX-Qt to external module  #162
• Pass through extern blocks for now so we can get to the next stage gen_rs: pass through ForeignMod to the CXX bridge for now #164
• Require the user to define the types they use in the C++ extern, eg type QPoint = cxx_qt_lib::QPoint cxx-qt-gen: use extern "C++" block to define Qt lib types #167
• Change invokable definition to be onto impl Qt<T> block cxx-qt-gen: use impl cxx_qt::QObject<T> block for invokables #178
• Rename types exposed to C++ to be MyObject and MyObjectRust cxx-qt-gen: have MyObjectRust on C++ side and MyObjectQt on Rust #179
• Add rust getter method to go from C++ to Rust cxx-qt-gen: add rust getters for immutable and mutable access #181
• Change opaque helper types to be UniquePtr and have the wrapping occur on the C++ side cxx-qt-lib: use generic templated method for converting returns #165 cxx-qt-lib: use unique ptr types and don't wrap #166
• Namespace internal methods so that we don't collide if QObject are in the same namespace cxx-qt-gen: use namespace for internal methods and support no namespace #210
• Combine the Data and RustObj structs (once this has happened we can try https://github.com/ahayzen-KDAB/cxx-qt/tree/cxx-qt-libs-tidy-derives again) cxx-qt-gen: remove the Data struct and move properties to Rust #235
• Add cxx_qt::qobject macro and use RustObj as the struct for the QObject for now cxx-qt-gen: add cxx_qt::qobject to determine which struct is the QObject #197 cxx-qt-gen: use cxx_qt::qobject struct as the QObject name #198
• Add the CppObj methods onto the Cpp obj as a method?
• Put the impl Qt<T> block onto the Cpp object and update the wrappers to be namespaced free functions Remove CppObj #202
• Add the macros for cxx_qt:::signals etc cxx-qt-gen: use cxx_qt::signals attribute to define signals #180
• Remove pattern matching and let compiler failures handle typing issues on the C++ side cxx-qt-gen: remove gen_cpp and use new phases for C++ side #239
• Remove pattern matching and let compiler failures handle typing issues on the Rust side cxx-qt-gen: remove gen_rust and use new phases for Rust side #254
• Move the properties to be own on the Rust side and add the getter/setter/_mut helper cxx-qt-gen: remove the Data struct and move properties to Rust #235
• Move the CppObj helpers to be on the Cpp object (?)
• Once all the cxx-qt stuff uses macros or we can infer it, then passthrough unknown components to the CXX mod
• Consider how to define signals and state which object they are on (either attribute or template) - attribute
• Add the base class to the cxx_qt::qobject macro cxx-qt-gen: support base class for the qobject macro #214
• Add mutable getter for properties cxx-qt-gen: add prop_mut and rename get_prop to prop #267
• Rename properties to prop/prop_mut/set_prop on the Rust side cxx-qt-gen: add prop_mut and rename get_prop to prop #267
• Add getter/setter/mut for non properties (private fields) cxx-qt-gen: add prop/prop_mut/set_prop for Rust fields as well #268
• Can we use Deref for getters of properties so that we can do UniquePtr -> &T in the same way as T -> &T?
• Have a way to specify that a method is overriding a virtual How should we define C++ specifiers #257 cxx-qt-gen: add C++ specifiers support for final, virtual, override #282
• Implement an example listmodel manually examples: manually implement a listmodel #260
• Improve C++ context API so that it matches nested objects later cxx-qt-gen: use impl qobject::T to define the C++ context #276
• Update the book for new API changes
• Remove any branches from cargo.toml's (eg qt-build)
• Change signals to be immediate now that we have a recursive mutex cxx-qt-gen: emit signals immediately #281
• Use the module name for the generated file name for now, with a macro file_stem to override cxx-qt-gen: use the module name or attribute for the CXX file names #283
• Split qml-features QML into pages demoing each feature
• Change include paths to be cxx-qt-gen/stem.h and cxx-qt-lib/stem.h

Further independent steps

• Change CMake to use a tool CLI tool for generating C++ sources at CMake configure stage #146
• Build generated C++ with Cargo, simplify CMake (build cxx-qt-lib autogenerated C++ with Cargo instead of CMake #174, cxx-qt-build: build generated C++ with cc from build.rs #218)
• Change UpdateRequester to be generic Generic queued emitter for threading #150 cxx-qt-gen: change the update requester to use function pointers #215

Stretch improvements (move to 0.5)

• Run whole build from Cargo without CMake add example application built entirely with Cargo #221
• (0.5) Have a cxx_qt_lib::prelude!() to define a unsafe extern "C++" block with all the types in it
• (0.5) Support having a namespace on further objects, such as on the struct for the QObject
• 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.
• Support multiple macro mod blocks
• (0.5) Have the ability to declare a #[property(getter = "...", setter = "...", notify = "...")]
• (0.5) 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
• Investigate how CXX does parsing of syn code to find the macro mods, as we currently pattern match cxx::bridge to be the macro when the developer might do use cxx::bridge; ... #[bridge]
• 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 )

[ahayzen-kdab]

Split the remaining issues into separate tasks.