![]() Registered Member ![]()
|
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. |
![]() Registered Member ![]()
|
+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).)
openSUSE 13.2 x64, Platform Version 4.14.X, Kubuntu 14.04 (LTS), Platform Version 4.13.X
|
![]() Registered Member ![]()
|
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) |
![]() Registered Member ![]()
|
I guess that's in some config file?
That sounds great!
openSUSE 13.2 x64, Platform Version 4.14.X, Kubuntu 14.04 (LTS), Platform Version 4.13.X
|
![]() ![]()
|
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.
|
![]() Registered Member ![]()
|
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.
|
![]() KDE Developer ![]()
|
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 ![]() 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? |
![]() Registered Member ![]()
|
[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. |
![]() ![]()
|
Nope ![]()
QCompleter::PopupCompletion would, Completer::InlineCompletion would not.
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? |
![]() Registered Member ![]()
|
@dfaure Any progress on the filtering feature?
|
![]() Registered Member ![]()
|
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. |
Registered users: Bing [Bot], Google [Bot], kesang, Sogou [Bot], Yahoo [Bot]