<table><tr><td style="">rkflx 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/D8056" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>Gave this a spin, it's a really nice improvement. As for the categories, I do not feel they "get in the way", because:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">In most cases, even after only typing three letters there is only one result left, which is already preselected so <kbd style="display: inline-block; min-width: 1em; padding: 4px 5px 5px; font-weight: normal; font-size: 0.8rem; text-align: center; text-decoration: none; line-height: 0.6rem; border-radius: 3px; box-shadow: inset 0 -1px 0 rgba(71, 87, 120, 0.08); user-select: none; background: #f7f7f7; border: 1px solid #C7CCD9;">Enter</kbd> will accept seemlessly.</li>
<li class="remarkup-list-item">It is actually helpful to also see which category an app is in, as this provides confirmation you are on the right track (e.g. if you do "graphics" things, you do not want "devel" stuff) as well as disambiguation of similar entries.</li>
<li class="remarkup-list-item">In a way those visual anchors help finding results faster in case the resulting list is long, as you can easily move to the next category instead of having to scan the complete list of results.</li>
</ul>

<p>Here is an idea for a compromise which both preserves important context and reduces visual noise: Include subtle grouping like in the new type-ahead search in <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">System Settings</span></span></span>, i.e. instead of a tree, flatten the list and include the categories as disabled items / intermediate headers. (Not sure how difficult this would be to implement, though.)</p>

<p>At least any duplicates should be removed if you should decide to remove categories altogether (e.g. <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">KMail</span></span></span> is both in <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Internet</span></span></span> and <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Office</span></span></span>, which would be confusing without context). Note the duplication is actually helpful when just using categories, and searching in <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Kickoff</span></span></span> already de-duplicates results.</p>

<p>That said, there are some improvements I could imagine would polish this even further:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Expand the categories once the first character is typed. This gives a hint on what to type next (e.g. <tt style="background: #ebebeb; font-size: 13px;">km</tt> would hint at <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">KMail</span></span></span> and <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">KMag</span></span></span> instead of just showing the categories).</li>
<li class="remarkup-list-item">Search in the descriptions too (e.g. <tt style="background: #ebebeb; font-size: 13px;">browser</tt> would show <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Firefox</span></span></span> and <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Chromium</span></span></span> instead of returning nothing).</li>
<li class="remarkup-list-item">First line of text: Make it clear what is description and what is the item being opened, i.e. like on Phab I would not write "install the arc helper" but add markup like "install the <tt style="background: #ebebeb; font-size: 13px;">arc</tt> helper". Not sure about the best way to do this, but using bold text would be a first step (also see screenshot below).</li>
<li class="remarkup-list-item">It is not discoverable you are allowed to type in a full path to a binary, which is important for a lot of third party / proprietary / binary.tar.gz-style software not installing proper desktop files and one of the primary use cases of this dialog IMHO. Ideas: Add something to the tooltip? Add a gray text (e.g. "Type to search or enter full path" – exact formulation could be better) to the line edit which is currently just empty?</li>
</ul>

<p>That said, I would suggest to just commit this patch as is and work on any further improvements in a followup patch (just wanted to put this out there to give a complete picture).</p>

<hr class="remarkup-hr" />

<p>In addition to the screenshot in <a href="https://phabricator.kde.org/D8056#159491" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D8056#159491</a>, the dialog is used when opening <tt style="background: #ebebeb; font-size: 13px;">kcmshell5 filetypes</tt> and then navigating <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">"text"</span></span><span style="color: #92969D;"> → </span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">"css"</span></span><span style="color: #92969D;"> → </span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Application Preference Order</span></span><span style="color: #92969D;"> → </span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">Add…</span></span></span>. Note the bold text (although I wish the colon in front of it could go):</p>

<p><a href="https://phabricator.kde.org/F5478956" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">F5478956: app-chooser.png</a></p>

<p>I'm showing this because there is actually a mention of "If the program is not listed…". In the end both dialogs should be consistent in intro text, line edit background text and tooltip help text. I'd be happy to help implementing any adaptations in wording once we've reached a conclusion here.</p></div></div><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/D8056#inline-36978" rel="noreferrer">View Inline</a><span style="color: #4b4d51; font-weight: bold;">dfaure</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kopenwithdialog.cpp:826</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Please use QRegularExpression; QRegExp is deprecated.</p>

<p style="padding: 0; margin: 8px;">Although, if this is about FixedString, why not just use setFilterFixedString?<br />
Regexps are slow, better avoid them when not necessary.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;"><a href="https://phabricator.kde.org/p/simgunz/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@simgunz</a> This is marked as done, but still uses <tt style="background: #ebebeb; font-size: 13px;">QRegExp</tt> and not <tt style="background: #ebebeb; font-size: 13px;">QRegularExpression</tt>?</p></div></div><br /><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/D8056#inline-38153" rel="noreferrer">View Inline</a><span style="color: #4b4d51; font-weight: bold;">kopenwithdialog.cpp:1099</span></div>
<div style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; white-space: pre-wrap; clear: both; padding: 4px 0; margin: 0;"><div style="padding: 0 8px; margin: 0 4px; background: rgba(151, 234, 151, .6);">            <span style="color: #74777d">// FIXME: Disable arrow down in CompletionPopup and CompletionPopupAuto only when the dropdown list is shown.</span>
</div><div style="padding: 0 8px; margin: 0 4px; background: rgba(151, 234, 151, .6);">            <span style="color: #74777d">// When popup completion mode is used the down arrow is used to navigate the dropdown list of results</span>
</div><div style="padding: 0 8px; margin: 0 4px; background: rgba(151, 234, 151, .6);">            <span style="color: #aa4000">if</span> <span class="p">(</span><span class="n">combo</span><span style="color: #aa2211">-></span><span class="n">completionMode</span><span class="p">()</span> <span style="color: #aa2211">!=</span> <span class="n">KCompletion</span><span style="color: #aa2211">::</span><span class="n">CompletionPopup</span> <span style="color: #aa2211">&&</span> <span class="n">combo</span><span style="color: #aa2211">-></span><span class="n">completionMode</span><span class="p">()</span> <span style="color: #aa2211">!=</span> <span class="n">KCompletion</span><span style="color: #aa2211">::</span><span class="n">CompletionPopupAuto</span><span class="p">)</span> <span class="p">{</span>
</div></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Is this a "fixme-before-commit" or a "fixme-sometimes-in-the-future" FIXME?</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R241 KIO</div></div></div><br /><div><strong>BRANCH</strong><div><div>openwithdialog-filter-app-tree</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8056" rel="noreferrer">https://phabricator.kde.org/D8056</a></div></div><br /><div><strong>To: </strong>simgunz, dfaure, Frameworks, VDG, ngraham<br /><strong>Cc: </strong>rkflx, subdiff, fabianr, abetts, ngraham, alexeymin, Frameworks<br /></div>