State reporting (was: Re: Major FUD (was Re: Add root drive mapping to default config file))

[Mike Hearn]

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

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center