<table><tr><td style="">hein 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/D3805" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>I've tested now and things look good, the multi-activity-migration thing is solved. Here's my remaining concerns:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">No Kickoff support: Personally I think we should actually migrate all applets at once. One of the main motivations for this is so users no longer unexpectedly lose favorites when swiching between applets using Alternatives. If Kickoff (the default applet) doesn't use it, that is not yet actually achieved. And since the missing support was based on a misunderstanding ...</li>
</ul>

<ul class="remarkup-list">
<li class="remarkup-list-item">I really dislike the submenu with the checkboxes, in particular for removing a favorite. It's just very complicated and hard to use, you need to uncheck a checkbox to remove. I know everybody is sick and tired of this merge taking so long, but I am really, really hesitant of shipping that to users. It sort-of is okay for windows because it's more like tagging there and remove is actually done by closing the window, but here it's incredibly awkward.</li>
</ul>

<ul class="remarkup-list">
<li class="remarkup-list-item">The initial sorting of the migrated superset seems random. How is it done?</li>
</ul>

<ul class="remarkup-list">
<li class="remarkup-list-item">In <a href="https://phabricator.kde.org/D7561" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D7561</a> we adjusted libtaskmanager to use applications:<kservice menuId()> as URL whenever we're dealing with a KService that returns a non-empty menuId() instead of KService::entryPath(). The approach taken is to accept both as input (rc file) but resolve the latter to applications: when possible and then use that for the model data roles. As adding a new launcher is done from the data roles, newly-added launchers are stored as applications:. That makes it a non-absolute path, which fixes cases like (a) apps (or the menu editor) making a copy of a .desktop file in $HOME to add/update data there and the Task Manager not noticing or (b) having a launcher point at a .desktop file in $HOME that disappears later (e.g. menu editor reset). Kicker still uses entryPath so it suffers from both problems. I'd like this adjustment done here as well, using more or less the same approach, and I think it would make sense as part of this patch maybe because I'm not sure how it will affect your migration and so we don't add outdated stuff to the KAStats db in the first place that would need to be rewritten later otherwise?</li>
</ul></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D3805" rel="noreferrer">https://phabricator.kde.org/D3805</a></div></div><br /><div><strong>To: </strong>ivan, mart, hein<br /><strong>Cc: </strong>Zren, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas<br /></div>