That's the design reason. A technical one is that in Qt4 you made connections only via SIGNAL macro, which just normalized signal name as a string, so signals could be private. With the function pointer based syntax you wouldn't be able to specify private &Class::signalName in the static QObject::connect.

Slots are a different story. In Qt5 and 6 you can make a connection to any functor, not just slots. For the purpose of connections slots are pretty much just regular member functions, so they can be public, private or protected like any other method. The only difference is they are registered as slots in meta object and can be used in the old string based connections.

As to which is better - public or private. There's no better or worse. It depends on a use case. Like with regular methods you, as a designer of the class, decide what is the desired access level for given method.

1- Why do Signals have to be public? (Please explain the underlying mechanism)
2- Do slots need to be public as well? (if yes, then why? and if not, then which is better public/private?)

Treat them as normal functions and you get the answer by yourself.

That's the design reason. A technical one is that in Qt4 you made connections only via SIGNAL macro, which just normalized signal name as a string, so signals could be private. With the function pointer based syntax you wouldn't be able to specify private &Class::signalName in the static QObject::connect.

Slots are a different story. In Qt5 and 6 you can make a connection to any functor, not just slots. For the purpose of connections slots are pretty much just regular member functions, so they can be public, private or protected like any other method. The only difference is they are registered as slots in meta object and can be used in the old string based connections.

As to which is better - public or private. There's no better or worse. It depends on a use case. Like with regular methods you, as a designer of the class, decide what is the desired access level for given method.