As per the discussion in https://invent.kde.org/plasma/plasma-integration/-/merge_requests/47 This change that has been merged replaces the open with dialogue with the one used for portals. However, this removes a feature users might depend on: being able to choose a custom binary, e.g. an application you have in your home directory. The current dialogue provides this option. STEPS TO REPRODUCE 1. Use the new portal based open with dialogue 2. Try to specify a custom binary to open a file with OBSERVED RESULT You can't EXPECTED RESULT You can ADDITIONAL INFORMATION Not filing as wish list as this would remove a feature users might depend on in the last supported Qt5 version, which probably will be in use for quite some time on some distributions. Thus not implementing this would make it impossible for these users to choose a custom binary, which they might need to.
IIRC it also lacks an option to choose any installed application (i.e. one doesn't specify this mime type), which is quite a common situation even in the Windows land.
That's not relevant to this bug report, and I can't reproduce it; for me, the portal-based dialog *always* shows all apps in it.
Which app do you use to test this dialog?
UPD: Tested with Telegram, can confirm that there's now a switch next to the search bar to choose between only matching and all installed apps. No need for a separate bug report, after all :)
Yes, that's the expected state of affairs when called from a sandboxed app. When it's called from a non-sandboxed app like Dolphin or Plasma Folder View, it inappropriately shows all apps, not just the default and recommended ones. That's a separate issue: Bug 461165.
Does "portal-based" imply it is something not provided by KDE? I was about to report other issues with this odd dialog.
It's provided by us, by the product of this bug report in fact :) What should the UI for this look like? Writing the code is surely not the problem here.
(In reply to Harald Sitter from comment #7) > It's provided by us, by the product of this bug report in fact :) > > What should the UI for this look like? Writing the code is surely not the > problem here. Personally I think a button at the bottom with something like "Pick program manually" that opens a file chooser. If one doesn't want a button, technically the bottom text with discover could be extended to have a second link doing that, but I would expect that to break in various languages, order wise, so I would prefer it to be separate.
It seems 5.27 got released without this, so if you as a user now need to open a certain file with a custom application, you simply can't.
Oops.
(In reply to Nate Graham from comment #10) > Oops. I'd say this needs fixing urgently, but unfortunately we probably can't within the 27er release, and given there is no 28 and some distributions are probably not going to upgrade to Qt6 based plasma 6, so we are going to be stuck with this for a while :/
(In reply to Christian (Fuchs) from comment #8) > (In reply to Harald Sitter from comment #7) > > It's provided by us, by the product of this bug report in fact :) > > > > What should the UI for this look like? Writing the code is surely not the > > problem here. > > Personally I think a button at the bottom with something like "Pick program > manually" that opens a file chooser. What happens when one has picked a file? Does it just open with that file?
I would rather prefer something similar to the old dialog, where you can directly type a path into the search field and it will use that binary to open the file, and a button to open a file dialog to pick a binary is next to the search field. It is often faster to just type the path directly than to naviigate and pick the binary using a dialog.
Same question for your proposal What happens when one has picked a file or entered the path and hit enter? Does it just open with that file? Or maybe add it to the model? What I don't get btw, why do you have applications that don't have a desktop file? What kind of applications are those? And couldn't they just have a desktop file to begin with? So kickoff/krunner and this dialog have an easier time finding them?
The portal dialog ignores .desktop files in ~/.local/share/applications/
That seems like a separate bug that needs to be fixed, and working around that bug by choosing custom binaries isn't ideal. :)
All entries I have in ~/.local/share were created by the old dialog when adding a custom binary. At I cannot remember I ever wrote a .desktop file by hand :)
(In reply to Harald Sitter from comment #14) > Same question for your proposal > > What happens when one has picked a file or entered the path and hit enter? > Does it just open with that file? I think the old (and imho correct) behaviour was indeed to just call that binary with the path of the file as the first and only argument, yes. > What I don't get btw, why do you have applications that don't have a desktop > file? What kind of applications are those? And couldn't they just have a > desktop file to begin with? So kickoff/krunner and this dialog have an > easier time finding them? A whole fun mixture of "binaries you downloaded" via "binaries you compiled yourself" to "scripts you wrote" etc. pp. In an ideal world every app would have a corresponding .desktop file, yes. But we do not live in this ideal world and, more importantly, we as KDE can't enforce / control it. So to not put users in front of a very-hard-to-resolve problem (writing their own .desktop file, and I know this can technically be done through means such as menu editor, but: they don't) we can just give them a manual override.
I agree that the portal dialog should gain the feature, to achieve parity with the older widgets dialog. I'd very much like the UI for it to be explicit, though; like an Open with terminal command or script" button. The old dialog has a super weird UI that jams the UI to open with a CLI tool into the search field you use for finding GUI apps. This always confused the heck out of me when I had to use it. If I typed "gwenview" and hit enter for example, I never knew if it was opening it with Gwenview (via desktop file) or opening it via its binary and creating a new .desktop file in ~/.local/share/applications for that entry.
Perhaps the "mode" (binary vs. .desktop) could be made more explicit by displaying what the dialog will do somewhere, but I don't want to have to click an extra button or, worse, manually pick a binary with file chooser dialog. With the old dialog, you could hit "open with" in Dolphin, immediately start typing, and hit enter, and you knew that it would do the right thing (at least I have never had any problems with it).
As an addition to the "does it create a .desktop file" if you choose a custom binary: imho either no, as things should be explicit and not implicit, or yes, but only when you check a [x] always open $filetype with this application checkbox of sorts. Because otherwise for the case of temporary binaries (e.g. imagine something you build a new binary under a new path/name for every version) you'll end up with a hard to clean mess of old cruft. Other than that, I am fine with whatever, but I do agree with Nate that an explicit dialogue is nicer. For brevity such as wished by Ilia if we have a keyboard shortcut to open the file chooser it should still be reasonably fast (assuming correct focus so you can shortcut and type)
Thanks to Nate for directing me to the proper bug (I didn't find it via the search, because I looked in dolphin, sorry). I often used the old dialog quite often for starting a database file that required a parameter on the command line. This was super handy since the command line history was saved in Dolphin's config file. So I would just choose the correct one from the dropdown. Krusader still works this way (it has its own history though).
As Plasma 5.27 is the last release of the Plasma 5 series, can't we revert to the old application selector? As others already have said, I often used this feature to test custom binaries, and I don't think adding a custom `.desktop` file for each binary is a feasible solution. Sometimes I just want to process a CSV, or TSV, with a custom binary, and doing it from the interface, with its embed history, specially when I am doing some repeated work is very handy. I truly believe all advancements are proposed and coded with the best intentions and having a regular user in mind. But I can't recall any complaint of how this specific feature works. Never saw any mentions in KDE's reddit or anywhere else. But of course, you as maintainers know better. If I could choose, I'd say to keep both for a while and do some A/B testing, or asking for user feedback. But I know resources and time is limited. Just please consider not limiting it to `.desktop` file. This would be very limiting to mine, and -- as it seems from some comments -- others workflow. Having this as a hard requirement for replacing this component is very frustrating. Is this a feature that could be maintained by volunteers and be replaced desktop-wise for those who prefer the older component? Thanks in advance.
Created attachment 156816 [details] mockup of additional option on open with menu I made a mockup of what could be an additional option on open with menu (not a pro, not even an amateur with Krita) Could that be an option? Having an additional option to open with path that would open a file picker directly? That way, the current portal selector wouldn't need to be changed, and users who rely on the old behavior could keep their workflow.
Rodrigo, I'm starting to come to that conclusion myself. Perhaps the switchover was premature, and we can delay it until we have all the missing features from the old dialog implemented in the new one. I plan to look into this soon.
(In reply to Nate Graham from comment #25) > Rodrigo, I'm starting to come to that conclusion myself. Perhaps the > switchover was premature, and we can delay it until we have all the missing > features from the old dialog implemented in the new one. I plan to look into > this soon. I'd +1 reverting delaying switching over until 6.* which is a major new version and "breaking" changes are less of an issue, plus it will get frequent feature updates, which will make changes easier. Thanks a lot for looking into this :)
(In reply to Christian (Fuchs) from comment #26) > I'd +1 reverting delaying switching over until 6.* which is a major new > version and "breaking" changes are less of an issue, plus it will get > frequent feature updates, which will make changes easier. Thanks a lot for > looking into this :) err, "reverting the switch and delaying ..." of course, sorry, paws faster than brain, sorry for the spam.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/73
This one also needs to be reverted then: https://invent.kde.org/plasma/plasma-integration/-/commit/bc1c5d66828429904ea9820154b72307d26a8529
Yes, it's included in that patch.
Git commit 1ca959de772e949ca8ab55ed41827ea796be1da8 by Nate Graham. Committed on 28/02/2023 at 15:53. Pushed by ngraham into branch 'Plasma/5.27'. Revert "extend kio with portal-based open-with implementation" This reverts commit 8c72d54596afe8e97c7bb96cccb324f24f67b7b0. This reverts commit ae36cf167089b0bf42c29d501e9009b51980b4ec. This work to unify on a single "Open With" dialog implementation is important for the long-term, but it's not ready to be rolled out yet due to missing features in the portal-based dialog that some users currently rely on ("open with arbitrary binary" and "launch the chosen app in a terminal window"). Because the roll-out happened for Plasma 5.27 LTS, the possibility of adding those features soon is unlikely because the next Plasma feature release is 6.0 which is 8+ months way. Let's revert this work for now to un-break users and stabilize the last Plasma 5 LTS version, and then we can work on adding the missing features for Plasma 6.0 and try again then. Related: bug 460741 FIXED-IN: 5.27.3 M +1 -7 CMakeLists.txt M +0 -1 autotests/CMakeLists.txt M +0 -2 src/platformtheme/CMakeLists.txt M +0 -203 src/platformtheme/kdeplatformtheme.cpp https://invent.kde.org/plasma/plasma-integration/commit/1ca959de772e949ca8ab55ed41827ea796be1da8
Lowering priority now that this has been reverted for Plasma 5.27.
Thank you all =) Maybe for Plasma 6 the mockup I made could be taken into consideration. Not necessarily the mockup, but the idea. I think it would be a clear way to separate both concepts, whilst reducing the clutter and confusion on the portal component. And as a bonus, it would allow to those of us who like the ability to quick use a binary path to have a way to do so with fewer steps. Thanks again, and have a nice day =)
*** Bug 466928 has been marked as a duplicate of this bug. ***
When will this be fixed? Is there the possibility to change back to the old dialog in dolphin? I often use it to enter something like "java -jar" or "something %F" or "something %u" (it would be very important to still accept these placeholders). I now have to open konsole for this...
(In reply to H.H. from comment #35) > When will this be fixed? Is there the possibility to change back to the old > dialog in dolphin? I often use it to enter something like "java -jar" or > "something %F" or "something %u" (it would be very important to still accept > these placeholders). I now have to open konsole for this... Likewise. However, more importantly, the commit didn't appear to revert the inclusion of the portal for me in OpenSUSE Tumbleweed. Should it have by now?
Yes. If you're still seeing the portal dialog in non-portal-using apps, please talk to your distro packagers about it. This isn't the place for that, as it's about adding a specific feature to the new portal dialog.
(In reply to Nate Graham from comment #37) > Yes. If you're still seeing the portal dialog in non-portal-using apps, > please talk to your distro packagers about it. This isn't the place for > that, as it's about adding a specific feature to the new portal dialog. Thanks.