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