AppChooserDialog: make it more usable
ClosedPublic

Authored by jgrulich on Apr 9 2019, 7:28 AM.

Details

Summary

Add 'open' button so users doesn't need to choose only with double-click and also allow to
open app with enter

New dialog:

Diff Detail

Repository
R838 Flatpak Support: KDE Portal for XDG Desktop
Branch
Plasma/5.15
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 10653
Build 10671: arc lint + arc unit
jgrulich created this revision.Apr 9 2019, 7:28 AM
Restricted Application added a project: Plasma. · View Herald TranscriptApr 9 2019, 7:28 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
jgrulich requested review of this revision.Apr 9 2019, 7:28 AM
jgrulich edited the summary of this revision. (Show Details)Apr 9 2019, 7:31 AM
jgrulich added a reviewer: Plasma.
ngraham added a subscriber: ngraham.Apr 9 2019, 1:14 PM

IMO this should be a single-click UI, with no Open button: since there's nothing useful you can do with a selected item besides opening it, it should always open with a single-click.

IMO this should be a single-click UI, with no Open button: since there's nothing useful you can do with a selected item besides opening it, it should always open with a single-click.

Shouldn't we maybe follow mouse options, whether users prefer single/double click?

IMO this should be a single-click UI, with no Open button: since there's nothing useful you can do with a selected item besides opening it, it should always open with a single-click.

Shouldn't we maybe follow mouse options, whether users prefer single/double click?

No. The rule is that following that setting only makes sense for items that have a real selection state, i.e. you can do something other than opening it when it's selected. If you can't, then it's a button and it should always activate on single-click. This is why toolbar buttons always activate on a single-click even when you have double-click mode activated.

apol added a subscriber: apol.Apr 9 2019, 8:40 PM

What Nate says makes sense to me. Single click should be fine, there's no real value in just selecting it.

Don't we already have another dialog for choosing applications? It could make sense to use the same everywhere and improve it once.
i.e. KOpenWithDialog from KIO::Widgets

+1 for unifying, and I'll admit that I kind of like this one better than the other one which is really complicated and fiddly. With an added search/filter field, this one would be just right.

This revision was not accepted when it landed; it landed in state Needs Review.Apr 10 2019, 7:11 AM
This revision was automatically updated to reflect the committed changes.

Uppps, I accidentaly pushed the change instead running "arc diff". I made it to select app with just a single click as you wanted to, without buttons below.

I'm not sure this will be easy to replace with KOpenWithDialog() as we receive from the portal just list of applications we should present, it's not us who constructs the list of applications which is what the KOpenWithDialog() does if I'm not mistaken.