<table><tr><td style="">dfaure added inline comments.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D24466">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D24466#inline-139088">View Inline</a><span style="color: #4b4d51; font-weight: bold;">kossebau</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kactioncollection.h:314</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">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.</p>

<p style="padding: 0; margin: 8px;">Just had a look again, but as before stranding with <tt style="background: #ebebeb; font-size: 13px;">MethodCompatibility</tt> from qmetaobject_p.h, which seems though nowhere really used.</p>

<p style="padding: 0; margin: 8px;">So far my guess has been this is some relict from Qt3 times no-one ever properly cleaned up?</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Taking this from the other side: warnings when connecting to deprecated signals actually work. They happen in check_and_warn_compat in qobject.cpp</p>

<p style="padding: 0; margin: 8px;">... this does support warning about connecting to compat slots, so my comment was bogus, this is fine.</p>

<p style="padding: 0; margin: 8px;">For the usual case, compat signals, the code checks <tt style="background: #ebebeb; font-size: 13px;">signal.attributes() & QMetaMethod::Compatibility</tt>.</p>

<p style="padding: 0; margin: 8px;">Ah and I found where <tt style="background: #ebebeb; font-size: 13px;">MethodCompatibility</tt> (which has the value 0x10) is actually set...<br />
the generated moc code says</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">6,    2,   89,    2, 0x06 /* Public */,
8,    2,   94,    2, 0x16 /* Public | MethodCompatibility */,</pre></div>

<p style="padding: 0; margin: 8px;">See the second line, it has the 0x10 value in there, which means <tt style="background: #ebebeb; font-size: 13px;">MethodCompatibility</tt> is set.... by value, not by name.</p>

<p style="padding: 0; margin: 8px;">I'm just still a bit confused about the relation between the 0x10 metaobject flag and the signal attribute which has value 0x1...</p>

<div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">enum Attributes { Compatibility = 0x1, Cloned = 0x2, Scriptable = 0x4 };</pre></div>

<p style="padding: 0; margin: 8px;">But it must work, tst_qobject.cpp tests that QT_MOC_COMPAT ends up setting <tt style="background: #ebebeb; font-size: 13px;">QMetaMethod::Compatibility</tt> in attributes().</p>

<p style="padding: 0; margin: 8px;">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.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R263 KXmlGui</div></div></div><br /><div><strong>BRANCH</strong><div><div>deprecatedapi</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D24466">https://phabricator.kde.org/D24466</a></div></div><br /><div><strong>To: </strong>kossebau, Frameworks, dfaure, mlaurent<br /><strong>Cc: </strong>kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns<br /></div>