kossebau added inline comments.
INLINE COMMENTS
> kossebau wrote in kactioncollection.h:314
> Okay, so "QT_MOC_COMPAT" is still a (just undocumented) thing, and thus
> something we should use for deprecated signal/slots then as before, right?
>
> Had now another look based on your info, and found that the magic to map 0x10
> onto 0x1 happens in the getter of the method attributes:
>
> int QMetaMethod::attributes() const
> {
> if (!mobj)
> return false;
> return ((mobj->d.data[handle + 4])>>4);
> }
>
> So that mystery seems solved :)
>
> For adding deprecation attributes via _DEPRECATED to signals, yes, would
> agree to do this consistently then, following your argumentation. Will add
> this to the howtodeprecateallkindsofapi text I yet have to write, so far
> delayed to first gather experience.
Just remembered though: seems that Qt code itself no longer uses QT_MOC_COMPAT?
At least I had no hits for actual usages in Qt classes when searching in my
local Qt headers, via code.woboq.org or github search, there only for the old
unsplit qt repo (which once made me think this is a Qt3 relict).
And given the `#ifndef QT_NO_DEBUG` does this warning land in normal Qt builds?
(sorry, not build Qt in a decade).
till have to test with my openSUSE TW, will do later today.
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
