Bug 359233

Summary: Improve usability of "Open with > Other" file dialog
Product: [Frameworks and Libraries] frameworks-kio Reporter: Simone Gaiarin <simgunz>
Component: generalAssignee: David Faure <faure>
Status: RESOLVED FIXED    
Severity: wishlist CC: bugseforuns, codestruct, colesen, kdelibs-bugs, maurizio.colucci, MurzNN, nate, sibskull, simonandric5, sladivadi, sudrien, visual-design
Priority: NOR Keywords: usability
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Show the two entries of kate.
Mockup of the open with dialog
Improve caption and text

Description Simone Gaiarin 2016-02-10 13:38:46 UTC
Here I want to point out some usability issues with the "Open with > Other" file dialog.

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.

I would suggest to involve the Visual Design Group in this.

Related bugs:
https://bugs.kde.org/show_bug.cgi?id=358139
https://bugs.kde.org/show_bug.cgi?id=195214
https://bugs.kde.org/show_bug.cgi?id=110146

Reproducible: Always
Comment 1 Simone Gaiarin 2016-02-10 13:40:33 UTC
Created attachment 97134 [details]
Show the two entries of kate.

If we associate the file with the "kate" command two entries of kate are shown in the "Open with.." menu, and one of those doesn't have an icon (because it's a command).
Comment 2 David Faure 2016-02-20 19:07:52 UTC
Could you actually involve the visual design group and tell me what to implement? I volunteer to implement what you come up with, but not to take part in lengthy discussions :)


PS: I implemented https://bugs.kde.org/show_bug.cgi?id=110146, see link to screenshot there.
Comment 3 Simone Gaiarin 2016-02-20 19:18:17 UTC
Thanks for the interest.

I've actually opened a topic in the VDG section of the forum, but for now the discussion haven't received much interest. Let's wait a bit and see if someone post something there.

https://forum.kde.org/viewtopic.php?f=285&t=131014
Comment 4 Simone Gaiarin 2016-02-20 20:08:03 UTC
Created attachment 97317 [details]
Mockup of the open with dialog

My two cents on how to implement the solution:

See attached mockup first.

* Set window title to the file name without the full path (see red circle in mockup)
* Add "Advanced section" to hide terminal options (see mockup)
* Line edit should behave like this:
  * When the user start typing the know applications are filtered out leaving only the ones that match the query
  * It can also behave as a terminal to run a command, but I would activate the dropdown suggestion list of commands only if the user presses "arrow down". The current behavior of showing it as the user starts typing will let it hide the known application list underneath. In this way the know application list is considered the way of choosing the application with highest priority, while the terminal command is a secondary option.


In any case let's wait for the VDG suggestions, otherwise I suggest to implement as I described if none has anything against it.
Comment 5 David Faure 2016-02-28 13:48:08 UTC
Window title: the filename is actually a bit hard to see, and the sentence "Open with:" underneath is a bit terse. How about something like Windows does? http://www.bleepstatic.com/tutorials/windows-7/change-file-associations/choose-program.jpg
Rather have a terse caption and an explanatory sentence like that, no?
Comment 6 David Faure 2016-02-28 14:02:01 UTC
Created attachment 97592 [details]
Improve caption and text

Here's what my current code leads to.
Comment 7 David Faure 2016-03-13 23:34:04 UTC
Git commit 2e652f99ad069188f96f7f070579996a13e9a4f6 by David Faure.
Committed on 13/03/2016 at 23:33.
Pushed by dfaure into branch 'master'.

KOpenWithDialog: improve window title and description text

M  +11   -8    src/widgets/kopenwithdialog.cpp
M  +1    -1    src/widgets/kopenwithdialog.h
M  +6    -6    src/widgets/krun.cpp
M  +2    -2    tests/kopenwithtest.cpp

http://commits.kde.org/kio/2e652f99ad069188f96f7f070579996a13e9a4f6
Comment 8 Simone Gaiarin 2017-07-12 17:32:00 UTC
I've submitted a patch to solve the point number 3, app tree filtering.

https://git.reviewboard.kde.org/r/130179/
Comment 9 David Faure 2017-07-15 12:53:12 UTC
Git commit 0296b89714ce96b247322d9be09b387573d79193 by David Faure, on behalf of Simone Gaiarin.
Committed on 15/07/2017 at 12:53.
Pushed by dfaure into branch 'master'.

Make advanced options of "open with" dialog collabsible and hidden by default

The current "open with" dialog implementation does not follow the KDE principle "Simple by default, powerful when needed" for the following reasons:
- The "run in terminal" and "keep terminal open" options are advanced options and should not be exposed by default
- The primary goal of the dialog should be to select an application from the app tree, running command is an advanced feature

My patch changes the behavior as follow:

* Put the two options in a KCollapsibleComboBox collapsed by default
* The user can expand it only if he needs to use a command line command

Implementation details:
- When the KCollapsibleComboBox is clicked it is expanded upward keeping the dialog size fixed and compressing the treeview, I'm not sure this is the best approach, but to make it expand downwards we need to fix the size of the dialog with setSizeConstraint(QLayout::SetFixedSize); which may not be desiderable. Maybe there is a way to keep the dialog resizable and expand the combobox downwards, but I couldn't find it.
- I've increased the vertical size of the dialog (which I think it was too small) also to accomodate the upward expansion which otherwise would make the app tree almost disappear

Relevant discussions:
https://forum.kde.org/viewtopic.php?f=285&t=131014
REVIEW: 130180

M  +24   -11   src/widgets/kopenwithdialog.cpp

https://commits.kde.org/kio/0296b89714ce96b247322d9be09b387573d79193
Comment 10 Simone Gaiarin 2017-09-04 08:32:21 UTC
@David Faure Have you had a look at the other review request regarding this bug? The one on tree filtering.

https://git.reviewboard.kde.org/r/130179/
Comment 11 Christoph Feck 2017-09-25 20:27:40 UTC
Simone, if you are still interested to contribute your improvements, I suggest to upload the patch to https://phabricator.kde.org/differential/diff/create/

Unfortunately we had to abandon the old reviewboard site.
Comment 12 Simone Gaiarin 2017-09-26 08:20:28 UTC
I'm trying to submit the patch to phabricator using arcanist and I have some questions:

- Who should I set as reviewer?

In the phabricator guide they say to set a hashtag with the name of the project but searching for the project "kio" I don't get results on phabricator.

so what is the name of the project? 

- Are there a list of keywords to use in the arc commit message? As an example one to say which bug is fixed by this patch?
Comment 13 Simone Gaiarin 2017-09-26 08:23:45 UTC
I'm using arcanist instead of the patch form because the modification includes 7 commits, and I think it is going to be way harder to review if I squash everything in a single patch. 

I'm not familiar with arcanist, but I hope it preserves the different commits with their messages.
Comment 14 Nate Graham 2017-09-29 17:58:48 UTC
Nice work! Does this also have the effect of fixing https://bugs.kde.org/show_bug.cgi?id=377322?
Comment 15 Nate Graham 2017-09-29 18:00:06 UTC
Ah, I see that it does, since my duplicate entries are actually commands, not app items.
Comment 16 Nate Graham 2017-09-29 18:01:35 UTC
*** Bug 377322 has been marked as a duplicate of this bug. ***
Comment 17 Nate Graham 2017-09-29 18:02:54 UTC
And for people's easy reference, the Phabricator revision is at https://phabricator.kde.org/D8056
Comment 18 Nate Graham 2017-10-27 13:40:13 UTC
*** Bug 358139 has been marked as a duplicate of this bug. ***
Comment 19 null 2018-02-14 17:20:04 UTC
Git commit e3af26bbb1e7dd32a7bb48c615d352416066e238 by Henrik Fehlauer, on behalf of Simone Gaiarin.
Committed on 14/02/2018 at 17:19.
Pushed by rkflx into branch 'master'.

Improve usability of "Open With" dialog by adding option to filter the application tree

Summary:

The current "open with" dialog implementation does not follow the KDE principle "Simple by default, powerful when needed" for the following reasons:
- The current primary goal of the lineedit is to type in a command. Indeed when start typing a drop-down list with command auto-completion appears.

Usability problems:
- The mentioned drop-down list covers the application tree
- It's not possible to search in the application tree, so to find a software it is necessary to guess the category every time

My patch changes the behavior as follow:

Simple by default:
- The primary goal of the lineedit is to be a search box that allows to filter the applications in the tree
- The command auto-completion is disabled by default

Powerful when needed
- The command autocompletion can be turned on by advanced users by selecting the preferred autocompletion mode in the right click context menu of the lineedit (this behavior is quite hidden, and I guess most of the normal users don't even know it's possible (I didn't know it until I dig into the code))

Implementation details:
- The application tree filtering is achieved using a subclass of QSortFilterProxyModel
- When 3 characters are typed in the search box all the tree is expanded (there should be few matching entries at this point)
- When the 3rd character is deleted all the tree is collapsed
- In order to be able to filter, it's necessary to fetch all the tree nodes when the model is created, and not on demand as it was before. This is achieved by adding a fetchAll method. Maybe there is a more elegant way.

I've tested the implementation, but I'm pretty sure I haven't covered all the possible cases, so a careful testing is necessary.

Relevant discussions:
https://forum.kde.org/viewtopic.php?f=285&t=131014

Test Plan:
Tests done:

With and without some text in the line edit:
- Double click on category opens it
- Double click on entry launches the software
- Remember program association for mime works
- Run in terminal works
- Keep open terminal works

Reviewers: dfaure, #frameworks, #vdg, ngraham, rkflx

Reviewed By: dfaure, ngraham, rkflx

Subscribers: rkflx, romangg, fabianr, abetts, ngraham, alexeymin, #frameworks

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D8056

M  +138  -24   src/widgets/kopenwithdialog.cpp
M  +2    -0    src/widgets/kopenwithdialog.h
M  +16   -1    src/widgets/kopenwithdialog_p.h

https://commits.kde.org/kio/e3af26bbb1e7dd32a7bb48c615d352416066e238
Comment 20 Nate Graham 2018-04-10 20:44:47 UTC
*** Bug 167424 has been marked as a duplicate of this bug. ***
Comment 21 Nate Graham 2018-04-10 21:50:42 UTC
*** Bug 337264 has been marked as a duplicate of this bug. ***
Comment 22 Nate Graham 2018-04-11 18:43:00 UTC
*** Bug 110871 has been marked as a duplicate of this bug. ***
Comment 23 Nate Graham 2018-04-11 18:43:26 UTC
*** Bug 118799 has been marked as a duplicate of this bug. ***
Comment 24 Nate Graham 2018-04-11 18:45:40 UTC
*** Bug 212030 has been marked as a duplicate of this bug. ***
Comment 25 Nate Graham 2018-04-16 22:01:12 UTC
*** Bug 80355 has been marked as a duplicate of this bug. ***