Difference between revisions of "Windows/Console"

From ScummVM :: Wiki
Jump to navigation Jump to search
(→‎Windows Console - Blessing or Curse?: In order to "reach a decision", it must be clear what the alternatives are. Tried to spell my proposal out.)
Line 5: Line 5:
This window is '''not''' the drop down debug console (CTRL-D), but the command line DOS style window which shows stdout messages i.e. debug() and warning().
This window is '''not''' the drop down debug console (CTRL-D), but the command line DOS style window which shows stdout messages i.e. debug() and warning().


There is a perennial argument as to whether this is a good or a bad thing, mainly with respect to novice Windows users?
There is a perennial argument as to whether this is a good or a bad thing, mainly with respect to novice Windows users-


This page exists to collect the arguments on both sides and to record counterarguments, so that:<br>
The following alternative has been proposed: Do not show this console window by default, but only show it when explicitly requested by the user (e.g. via a command line switch, a setting in the GUI, or possibly even a hotkey). In addition, when ScummVM is launched from a console, then that console would not be hidden or affected in any other way by ScummVM. That is, the only difference in behavior would be apparent in the case that ScummVM is started via the GUI (e.g. via the Start menu, by double clicking scummvm.exe, etc.).
a) a decision can be reached on this which all interested developers can be satisfied with.<br>
b) the reasons and arguments for the decision can be minuted, such that the perennial argument can be avoided in the future, unless the reasons given here can be shown to have evolved.


Log files can be used instead of the console window, which can be erased every time ScummVM starts. Ideally, we could have a "Submit" button which the user can click on to submit unknown checksums.
This page exists to collect the arguments on both sides and to record counterarguments, so that:
# a decision can be reached on this which all interested developers can be satisfied with;
# the reasons and arguments for the decision can be minuted, such that the perennial argument can be avoided in the future, unless the reasons given here can be shown to have evolved.
 
Independently of how this is resolved, log files should be introduced, which could be erased (or rotated) every time ScummVM starts. Console messages which the user really should see should be modified to use other means (this is also important for the many ports that have no way to show a DOS console). Typically by showing a GUI dialog. For the specific case of unknown MD5 checksums, we ideally would even have a "Submit feeback" dialog which could semi-automate submissions of unknown checksums (e.g. by sending an email, or opening a pre-filled email in the user's email client, etc.), at least on desktop operating systems.


== Pros (Arguments For Hiding The Console Window) ==
== Pros (Arguments For Hiding The Console Window) ==

Revision as of 15:18, 25 October 2010

Windows Console - Blessing or Curse?

Currently, Windows Release Builds (1.2.0 and earlier) open a console window in addition to the normal ScummVM GUI window.

This window is not the drop down debug console (CTRL-D), but the command line DOS style window which shows stdout messages i.e. debug() and warning().

There is a perennial argument as to whether this is a good or a bad thing, mainly with respect to novice Windows users-

The following alternative has been proposed: Do not show this console window by default, but only show it when explicitly requested by the user (e.g. via a command line switch, a setting in the GUI, or possibly even a hotkey). In addition, when ScummVM is launched from a console, then that console would not be hidden or affected in any other way by ScummVM. That is, the only difference in behavior would be apparent in the case that ScummVM is started via the GUI (e.g. via the Start menu, by double clicking scummvm.exe, etc.).

This page exists to collect the arguments on both sides and to record counterarguments, so that:

  1. a decision can be reached on this which all interested developers can be satisfied with;
  2. the reasons and arguments for the decision can be minuted, such that the perennial argument can be avoided in the future, unless the reasons given here can be shown to have evolved.

Independently of how this is resolved, log files should be introduced, which could be erased (or rotated) every time ScummVM starts. Console messages which the user really should see should be modified to use other means (this is also important for the many ports that have no way to show a DOS console). Typically by showing a GUI dialog. For the specific case of unknown MD5 checksums, we ideally would even have a "Submit feeback" dialog which could semi-automate submissions of unknown checksums (e.g. by sending an email, or opening a pre-filled email in the user's email client, etc.), at least on desktop operating systems.

Pros (Arguments For Hiding The Console Window)

  • Most Windows applications do not display a console window.
  • Unknown games can be reported with a nice popup GUI window, and the game checksums in question can be exported to a file, which the user can copy and paste to a bug report
  • Sometimes, when ScummVM crashes unexpectedly, the program exits completely, and the user loses the error in question. This doesn't happen with a log file.
  • Users need to restart ScummVM, to get more feedback, when bugs or issues occur and they haven't copied/pasted the relevant information from the console, and might not even be able to reproduce the bug/issue.

Cons (Arguments Against Hiding The Console Window

  • How do we report unknown games, or games with missing files to users?
  • Many of the current warnings (i.e. loading related, missing code or features) in source code, can provide useful feedback to users.
    • I disagree, most users don't care about the warnings that we throw. Most warnings are very confusing/cryptic for the user anyway, and the critical ones should be replaced with some sort of GUI popup, when possible - Md5
  • If a known issue occurs, but isn't suitable for GUI feedback, then users lose that information.
    • For example: Original bugs in games based of AGOS game engine, can cause a few wait timeouts, which can make ScummVM appear as locked up.
      • Yes, but noone notices the console in this case anyway - Md5
  • A single log file can easily be overwritten, if a user relies solely on logs for reporting bugs or issues. This is exactly the same situation with console windows, though.
    • Multiple logs would lead to more confusion, about which file to submit, if that method was used.
  • If a toggle is added for opening/closing the console window (showing all previous output), users will be dumped back to the desktop. And jumping back into ScummVM can result in further issues, of screen going out of sync or crash, with poor display drivers.
    • Hiding a window is a standard procedure in Windows. If a user has such a badly broken graphics driver, then this will be the least of his problems, nothing will work properly - Md5
  • The current option is inconsistent, when starting directly (no console), compared to starting via a command prompt (console used, and prompt not returned). The standard behavior of GUI only programs, is to return the prompt straight away, if started by a command prompt.
    • This already happens with the currently submitted patch by m_kiewitz - Md5
    • note: my patch does not change the application type to GUI, so cmd.exe will wait currently for ScummVM to end, also console output will still be shown in that case and console window won't get hidden as well - m_kiewitz

Why is this pro/con hiding only? There is also the possibility of just showing the console, when its actually needed (error in game or md5 for unknown game etc.) - m_kiewitz