D24466: Use ECMGenerateExportHeader to manage deprecated API better

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> dfaure wrote in kactioncollection.h:314
> 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.

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.

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/20191014/b655f3e8/attachment.html>