On Mon, Apr 6, 2009 at 3:48 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
Austin English wrote:
I don't think it's safe to assume that stderr will be lost if the program was started from a .desktop file.
The majority of users are double clicking .desktop files to start their applications. Where do you see stderr going to in this case?
It is centralised to $HOME/.xsession-errors (in Ubuntu at least).
Doesn't here. I use wine daily, with several crashes while testing apps and the log contains nothing related to wine.
You can tell users to look there when their app crashes.
Sure we could. But no one does. We tell them to run from a terminal and see what they get. The log will be full of _other_ applications error messages, or other wine applications' messages.
The only bug IMHO -- and it's not in wine -- is that some entity in Gnome or KDE limits output to 200KB and I found no way to reset that. I.e. once this file has grown that large, output is lost until you log out. Obviously this mechanism was not expected to receive as many output as *some* wine apps produce.
Which is why you should run in a terminal and get clean output.
Alternatively, with your desktop's icon/menu editor, you can have a terminal window created for the application when it starts. Then debug output goes there. I once did that for one application which crashed at start from times to times, to get visual feedback.
It's just as easy to launch a terminal itself and do that. Debugging should be done in a terminal, not from a .desktop file.
This winemenubuilder distinction seems superfluous. All it seemingly boils do is that some people plead for a change of wine behaviour to "by default, produce zero output. If you want some, set $WINEDEBUG (since you're in a shell anyway), because the majority of users doesn't care". I don't vote for that, since I value post-mortem analysis. Yet I admit I've been thinking myself about using WINEDEBUG=-xyz for *some* verbose apps which nevertheless work fine: once you've seen the output once, further runs are not interesting anymore.
Like I said, if you're debugging, launch a shell, or edit your shortcut appropriately. The .xsession-errors method is buggy and unreliable at best.
A possible compromise would be to use fixme-all, which would just eliminate fixme messages, which is the vast majority in most cases. Backtraces are still printed, however (though, they are even with -all).