Difference between revisions of "Windows/Console"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Created Basic Framework for "Windows/Console" Page)
 
(Added Kirben's Cons Arguments)
Line 16: Line 16:
* Most Windows applications do not display a console window.
* Most Windows applications do not display a console window.


== Cons (Arguments For Showing The Console Window ==
== Cons (Arguments Against Hiding The Console Window ==


* Displays debug() and warnings() useful for bug reports.
* 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.
* 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.
* Users need to restart ScummVM, to get more feedback, when bugs or issues, and might not even be able to reproduce the bug/issue.
* A single log file can easily be over writen, if a user relies solely on logs for reporting bugs or issues.
** 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.
* 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 behaviour of GUI only programs, is to return the prompt straight away, if started by a command prompt.

Revision as of 23:50, 24 October 2010

Windows Console - Blessing or Curse?

Currently (2010-10-25), Windows Release Builds 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?

This page exists to collect the arguments on both sides and to record counterarguments, so that:
a) a decision can be reached on this which all interested developers can be satisifed with.
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.

Pros (Arguments For Hiding The Console Window)

  • Most Windows applications do not display a console window.

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.
  • 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.
  • Users need to restart ScummVM, to get more feedback, when bugs or issues, and might not even be able to reproduce the bug/issue.
  • A single log file can easily be over writen, if a user relies solely on logs for reporting bugs or issues.
    • 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.
  • 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 behaviour of GUI only programs, is to return the prompt straight away, if started by a command prompt.