<table><tr><td style="">davidedmundson added a comment.
</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/D24423">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>The trouble is still here: if we land this patch and released new frameworks, it won't work with older plasma workspace (like 5.17.0, 5.16.x).</p></blockquote>

<p>Talk me through what will happen. Do they end up in lost and found?</p>

<p>In terms of the circular dependency, it does indeed seem very weird. Task for the KF6 board at least.</p>

<p>So, the state is:<br />
 ksycoca needs to know the name of the menu to use at compile time<br />
 That menu is therefore in the framework<br />
 The directory files it references are not.</p>

<p>IMHO the part that seems most wrong is that ksycocacocacooca needs the name at compile time. If we were on gnome we would want to load gnome's menu structure surely? Though maybe we need to at least have some menu so that ksycococoaoca loads all the applications even if they end up in the wrong "dir".</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R309 KService</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D24423">https://phabricator.kde.org/D24423</a></div></div><br /><div><strong>To: </strong>guoyunhe, Frameworks<br /><strong>Cc: </strong>davidedmundson, ngraham, ltoscano, kde-frameworks-devel, LeGast00n, GB_2, michaelh, bruns<br /></div>