(*** This bug was imported into bugs.kde.org ***) Package: general Version: KDE 2.1.2 Severity: normal Installed from: Red Hat Linux 7.1 Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) OS: Linux 2.2.17-8smp i686 OS/Compiler notes: If an application launched finishes without opening any windows on screen the console output should be displayed. This allows: 1. Better troubleshooting for GUI applications that fail and log bugs to the command line 2. The use of command line utilities from the run menu application links etc. (Submitted via bugs.kde.org) (Called from KBugReport dialog. Fields Application manually changed)
You can use the "Run in terminal" checkbox to achieve this.
You can, but users need to know that running in the terminal will show command line output which will be useful for them to diagnose the problem. Hence `run in terminal', while showing console output, isn't really the best solution for end users. That said, I entered this `bug' report a while ago, but I think its more of a feature request. Could this be reopened and marked as a feature request?
Er, new users. Not end users. Cheers Waldo :^)
Yes, but how do you know that an application will not create a window? The only way of doing that would be to cache the application's output regardless and if the window is not shown (until when?), then show the output. That requires a bit more of processing than normally. Besides, there's also the case you don't want to see any output. How about a compromise: show a hint if no window was created after a certain time, telling that the application might have crashed or options may have been missing, and explaining how to obtain a terminal. Of course, with a "Don't ask me again" option.
Indeed, you'd cache the output of launched apps - and as you've pointed out, there would be a small load associated with this, hence this behaviour should be user configurable. Your idea of showing a hint after a reasonable timeout sounds good.
Probably kwin or kicker should do that. We already have the launch feedback in kicker.
This is nonsense, way too difficult to implement, and not really needed, if you ask me. There's a checkbox or .desktop file entry for CLI apps, and the output is logged in ~/.xsession-errors. Code for detecting when to show it would probably need crystal ball.
Not nonsense. Difficult or impossible to implement, maybe. But when I press alt-f2, type kmail, and nothing happens, repeatedly, I don't know what to do. This is how many users (especially newbies) must feel. So I fallback on opening up a konsole, and typing kmail. Then it works fine. I close it and try again from alt-f2 and this time it works. How will I ever realize that applications are randomly crashing because I'm out of system memory? (And opening konsole is really not a solution at all). It's very aggravating when something doesn't start and I have to open konsole to find out why. Am I out of memory? Is my configuration file corrupt? Did my memory develop bad sectors and cause a signal 11? Did the files get mismatched when I updated my CVS last? On a side note, it's also very aggravating when something eats up all my memory and applications start randomly disappearing off of my desktop with no notification whatsoever (thankfully I finally realized the cause of this being out of memory).
> On a side note, it's also very aggravating when something eats up all my > memory and applications start randomly disappearing off of my desktop with > no notification whatsoever (thankfully I finally realized the cause of this > being out of memory). On that, there are many causes. One could simply be that your kernel's OOM killer has started killing processes. Therefore, the processes receive SIGKILL and there's nothing that can be done. Another reason is that memory allocation failed for whatever reason. Memory allocation for small chunks is not checked in KDE code (new throws an except which is not caught anywhere). If you really are out of memory, your swap must be in high activity. Even if we can catch those problems, there's no way of knowing if we can map a window and show "out of memory" or run drkonqi.
> Code for detecting when to show it would probably need crystal ball. Not really. You have the Launch Feedback which knows when the window has opened, right? And if nothing happens within a certain timeout period, the feedback stops. This same code can be reused: when the window opens, the cache is discarded; if nothing happens within timeout (it can be the very same timeout) show window with output on stdout+stderr. Would it be really that hard to pipe stdout and stderr for all apps started from menus and Alt+F2 to /tmp/appname.something ???
*** This bug has been confirmed by popular vote. ***
*** Bug 17903 has been marked as a duplicate of this bug. ***
Rather - Attempt to make the programs work better without failing - Learn to type the proper commands or use the shiny *click* *click* interfaces The feature could popup windows also when they are not needed meaning useless spam. Distinguishing important from unimportant would be hard. If you got something that might fail, run it from console... Just my .02$
Responding to Anlar: - Programs won't always work perfectly all the time. - Learning to type 'firefox' versus click on 'firefox' doesn't constitute learning. Nor is typing more 'proper' than clicking. Anlar, you seem to be suggesting the user should know in advance if his program is going to fail. How will the user know that? - There is no spam issue, because the console output would be shown only if the program generates no windows.
*** Bug 253653 has been marked as a duplicate of this bug. ***
Duplicated wish #253653 has also input and error functionality requested
>If an application launched finishes without opening any windows on screen the console output should be displayed. This is not the job of kwin. We're not doing this.