Wooo, nested subject lines. This is what I call a Thread!
However, the latest generation of users seem to start their wine experience by point-an-click on an .exe in some filemanager. They won't see the messages sent to stderr. Perhaps we should instead of error message "blabla.exe not accessible from a configured", make this a plain MessageBox() call?
I've thought about this a couple of times now. It's not just for that error, we really need some generic way to report problems and wine output in a totally GUI oriented fashion. OK, so it might not be common *quite* yet, but people will start running Wine from places other than the terminal very soon now.
We have a couple of problems in this area.
Firstly, the output can be misleading/confusing to newbs. Common conversation on IRC:
Them: "My app doesn't work because wine can't open my mixer" Us : "What makes you think it's related to the mixer" Them: "It says err:ossdrv:WAVEOUT could not open mixer" Us : "That's probably not related to your problem."
Secondly, you only get the output if you run from the terminal.
Thirdly, if there is a line that reveals the cause of the users problems, it could be buried amongst huge reams of spew about non-implemented flat scrollbars for instance. This is because we don't distinguish between messages that might help the user, like:
* You need stdole32.tlb for this app to work * Your configuration file is busted * The program crashed because it hit a stub.
from messages that don't help them, like:
* Flat scrollbar/CoSetState/other non-critical fixmes * Warnings/errors about broken apps writing to SEH resource data, mangling surface locks or whatever broken behaviour is in vogue this year.
Basically I think the Wine output should be hidden by default as it's essentially meaningless to anybody but developers (and often, anybody but wine developers).
I would also propose a new class of logging message, or logging macro, USERMSG, which is *only* to be used for things that directly help or inform the user, as opposed to developers. Stuff put in such messages would be low on jargon and high on helpful advice. Developers still have all the other 3 debug channels, winedbg output and so on to help debug a problem if said user/newbie asks for it - for when a friendly wine hacker isn't available, the USERMSG messages might be all they have.
CrossOver already hides the output I'd note, unless you specifically log it. I don't know how they deal with b0rkage.
So, that leaves the question of how to display these USERMSG logs. I'd propose a simple dialog box which contains a graphical list of output. If you've ever seen the Mozilla JavaScript console, something like that. It'd be displayed when the first USERMSG is shown, or on demand via a command line switch or something, as it could be used to filter the log messages at runtime for instance.
Anyway. It's just random brain activity from me. Thoughts? thanks -mike