<div class="im">>>On Sun, Jun 5, 2011 at 1:14 PM, Miguel Bernabeu <<a href="mailto:mukik182@gmail.com">mukik182@gmail.com</a>> wrote:<br>
>> Hi Max,<br>
>><br>
>> I'm sorry this is kind of unrelated, but it looks to me as if scummvm<br>
>> doesn't have a centralized logger system. I mean a class that manages where<br>
>> to publish the log entries. By the last mails it looks to me as if every<br>>> error has to be handled independently instead of in a similar way.<br>
>><br>
<br>
</div>> Since error handling is more than just  error displaying that is<br>> pretty much clear. And a central logger doesn't really sound like it<br>
> would make handling the error any easier, except if by "handling" you<br>
> mean "displaying it to the user and quit when he noticed".<br><br>Yes, I wasn't referring to error handling but to the problem of no error message being seen by the user and thus no report and maybe sense of lack of care. I consider error handling and error reporting two separate subjects related only in that all errors should be reported in one form or another.<br>

<div class="im"><br>
>> I'm asking because I think a central log class in which you publish a<br>
>> message and level of logging and the class itself handles where the message<br>
>> should be displayed (debug console, GUI, logfile, etc) could come in handy<br>
>> if it could be supported on all ports.<br>
>><br>
<br>
</div>> We have the debug*, warning, error functions which print to both<br>
> stdout/stderr and our log file. error in fact also prints to the<br>
> ingame debug console. In case of debug we also have debug levels and<br>
> debug channels.<br>
<br>I wasn't completely sure of how was the logging managed, I supposed you had some functions but didn't know how you did it.<br><br>
> It shouldn't be too much effort to extend debug/warning to also print<br>
> the debug messages to the ingame debug console, if there is any.<br><br>Extending those functions is mainly what I would accomplish with the central system. You could have done the logging in several ways, some of them non-extensible or at least not easily. That was the main reason for me to ask.<br>


<br>
> Anyway this gets pretty much off topic.<br><br>I agree. I'm now informed, thank you very much<br><br><div class="gmail_quote">2011/6/5 Johannes Schickel <span dir="ltr"><<a href="mailto:lordhoto@gmail.com">lordhoto@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Sun, Jun 5, 2011 at 1:14 PM, Miguel Bernabeu <<a href="mailto:mukik182@gmail.com">mukik182@gmail.com</a>> wrote:<br>

> Hi Max,<br>
><br>
> I'm sorry this is kind of unrelated, but it looks to me as if scummvm<br>
> doesn't have a centralized logger system. I mean a class that manages where<br>
> to publish the log entries. By the last mails it looks to me as if every<br>
> error has to be handled independently instead of in a similar way.<br>
><br>
<br>
</div>Since error handling is more than just  error displaying that is<br>
pretty much clear. And a central logger doesn't really sound like it<br>
would make handling the error any easier, except if by "handling" you<br>
mean "displaying it to the user and quit when he noticed".<br>
<div class="im"><br>
> I'm asking because I think a central log class in which you publish a<br>
> message and level of logging and the class itself handles where the message<br>
> should be displayed (debug console, GUI, logfile, etc) could come in handy<br>
> if it could be supported on all ports.<br>
><br>
<br>
</div>We have the debug*, warning, error functions which print to both<br>
stdout/stderr and our log file. error in fact also prints to the<br>
ingame debug console. In case of debug we also have debug levels and<br>
debug channels.<br>
<br>
It shouldn't be too much effort to extend debug/warning to also print<br>
the debug messages to the ingame debug console, if there is any.<br>
<br>
Printing directly to some GUI is also not always possible, mostly in<br>
case it's debug messages from the sound thread (i.e. some audio<br>
driver, audio stream etc. code). Since the code is run from another<br>
thread it can not access the graphics functionality, since for example<br>
backends like Android or in generally most OpenGL based backends, do<br>
only allow to access OpenGL functionality from the thread where the<br>
OpenGL context was initialized.<br>
<br>
Anyway this gets pretty much off topic.<br>
<font color="#888888"><br>
// Johannes<br>
</font></blockquote></div><br>