> On 03/10/2012 07:32 PM, ext Andre Somers wrote: > > Signals are often used outside the context of properties. > > Signals yes, but NOTIFY signals? > > This change only affects signals marked as NOTIFY in a Q_PROPERTY macro.
I think the point is there may be instances where a signal that is emitted incidentally when a property changes is used as the notify signal for that property. I get not wanting to be forced into writing redundant 'emitted when this property has changed' documentation but excluding documentation that has been written for a signal seems a bit excessive, wouldn't it be enough to just omit the warning for an undocumented signal if it's a notify signal? Andrew > > > I'm already not all that enthousiastic about not having the getters > > and the setters documented explicitly*, and now people will have to > > start looking at several places in the documentation to find out what > > signals there are too. > > This doesn't change the class overview. It only changes where links point to. > > So you can still see that the class has members foo, setFoo and fooChanged > but the links point to 1 place, the property documentation. > > When you have a property, the getter, setter and notifier are > implementation details that don't matter to the property user. > > > I think there are even cases where a pair of getters& setters is only > > _documented_ as a property, but it is not defined as a Q_PROPERTY so > > anyone trying to use them using the properties API is at a loss at why > > that does not work... > > You can't document members as a property without using Q_PROPERTY. > > -- > Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, > Nokia - http://qt.nokia.com/ > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
