[Scummvm-devel] consoles, warnings, errors and so forth

Max Horn max at quendi.de
Wed Jun 1 17:54:03 CEST 2011


Am 01.06.2011 um 16:44 schrieb Arnaud Boutonné:

> Hi Max, Hi Fuzzie, Hi everybody
> 
> I must admit I consider useful that the user can see warnings (or that we find a way to activate the console on demand).

Wait, which console are you talking about now? The Windows console, or our GUI console? 

If you meant the Windows console: I'd prefer to solve this by having a hotkey on Windows for toggling visibility of the Windows console (with it being hidden by default). For some more details on the idea and how to avoid certain problems with it, see here: <http://wiki.scummvm.org/index.php/Windows/Console#If_a_toggle_is_added_for_opening.2Fclosing_the_console_window_.28showing_all_previous_output.29.2C_users_will_be_dumped_back_to_the_desktop._And_jumping_back_into_ScummVM_can_result_in_further_issues.2C_of_screen_going_out_of_sync_or_crash.2C_with_poor_display_drivers.>

If you meant the GUI console: fuzzie already suggested that we should log warnings there, too, and I kind of agreed. If we also add a global hotkey for that, then this would also help non-Windows users.

Of course, both directions can and IMHO should be pursued simultaneously.


> It helped me several times that the user was able to tell me what he saw just before a problem occurred in the game. I'm not sure I'll be able to have such a detailed explanation if we simply spool everything to a flat file.
> 
> Also, if we switch to a spool file, I don't agree that we should ensure that as few warnings as possible are displayed.

Not sure what gave the impression that we would reduce the number of warnings; but whatever, let me make it clear that of course we should not remove useful warnings. Indeed, right now I have no plans to remove any warnings() whatsoever. Also, I don't really think this should be part of the ongoing "console" discussion.

But since we are at it: We certainly should review the warnings we output; but not to remove them, but rather because we really should handle the problems they warn of better. E.g. some should be promoted to more user-visible GUI dialogs. *Maybe* some should be demoted to debug messages, but right now, I am no aware of any where this strikes me as a good idea. Conversely, some some debug() messages maybe should be promoted to warnings.

By the way, the "spool file" (actually, we call it "log file") already exists and is used :). 

> Maybe we could transform some warnings in debug traces in order to reduce the current number of warnings, but then we should also be able to ask the user to use some debug level and send us the result in order to analyze it.

This is already possible, isn't it? I am not quite sure what your point here is? Maybe you want a GUI dialog for setting the debug level?!?

> Concerning the cut&paste issue, couldn't we fix that by mixing the console and a spool file? This would allow the console ports to have something they don't have currently, and the user could copy & paste for the spool file even if he sees the console

(I'll use the term "handheld device" to avoid a third meaning of console in this thread ;)

I am not completely sure I understand you here, but:
On handheld devices, usually a log file is not created (and even if, the user typically could not access it), and there is no copy & paste. So the only thing we really can do for them is show our built-in GUI console to allow users to photograph the output, as fuzzie suggested. 
On desktop systems, users can copy&paste from the spool file, and they could also read text in the console window (if they open it manually, or if an error() call opened it) according to fuzzie's suggestion.


Hm, that reminds me: If error() is called, we should also allow users to open the log file. So, we could add an "open_log" command (suggestions for better names welcome) which invokes the corresponding OSystem call. Then, error() would print something like this *only to the GUI console, but not the logs, and only on systems that have kFeatureOpenLogInEditor set:
  "To open a full error log, type 'open_log' and then enter"
Variations are possible, like showing a dialog saying
  "ScummVM just experienced a crash. Please report this to the ScummVM team by BLABLA."
and then buttons "Open crash log", "Quit" and "Debug". The first would open the log, but not dismiss the dialog. The middle quits; the last one closes the dialog, leaving the user in the console for further post mortem analysis.


Cheers,
Max



More information about the Scummvm-devel mailing list