Written by mydoghasworms the 1 Sep 10 at 05:25.

When an application fails to start, bring up a dialog saying: "[Application Name] failed to start" (perhaps with a return code), with a "More Detail" button. When you click "More Detail", it should show you, in the dialog, the standard output of the application.

When an application fails to start, bring up a dialog saying: "[Application Name] failed to start" (perhaps with a return code), with a "More Detail" button. When you click "More Detail", it should show you, in the dialog, the standard output of the application.

Written by Darwin Survivor the 3 Sep 10 at 06:31.

I propose adding 2 options to the dialog (in addition to the close/etc button).

"Restart Application" would simply restart the application.

"Restart With Error Reporting" would capture the stdout and stderr from the application and generate an "error report" that could be read (for experienced users) or copy/pasted to a new bug report for the application.

I propose adding 2 options to the dialog (in addition to the close/etc button). "Restart Application" would simply restart the application. "Restart With Error Reporting" would capture the stdout and stderr from the application and generate an "error report" that could be read (for experienced users) or copy/pasted to a new bug report for the application.

Written by DaedalusPrime the 5 Sep 10 at 22:19.

This would be similar to solution #2, but would be a single button that would implement the second option every time. It is likely the application will fail for the same reason the second time, so it is reasonable to take the more agressive approach. "Try Again" is also more explicit about what you're doing than simply "restart."

This would be similar to solution #2, but would be a single button that would implement the second option every time. It is likely the application will fail for the same reason the second time, so it is reasonable to take the more agressive approach. "Try Again" is also more explicit about what you're doing than simply "restart."

Written by PaddyLandau the 15 Sep 10 at 09:11.

* When adding an item to the menu, let there be an extra option (on by default) whether option #3 applies.
* If it the option is on, then the solution #3 happens only when the application is launched from the menu, not from anywhere else, and the application fails with a non-zero status within (say) 5 seconds.
* If the option is off, then the current behaviour applies.

This allows you to select programs where you do not want this behaviour to take place.

Rationale for this option:

There is a serious problem, in that the operating system doesn't know whether the application crashed or ended deliberately.

1) There are some applications (admittedly few, often smaller "home-made" scripts) that do not run for a long time and do not require any interaction from the user.

2) How would the operating system know whether the application started and was immediately dismissed by the user? For example, if I start Calculator by accident, and click the close button less than a second later.

* When adding an item to the menu, let there be an extra option (on by default) whether option #3 applies. * If it the option is on, then the solution #3 happens only when the application is launched from the menu, not from anywhere else, and the application fails with a non-zero status within (say) 5 seconds. * If the option is off, then the current behaviour applies. This allows you to select programs where you do not want this behaviour to take place. Rationale for this option: There is a serious problem, in that the operating system doesn't know whether the application crashed or ended deliberately. 1) There are some applications (admittedly few, often smaller "home-made" scripts) that do not run for a long time and do not require any interaction from the user. 2) How would the operating system know whether the application started and was immediately dismissed by the user? For example, if I start Calculator by accident, and click the close button less than a second later. 3) The operating system would have to distinguish between being started from a terminal or not. 4) What about applications that catch themselves? OpenOffice is one that regularly crashes on my system, but it catches itself. In that case, the proposed solution would be a repeated irritation. 5) What about a program that was started from a script, where the script itself catches the crash? I understand the rationale behind the proposal, but this would have to be carefully, very carefully, thought through.

Written by jkltechinc the 21 Sep 10 at 03:47.

The idea is not to just look at how long the application runs for, but to look at the return code for the program. If a program returns 0 it has exited successfully without error. Returning any other number means an error, so the only thing that's needed is to use a wrapper or the like to watch the return codes of things called by anything outside of the terminal (I think that such a dialog appearing from things inside the terminal would be annoying and unproductive for developers and advanced users).

An advantage over using return codes over run time is that this message can also detect crashes and provide error reporting data. When a program crashes or segfaults, it will return a non-zero exit code, so ubuntu would be able to tell if the program ended deliberately or not. If the script is written correctly, then it too will normally return an exit code of 0 when deliberately closed.

A GUI such as the one proposed in solution #1 would work perfectly, and the only other component is a wrapper or some way to read the return codes of applications started from gnome.

The idea is not to just look at how long the application runs for, but to look at the return code for the program. If a program returns 0 it has exited successfully without error. Returning any other number means an error, so the only thing that's needed is to use a wrapper or the like to watch the return codes of things called by anything outside of the terminal (I think that such a dialog appearing from things inside the terminal would be annoying and unproductive for developers and advanced users). An advantage over using return codes over run time is that this message can also detect crashes and provide error reporting data. When a program crashes or segfaults, it will return a non-zero exit code, so ubuntu would be able to tell if the program ended deliberately or not. If the script is written correctly, then it too will normally return an exit code of 0 when deliberately closed. A GUI such as the one proposed in solution #1 would work perfectly, and the only other component is a wrapper or some way to read the return codes of applications started from gnome.

Written by CherryBear the 30 Sep 10 at 22:44.

Rather than a whole new error reporting system, maybe there should be a trigger to open terminal with the details of the error as soon as a program crashes. This way, those Ubuntu veterans out there can figure out the problem their usual way and fix it then and there, rather than having to quote an error code online or something similar.

Rather than a whole new error reporting system, maybe there should be a trigger to open terminal with the details of the error as soon as a program crashes. This way, those Ubuntu veterans out there can figure out the problem their usual way and fix it then and there, rather than having to quote an error code online or something similar.