winemenubuilder: disable debug output for .desktop files
austinenglish at gmail.com
Mon Apr 6 16:39:57 CDT 2009
On Mon, Apr 6, 2009 at 3:48 AM, <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> 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
More information about the wine-devel