I report here a bug report about the usability of the "Open with.. > Other" file dialog. I hope the VDG can help in improving it.

Original report:
https://bugs.kde.org/show_bug.cgi?id=359233

1. Taking into account the phylosophy "Simple by Default, Powerful When Needed" the "Run in terminal" option should be hidden in an Advanced section (Something like a collapsible group box).
2. The title of the file dialog doesn't carry much information. Most of the times I can just see the beginning of the full path of the file. Why don't we just show the file name or some more usable information? (see also: https://bugs.kde.org/show_bug.cgi?id=110146)
3. The input text box should filter the results in the Know application tree instead of being a command line. Again: a command line is for advanced user, should be hidden in the Advanced section.

Scenario:
I want to open a text file with kate.
1. I right click the file and kate is not listed in the "Open with" menu
2. I click "Other.."
3. Kate is part of the know applications.

Current behavior:
Possibility 1:
I navigate the tree until I find it. This takes time, especially if the application is nested multiple times and if there is a long list of entries.

Possibility 2:
I type "kate" in the text box. This will associate the file with the COMMAND kate not with the application kate.

Problems:
1. Some commands need parameters (See: https://bugs.kde.org/show_bug.cgi?id=358139)
2. Next time we will open the "Open with.." menu there will be two entries of kate (See attached image).

Desired behavior: I type "kate" in the text box and the applications in the "known application" list are filtered in such a way that only Kate is shown so I can click on it, saving the hassle of searching for it in the tree.

+1
Also, I'd like to suggest that the "Open with..." menu remembers my last choice, even if I did not set "Always open with this application" to true.

Usecase: I had to open a bunch of log files with LibreOffice Calc (because it was in CSV) - I had to select LOCalc everytime from the "Other..." menu, as the "Open with" menu was never updated. (This is on Plasma 4 / KDE SC 14.X however (can't check Plasma5 / FW5 right now).)

It's exactly the same on KDE 5.

you can configure those assignments with "kcmshell[4|5] filetypes"

About the dialog proposal:
The input line could serve as filter and explicit command input at the same time - selecting an entry replaces the command anyway (and it's not a very pro-ish feature to hint what command will be actually run, there's no point in treating users more dumb than they are)
For this purpose, one would switch to inline completion (for binaries) to allow using the up/down arrows to be forwarded to the treeview (so you can navigate the thing while filtering w/o having to remove the focus from the lineedit)

luebking wrote:you can configure those assignments with "kcmshell[4|5] filetypes"

I guess that's in some config file?

luebking wrote:About the dialog proposal:
The input line could serve as filter and explicit command input at the same time...

That sounds great!

no, you run "kcmshell4 filetypes" (or "kcmshell5 filetypes" or "kcmshell filetypes" - that unfortunately "depends" and I've no idea how SuSE presently handles this) what shall spam a dialog where you can configure file associations.

With 'kcmshell filetypes' (or more simply by opening File Associations from the Menu) you can configure it, but still is quite annoying. I guess it would be very easy to implement a "memory" feature for that menu.

luebking wrote:The input line could serve as filter and explicit command input at the same time - selecting an entry replaces the command anyway (and it's not a very pro-ish feature to hint what command will be actually run, there's no point in treating users more dumb than they are)
For this purpose, one would switch to inline completion (for binaries) to allow using the up/down arrows to be forwarded to the treeview (so you can navigate the thing while filtering w/o having to remove the focus from the lineedit)

The inline autocompletion has another issue, it completely covers the treeview. Which makes the whole idea of filtering the treeview quite moot, since it's mostly not visible during typing . Shall we just turn off autocompletion? For advanced users like me (who like to just type the name of the binary and ignore the treeview) it means typing "kaddressbook" instead of "kadd<down>" but I think it's acceptable to make the dialog more user-friendly overall. Otherwise we are going to soon go towards two modes, the "type an executable name" mode, and the "choose in the tree" mode (with filtering)....

Next issue, I started to implement the filtering, and it has the very usual issue that since all items in the tree are "closed" initially, after filtering they are still closed, so one has to open the parent item to see the actual item; very annoying. But I wonder what's the usual solution to this? Open all items initially? Open all items when typing the first letter? (seems already better, because it allows to navigate in the tree with the mouse instead, as the first action). Do we have another example of a filtered tree where the "folders" are initially closed?

[UPDATE: Actually I've reported this on the bug report page, together with a mockup]

I thought on this problem as well, but then I must have forgotten to report it.

For me it makes sense to remove the auto-completion feature at all, since I think that the number of cases when a file needs to opened with a binary file are very little ( I may be wrong). In my personal experience, if I need to open a file with an executable I press F4 in dolphin to open a shell and I execute it from there, which is much faster (of course this doesn't allow to remember the association).

If we instead want to keep the auto-completion feature, it would be probably enough to show the suggestion list only if we press <down>. At that point the user explicitly manifest the intention of using an executable and even if the tree view is covered, it's not a problem any more.

dfaure wrote:The inline autocompletion has another issue

Nope

it completely covers the treeview

QCompleter::PopupCompletion would, Completer::InlineCompletion would not.

But I wonder what's the usual solution to this? Open all items initially? Open all items when typing the first letter?

I wrote a "flat application menu" for BE::Shell which is basically a treeview (minus looking like a tree) what might serve as a pattern.
The lineedit completes $PATH binaries (inline) and also filters the tree below. Once the tree count drops under a certain threshold (don't ask me - 10?) all non-leaf elements are hidden (and skipped by keyboard input) and the tree (ie. the remaining leafs) are completely unfolded, so you get a flat list of <= 10 (please don't nail me on the number) items which you can select by the arrow up/down keys.

It's oc. a rather custom GUI element (and a hackish implementation, iirc. it's actually a treewidget)

Then there's another class I wrote for BE::MPC (this time actually a treeview) which doesn't only filter leafs but also nodes, unfolding up to the match (ie. entering "haydn" will not only get you the composers branch, but also the haydn variations under the brahms composer - or some tune that contains the string)
Latter would allow to filter for "image" to find that category (and gwenview/krita/gimp/feh/whatnot in it), but I guess the app category list isn't as extensive as my music compilation, so that's likely not worth it?

@dfaure Any progress on the filtering feature?

As a quick workaround for the dropdown menu that covers the application tree, I've just figured out that right clicking on the text immission box a going to the submenu "Text completion" it's possible to change the text completion mode from Popup to something else (e.g. none) and get rid of the dropdown list.

It's a feature that can be found in other KDE applications by the way.