dfaure added inline comments.
INLINE COMMENTS
> kossebau wrote in kactioncollection.h:314
> No idea. I started a few times to look up what QT_MOC_COMPAT actually is
> about, but never had quick results, so delayed into the future.
>
> Just had a look again, but as before stranding with `MethodCompatibility`
> from qmetaobject_p.h, which seems though nowhere really used.
>
> So far my guess has been this is some relict from Qt3 times no-one ever
> properly cleaned up?
Taking this from the other side: warnings when connecting to deprecated signals
actually work. They happen in check_and_warn_compat in qobject.cpp
... this does support warning about connecting to compat slots, so my comment
was bogus, this is fine.
For the usual case, compat signals, the code checks `signal.attributes() &
QMetaMethod::Compatibility`.
Ah and I found where `MethodCompatibility` (which has the value 0x10) is
actually set...
the generated moc code says
6, 2, 89, 2, 0x06 /* Public */,
8, 2, 94, 2, 0x16 /* Public | MethodCompatibility */,
See the second line, it has the 0x10 value in there, which means
`MethodCompatibility` is set.... by value, not by name.
I'm just still a bit confused about the relation between the 0x10 metaobject
flag and the signal attribute which has value 0x1...
enum Attributes { Compatibility = 0x1, Cloned = 0x2, Scriptable = 0x4 };
But it must work, tst_qobject.cpp tests that QT_MOC_COMPAT ends up setting
`QMetaMethod::Compatibility` in attributes().
Anyhow, I still believe that using the *_DEPRECATED macro on a signal only
makes sense if we want to prevent subclasses from emitting the signal.
Theoretical possibility, extremely unlikely for KActionCollection, but... why
not. We can do this consistently everywhere without the need to consider the
likeliness of subclasses, I suppose.
REPOSITORY
R263 KXmlGui
BRANCH
deprecatedapi
REVISION DETAIL
https://phabricator.kde.org/D24466
To: kossebau, #frameworks, dfaure, mlaurent
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
