https://bugs.kde.org/show_bug.cgi?id=440497
--- Comment #4 from Ilya Bizyaev <bizy...@zoho.com> --- (In reply to Nate Graham from comment #3) > What is a use case for a non-nerd who needs to execute terminal commands? > Even if they succeed in running the app in a terminal, the output will be > useless to them, and they will need to involve a nerd anyway. If a nerd is > involved, then we don't need this feature. Right? Both the user and the nerd have limited amount of time and patience, especially if the nerd has to spend time explaining how to start an app from the terminal to every new user whose apps don't launch. Software failures are annoying as is, so if troubleshooting them requires dozens more of annoying steps, a user just gives up and goes back to whatever works for them. Here is an alternative approach to the same problem from the developer of linuxdeployqt: https://github.com/probonopd/appwrapper It has an added advantage of not requiring any special actions from the user, but is not generally reliable: * it only looks for specific errors in English; * does not catch errors that do not lead to app termination. The proposed approach is on-demand, but very versatile. Today I found myself missing this feature again, as the newly installed KDE Itinerary wouldn't launch. I'm obviously a nerd in this story, but even with my fancy shell with autocompletion and syntax highlighting it took me multiple attempts to guess what the binary name for KDE Itinerary is. It turned out that openSUSE's packaging data was missing 3 packages with QML dependencies for Itinerary to work, so I had to repeat the process 3 times. What's more, without those dependencies the app does not terminate, but keeps running in the background. Now, that was my machine, but if I had to help someone get KDE Itinerary running through a Telegram chat I would first need to explain: * How to launch a terminal (search "Konsole" in the application menu, as Ctrl-Alt-T doesn't work for many people) * How to use the terminal window to execute commands * How to interpret the output for incorrect binary names, or how to use the menu editor to find what the correct one is * How to understand if the process is still running or not * How to re-run the previous command with arrow keys * How to kill the broken process It could have easily turned out that they have multiple versions of the app in their system, e.g. from distro's repositories and Flatpak, and we would be troubleshooting the wrong version, just to then find out the menu shortcut still doesn't work. That would take us a while, presuming they would still be willing to use Itinerary/openSUSE afterwards. With this feature, I would tell them to: * Right-click the icon and choose "Open in Terminal" (context menus are an essential skill) * Make a screenshot (basic skill) * Close the window (essential skill) * Repeat Note that power users would also appreciate this, because: * Portable apps downloaded from the web (messengers/proprietary tools/etc.) often miss system libraries, even if they're AppImages * Python-based apps break silently when there are module dependency problems in the system * Wine games crash silently after Wine updates / new libraries in the prefix Searching for and copying long Exec lines or cleaning up ~/.local/share mess are just non-obvious extra steps which could be easily avoided. -- You are receiving this mail because: You are watching all bug changes.
