Henri Verbeet hverbeet@codeweavers.com writes:
Note that personally I don't think it's appropriate for "winediag" to abuse the __WINE_DBCL_ERR debug class for diagnostic messages.
Nothing says that winediag messages have to be ERR. If it's not an important failure that all users have to see, it can be a WARN or a TRACE. The hypothetical diagnostic GUI tool can then display those differently.
On 7 September 2010 11:23, Alexandre Julliard julliard@winehq.org wrote:
Nothing says that winediag messages have to be ERR. If it's not an important failure that all users have to see, it can be a WARN or a TRACE. The hypothetical diagnostic GUI tool can then display those differently.
Things like not using direct rendering, or using a software renderer indicate a badly configured system most of the time, but aren't necessarily wrong or fatal. In that sense winediag messages would always be WARNs, because real errors or FIXMEs would go to the regular debug channels anyway. But then no regular user is going to see them unless they use the non-existent GUI. I think ERR should be reserved for real errors, so that e.g. triggering ERRs in the tests would be equivalent to introducing failures. Most of the time that's already true, but there are places that use ERR for things like invalid values passed by the application, that really don't deserve more than a WARN.
Henri Verbeet hverbeet@gmail.com writes:
On 7 September 2010 11:23, Alexandre Julliard julliard@winehq.org wrote:
Nothing says that winediag messages have to be ERR. If it's not an important failure that all users have to see, it can be a WARN or a TRACE. The hypothetical diagnostic GUI tool can then display those differently.
Things like not using direct rendering, or using a software renderer indicate a badly configured system most of the time, but aren't necessarily wrong or fatal. In that sense winediag messages would always be WARNs, because real errors or FIXMEs would go to the regular debug channels anyway.
There is still a need for ERR with winediag, for cases where you can reliably detect the error. Software rendering is more of a heuristic that something might be wrong, so a WARN would be appropriate. But for instance if you fail to load libjpeg when the app gives you a jpeg file this can be an ERR, because at that point you are 100% sure the failure will happen. Of course you could print the ERR to the regular channel, but then most users wouldn't see it, because even once we have the hypothetical GUI I don't think we want to have it display all errors, that would be too much noise.
-
Alexandre Julliard -
Henri Verbeet