<table><tr><td style="">kossebau 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-139101">View Inline</a><span style="color: #4b4d51; font-weight: bold;">dfaure</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;">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 style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">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?</p>
<p style="padding: 0; margin: 8px;">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:</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);">int QMetaMethod::attributes() const
{
if (!mobj)
return false;
return ((mobj->d.data[handle + 4])>>4);
}</pre></div>
<p style="padding: 0; margin: 8px;">So that mystery seems solved :)</p>
<p style="padding: 0; margin: 8px;">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.</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>