Subclassing a Qt class and the 'Q_OBJECT' macro?

[matkuki]

Hi,

C++ novice here, I am loving cppfront so far, but I don't know how or if it's even possible to subclass a Qt class because of the needed Q_OBJECT macro declaration at the top. Example:

class MainWindow: public QMainWindow
{
    Q_OBJECT // <-- THIS PART
    
public:
    MainWindow(int width, int height, QWidget *parent = 0);
    ~MainWindow();
    ...
};

Is there a way to do this in cppfront or to inject it into the generated cpp code? Thanks

[JohelEGP]

I use a macro to inject [[no_unique_address]] before a member's type (e.g., see #1252 (comment)).
It seems like you can't do the same here, since an access specifier is always lowered: https://cpp2.godbolt.org/z/qsThcfGT5.

[matkuki]

Is it possible to circumvent this problem? If so, could someone give me a simple example?
Thanks

[JohelEGP]

I don't know what the macro does.
Maybe it suffices to put it in a Cpp1 base type.

class MyWindowImpl {
  Q_OBJECT
};
MyWindow: type == {
  this: MyWindowImpl = ();
}

[vincent-hui]

Defining a property by Q_PROPERTY MACRO in MyWindow requires Q_OBJECT MACRO. Without Q_OBJECT MACRO, properties cannot be defined in MyWindow.
We need metaclass functions for Qt.

[shemeshg]

I believe he’d like to leverage the template engine of the cppfront to inject the PROPERTY and inherit QOBJECT, while also including QML_ELEMENT.

For the time being, i'm using Python’s cogapp to create the class and as you suggested inherit from it.
(I find it more more manageable for humans and such)

Here’s an example:
https://github.com/shemeshg/MidiRouterClient/blob/main/Bal/RtMidiRouterLib/MidiClient/Dropdownlist.h

And here’s the properties definition:
https://github.com/shemeshg/MidiRouterClient/blob/main/Bal/RtMidiRouterLib/MidiClient/Dropdownlist.py

(QObject role is to delete copy constructor since QT is parental memory management, and add these macros, and add public slots: that adds macro of INVOCABLE for every function, and option for signals:)

one more thing: cppfront isn’t aware of parent memory. same as the Microsoft GSL tool gsl::owner, it’ll complain about memory leaks, and QT doesn’t support std::unique.
also QT STL's like QList, are not parental memory management, and requires manual delete of each new
(maybe this is where template engines may shine, because it will auto create the safe means to do so).
In some cases Qt objects pretend to be RAII (QApplication, etc...), but will never be movable.