Hi Max,<br><br>I'm sorry this is kind of unrelated, but it looks to me as if scummvm doesn't have a centralized logger system. I mean a class that manages where to publish the log entries. By the last mails it looks to me as if every error has to be handled independently instead of in a similar way.<br>
<br>I'm asking because I think a central log class in which you publish a message and level of logging and the class itself handles where the message should be displayed (debug console, GUI, logfile, etc) could come in handy if it could be supported on all ports.<br>
<br>I'm building a mostly general logging facility in c++ for one of my projects right now. If you consider there is a problem and this proposal a good solution I'd be glad to adequate the code to scummvm and submit it.<br>
<br>Hope to hear from you soon,<br>Miguel<br><br><div class="gmail_quote">2011/6/5 Max Horn <span dir="ltr"><<a href="mailto:max@quendi.de">max@quendi.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As a follow up, some more thoughts:<br>
<br>
<br>
I just did a quick test; if I run<br>
  ./scummvm -emt32 monkey2<br>
ScummVM works for me (I have everything set up right). If I remove the MT-32 control ROMs, though, I get an error on the console, but otherwise ScummVM exits silently. Bad. The funny thing is, the MT-32 emu even tries hard to paint an error message into the window, but since it bails out immediately, this is no good.<br>

<br>
This suggests two changes: First, we should modify the MT-32 emu to return an error code instead of calling error(), if it fails to instantiate. So that can fall back to another MIDI driver or at least show a nice error dialog.<br>

<br>
Second, error() is quite annoying if there is no debugger console setup. I.e. if no game is running resp. if the game is starting and so has not yet setup an error console. This ties in with the other recent discussion about logs and how to report errors. We should do something about this. Several ways come to mind:<br>

<br>
a) While no console has been setup, we should install an error handler that shows a GUI dialog with the error text. Of course that can only be done if at least the GUI has been setup correctly, so it can't be used for errors very early in the startup process. It may also be problematic if out-of-memory was the error cause.<br>

<br>
b) Alternatively, we ensure that there is always an active console instance. This would require some changes to the console code, but might be useful in general, too. So, we would further separate the code that handles console commands from the presentation code.<br>

<br>
c) We add an OSystem API displayAlert() or so, which tries to use OS functionality to show the error dialog. At least on desktop systems, and most phones, I would imagine that works well. For consoles, e.g. NDS, it could just paint the text into the screen surface, like the MT-32 emu does right now.<br>

<br>
<br>
<br>
<br>
Bye,<br>
<div><div></div><div class="h5">Max<br>
------------------------------------------------------------------------------<br>
Simplify data backup and recovery for your virtual environment with vRanger.<br>
Installation's a snap, and flexible recovery options mean your data is safe,<br>
secure and there when you need it. Discover what all the cheering's about.<br>
Get your free trial download today.<br>
<a href="http://p.sf.net/sfu/quest-dev2dev2" target="_blank">http://p.sf.net/sfu/quest-dev2dev2</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</div></div></blockquote></div><br>