| rkflx | |
| dfaure | |
| elvisangelaccio | |
| abetts |
| VDG | |
| Frameworks | |
| Dolphin |
This patch adjusts the Open With UI to improve the strings and always display the top app inline, outside of the sub-menu.
This presents the following advantages over the status quo:
| No Linters Available |
| No Unit Test Coverage |
Would it look good also that if there were less handlers and they are presented in the same menu that it goes like this:
Open With
I am talking about right justification instead of
Open With
Gwenview
GIMP
| src/widgets/kfileitemactions.cpp | ||
|---|---|---|
| 663 | This introduce one more so menu can grow with 6 items which is much. Why not keep same approach, but we can show every time the *preferred* one ---------------------------
Open with Gwenview
Open with other application -> { submenu if present others, or ... if not }
--------------------------- | |
| src/widgets/kfileitemactions.cpp | ||
|---|---|---|
| 663 | Hey, I like that idea! | |
@ngraham Thanks for setting me as a reviewer, I try to have a look before Frameworks string freeze on Saturday. Focussing on Apps string freeze today ;)
"Open With..." are quite memorable labels used in Windows, I fear "Open With Application" will take away the recognizability of "Öffnen mit …" in German to "Mit Anwendung öffnen". But I won't object.
I have two questions regarding this "open with" topic.
Is the displayed app the one which is also set as default for this file type or the first alternative (2nd app) ? If it's the default one why should someone make a right click on a file to open it with his/her default app instead of making a single/double click on it?
The second point: Shouldn't the "Open with" stuff be at the very beginning of the menu when we have a file selected for quick access? (1. opening, 2. create new files (for folders), 3. direct file operations, 4. additional file operations, 5. everything else)
It's rather odd that there's no Open item in Dolphin's context menu in the first place, and this patch remedies that. Also, this is a general API, so other clients can potentially benefit from it even when it's not used in a context menu. (e.g. Gwenview could adopt this to make it easier to open images in other apps, where currently the only option is to use a sub-menu)
The second point: Shouldn't the "Open with" stuff be at the very beginning of the menu when we have a file selected for quick access? (1. opening, 2. create new files (for folders), 3. direct file operations, 4. additional file operations, 5. everything else)
I would approve of that. It's what macOS does, FWIW:
As you can see from the above image, macOS doesn't tell you what app will launch in response to the Open action, so this patch would actually represent a usability improvement over that. However, re-ordering the menu would need to be changed in Dolphin, not here in KIO. That change (if we do it) should go into 18.08.0, to make sure that it can rely on this change (if it's accepted).
Looked at this now: The first iterations with the long list of apps and the header were not all that great (in particular for folders the list got much too long), but after @anthonyfieroni's idea I guess the current version is quite good. Showing the default app again at the first level is not that useful (@mmustac also noticed that), but if it helps consistency I'm not against it…
As for adding "Application" everywhere, I agree with @broulik. I don't feel that's necessary to achieve a good flow. Also macOS and Windows are simply using "Open With … Other …", counteracting your work elsewhere to make users from those platforms feel more at home. In general shorter descriptions are faster to read, and for some languages longer descriptions can make the menu almost too wide to still look reasonable. For me the following compromise would work well:
Open With…
Open With Gwenview, Open With…
Open With Gwenview, Open With → Other Application…
Code LGTM.
Not sure how this patch makes access easier?
Open Gwenview → navigate to an image → right-click: no change, Gwenview uses a custom implementation in fileopscontextmanageritem.cpp rather than this nice API, boo
There are two good reasons for this:
I'm not against changing Gwenview to this, but first we'd need to make more space and/or reorganize the long list, which is easier said than done because we cannot lose existing functionality. Solving Bug 211756 is another prerequisite.
This may be different than this patch is intending to address. Let me know if that's the case. Another thing that adds more characters to the menus are the long names that our applications have.
Firefox Web Browser
Gwenview Image Editor
GIMP Image Editor
I feel that users would know better as to the application they want to use. Could the app names be shortened to just
Firefox
Gwenview
GIMP
?
@ngraham I don't see that on my system. Is this a custom Kubuntu patch changing some default again in your screenshot? For Open With the mimetype is well-determined, so showing the longer description interferes more than it helps.
The names are determined entirely by the distro packaging. Ubuntu tends to lengthen the names, e.g. "Firefox Web Browser" instead of just "Firefox".
You probably had your reasons for also changing back Open With → Other Application…, but I guess this way it's fine too. Accepting for now.
If there are no further objections until Thursday (i.e. it's been a week under review in total), I think this can land (because the string freeze does not apply anymore).
I rather prefer Open With → Other Application... myself, and can change it back if folks prefer (I thought you wanted it this way, sorry!).
That's what I reckoned, and even recommended above :)
If you change it, make sure though to wait until the string freeze is over…
I'll leave the string the way it is for now so this can go into Frameworks 5.45, and change it after the string freeze.
+1 from me, other than the inline comment.
| src/widgets/kfileitemactions.cpp | ||
|---|---|---|
| 654 | Please use true rather than menu as 2nd argument | |
Looks good to me. Can you just make sure that kde/applications/konqueror/libkonq/autotests/konqpopupmenutest.cpp still passes after these changes?
I didn't notice that this change also affects the context menu of folders. That doesn't make much sense and just clutters the menu, imho.
Why would I want an "Open with Gwenview" action if 99% of my folders do not contain pictures?