Difference between revisions of "Windows/Console"
< Windows
Jump to navigation
Jump to search
m (cleanup) |
m (cleanup) |
||
| Line 1: | Line 1: | ||
== Windows Console - Blessing or Curse? == | == Windows Console - Blessing or Curse? == | ||
Currently | Currently, Windows Release Builds (1.2.0 and earlier) open a console window in addition to the normal ScummVM GUI window.<br> | ||
This window is '''not''' the drop down debug console (CTRL-D), but the command line DOS style window which shows | 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(). | ||
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> | This page exists to collect the arguments on both sides and to record counterarguments, so that:<br> | ||
a) a decision can be reached on this which all interested developers can be | 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. | 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. | ||
| Line 23: | Line 22: | ||
** 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. | ** 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. | * 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 | * A single log file can easily be over written, 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. | ** 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. | * 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 | * 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. | ||
Revision as of 23:59, 24 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?
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 satisfied 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 written, 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 behavior of GUI only programs, is to return the prompt straight away, if started by a command prompt.