D24466: Use ECMGenerateExportHeader to manage deprecated API better

[David Faure]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191012/f4678a0b/attachment.html>