>It is incredibly common to troubleshoot application problems by launching them in a terminal window to grab detailed logs.


Not common enough to warrant a context menu entry. A few nerd requests sure, but 
it's so easy to do if you need it.

No, the goal is explicitly to make it possible to support non-nerd users who find it challenging to manually execute terminal commands.

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?

(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.

I agree with you that this is a problem. I think that appwrapper product is a better idea than your proposed solution though. :) If an app doesn't launch, it is much more user-friendly for it to display a dialog box that has error messages you can do a web search for. Would yo be okay using this bug report to track something like that?

Hmm, I think that's better tracked separately then. I'm really not sure if it's even possible to implement something like that reliably, and it would of course require much more effort than a context menu item...

Besides, of the 2 example situations I mentioned here, neither would be solved by the appwrapper approach.

Sure they could: the app fails to launch, it shows a dialog box with an error message in it, and the box could have a button in it or whatever that shows the full command-line output.

Well, in the first case Dolphin didn't crash, it just printed an error message to stdout and kept running.

In the second case Itinerary remained running in the background, despite failing to display a window.

As long as the apps keep running, there's nothing such a wrapper can detect...

In both of those cases, we should just fix the relevant bugs. Showing the terminal output to the user is not going to help them figure out what is going on. Showing it to a nerd might, but a nerd already knows how to launch an app from the terminal. I don't see the win here, sorry.

(In reply to Nate Graham from comment #9)
> we should just fix the relevant bugs.
Oof, this statement has multiple bold assumptions, I'm not exactly sure which though.
* Not only KDE software has such bugs, and you can't fix all such bugs in the world :)
* Not only nerds are capable of reporting bugs. Such bugs will reappear, appear in different shapes and forms and apps and distros, and will all need to be reported first (which takes effort), then fixed (which takes time). For an app like Itinerary which is supposed to help you plan travel time, a user might not have enough time before the travel to wait for a packaging fix from openSUSE, while they are perfectly capable of getting a simple solution immediately if they provide the logs.

> Showing it to a nerd might, but a nerd already knows how to launch
> an app from the terminal. I don't see the win here, sorry.
Ok, let me make this personal then: I like helping people to get KDE software working for them, but I hate that troubleshooting sessions have to be so frustrating when there is no real underlying reason for them to be. Having output collection done by users (without my step-by-step explanations) would save me lots of time and nerves, that's my big win here.

Then there's not only me, not only KDE software, not only this use case... I think I've already explained this.

I get all that, and I'm not totally unsympathetic because I've done user support both informally and professionally for over 20 years. However it seems to me like your suggestion falls in that awkward valley of being so specific that it's easy to shoot down because it has obvious flaws, but not ambitious enough to actually solve the problem. :) So I think we need to re-focus along one of two axes:

1. Be more ambitious so that we actually generically solve the problem or a lack of information. This would be like a supercharged version of the appwrapper project.

2. Do the boring annoying work of investigating and fixing each individual bug encountered that pertains to KDE software or other software within our sphere of influence (e.g. openSUSE packaging)

Both of these would actually *solve* a problem. Your suggestion would not, it would simply make it easier for users gather information when directed by a nerd in preparation for solving it, at the cost of cluttering up the UI.

Because that UI clutter is the principal objection, how about a compromise: when you launch an app while holding down some combination of modifier keys, it automatically invokes the "launch in terminal" mode. This would be easy for you to tell to users for debugging purposes, while not cluttering up the UI for people who are not experiencing any bugs. What do you think?

(In reply to Nate Graham from comment #11)
> I get all that, and I'm not totally unsympathetic because I've done user
> Because that UI clutter is the principal objection, how about a compromise:
> when you launch an app while holding down some combination of modifier keys,
> it automatically invokes the "launch in terminal" mode. This would be easy
> for you to tell to users for debugging purposes, while not cluttering up the
> UI for people who are not experiencing any bugs. What do you think?

This is something I considered myself, and yes, that would work well! Maybe it's also possible to e.g. only display this option in the context menu if it was invoked while holding down Shift (Windows has something similar for power actions in their menu).

Would be nice if it was possible to implement this in a single central place; maybe in kdeinit5?

kinit is removed for kf6 and I see this going nowhere.

If somebody wants to have that, a merge request with some proposal is needed, I don't see a wide demand for that.

I would prefer this feature request to stay open, perhaps in a different component. "Not going anywhere [at the moment]" might not be enough of a reason to close the ticket when other feature request take decades before being worked on.

(In reply to Ilya Bizyaev from comment #15)
> I would prefer this feature request to stay open, perhaps in a different
> component. "Not going anywhere [at the moment]" might not be enough of a
> reason to close the ticket when other feature request take decades before
> being worked on.

Our bugzilla is not aimed to just collect all ideas for eternity. Close to 2 years nothing happened, if you want to have it, please provide a patch, otherwise accept that there is no interest. I fail to see the use case of this for 99% of our users, too, including myself.

(In reply to Christoph Cullmann from comment #16)
> Our bugzilla is not aimed to just collect all ideas for eternity.

2 years is far from eternity :) If you think that it's generally a good idea to close old feature requests, then I'm sure you can find much older ones to start with.

> I fail to see the use case of this for 99% of our users, too, including myself.

Have you read the reasoning above? Part of the reason I feel discontent with this being closed is that I believe my explanation above to be fairly detailed.

I think the explained use case is detailed and the proposal makes sense. Moving to KIO which is where we'd want to implement it.

And FWIW this is something I've thought would be handy myself on multiple occasions; I may try to implement it soon.

Would it perhaps make sense to have that just as an action in the 'edit application' dialog? e.g. to start the application with the current set stuff? Then one can try that very easily and it is hidden enough to not annoy the average user?

That already exists; it's the "Open in Terminal" checkbox on the advanced page of the Properties dialog. There are a few reasons why I think this isn't good:
1. It's a permanent option, not a one-time thing (so you'll forget to unset it)
2. It takes many clicks to access and walking someone through how to do it is very difficult

So it's not very useful for quickly troubleshooting once why something won't launch or is behaving strangely, which are the use cases Ilya mentions.

(In reply to Nate Graham from comment #21)
> That already exists; it's the "Open in Terminal" checkbox on the advanced
> page of the Properties dialog. There are a few reasons why I think this
> isn't good:
> 1. It's a permanent option, not a one-time thing (so you'll forget to unset
> it)
> 2. It takes many clicks to access and walking someone through how to do it
> is very difficult
> 
> So it's not very useful for quickly troubleshooting once why something won't
> launch or is behaving strangely, which are the use cases Ilya mentions.

To avoid to have to set that permanently I would have proposed to just have a button there to launch the app with the current settings once. But ok, if you think that is too complex, then that is no option.