On Mon, Apr 6, 2009 at 3:48 AM, <[email protected]> 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). -- -Austin
