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).
You can tell users to look there when their app crashes.
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.
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.
>Converting the fixme's to trace's/warn's may be a viable option.
I think it would be good if there were semantics behind fixme & warn that users
and developers can rely upon. Random conversion just to quiet messages is not
nice when trying to make apps run. Of course, the pragmatics already lead to
the (useful) FIXME once idiom.
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.
Regards,
Jörg Höhle
