Open main menu

Difference between revisions of "Windows/Console"

2,154 bytes added ,  13:40, 26 October 2010
Fix formatting, add comments.
(/* 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 start)
(Fix formatting, add comments.)
Line 23: Line 23:
=== Pros (Arguments for "Hiding The Console Window") ===
=== Pros (Arguments for "Hiding The Console Window") ===


* Most Windows applications do not display a console window. It is hence confusing for users.
==== Most Windows applications do not display a console window. It is hence confusing for users. ====
: Commercial programs, and stable programs don't usually display a console window. But beta programs, which rely on feedback from users, often leave the console open. Our release testing of ScummVM is seriously lacking, meaning we heavily rely on feedback from the release versions, for wider testing of games now. [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
: Commercial programs, and stable programs don't usually display a console window. But beta programs, which rely on feedback from users, often leave the console open. Our release testing of ScummVM is seriously lacking, meaning we heavily rely on feedback from the release versions, for wider testing of games now. [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
:: ScummVM releases are not betas, however, period. Moreover, if you think our testing is lacking, then please help us come up with ways to improve it. But showing a console will fix nothing. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)  
:: ScummVM releases are not betas, however, period. Moreover, if you think our testing is lacking, then please help us come up with ways to improve it. But showing a console will fix nothing. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)  
::: I still class ScummVM as beta, because our release testing only seems to get worse with each release. The last major release focused testing only on certain games, and the majority of games passed, without any regression testing at all. More thorough release testing, simply takes more time, and there are no easy solutions. [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)
: I don't see how an extra console window appearing in the background, suddenly confuses users either. [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
: I don't see how an extra console window appearing in the background, suddenly confuses users either. [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
:: Well, you are hardly a regular user, and devs often don't see things as problematic that "normal" users do. But you are right in so far as that we are essentially uttering believes here. So, we should run a poll among our users to determine what they think about the console window, and what they would prefer. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)  
:: Well, you are hardly a regular user, and devs often don't see things as problematic that "normal" users do. But you are right in so far as that we are essentially uttering believes here. So, we should run a poll among our users to determine what they think about the console window, and what they would prefer. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)
* Many users requested this over the years  
==== Many users requested this over the years ====
: My guess in fact is that many more want this than have reported it, simply because the threshold to reporting this nuisance is relatively high. --[[User:Fingolfin|Fingolfin]] 15:24, 25 October 2010 (UTC)
: My guess in fact is that many more want this than have reported it, simply because the threshold to reporting this nuisance is relatively high. --[[User:Fingolfin|Fingolfin]] 15:24, 25 October 2010 (UTC)
: Incorrect, we have only had two feature requests (#1093939 in 2005 and #3093800 in 2010), and two short topics (2879 and 9486) over the many years [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
: Incorrect, we have only had two feature requests (#1093939 in 2005 and #3093800 in 2010), and two short topics (2879 and 9486) over the many years [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
:: You are right, there were only a few FRs (though there is also feature request #552494 from 2002, closed by Ender). However, I still believe that many more users are (slightly, at least) annoyed by this. Again, a poll would help to determine what users really want. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)
:: You are right, there were only a few FRs (though there is also feature request #552494 from 2002, closed by Ender). However, I still believe that many more users are (slightly, at least) annoyed by this. Again, a poll would help to determine what users really want. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)
* No vital or important messages for the user should be displayed on the console alone anyway; if the user needs to know about something, we must show this via e.g. a GUI dialog or an overlay message. Hence there should be no need to show it by default (any cases where important information is only visible on the console are BUGS and should be reported and fixed).
::: No, any internet poll would only cover a small amount of users. Don't turn this into another pointless online petition. [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)
==== No vital or important messages for the user should be displayed on the console alone anyway; if the user needs to know about something, we must show this via e.g. a GUI dialog or an overlay message. Hence there should be no need to show it by default (any cases where important information is only visible on the console are BUGS and should be reported and fixed). ====
: There is still a lot of vital information (i.e. loading related problems), that is only shown via warnings in the current source code of game engines though. [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
: There is still a lot of vital information (i.e. loading related problems), that is only shown via warnings in the current source code of game engines though. [[User:Kirben|Kirben]] 23:22, 25 October 2010 (UTC)
:: Name concrete examples, please. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)
:: Name concrete examples, please. --[[User:Fingolfin|Fingolfin]] 09:13, 26 October 2010 (UTC)
:::Just do a grep (or Agent Ransack on Windows) for all warnings in the source code of the game engines. There are several warnings in sword1/2 game engines, related to load failures or unexpected data (i.e. corrupt files). [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)


=== Pros (Arguments for logging to a file) ===
=== Pros (Arguments for logging to a file) ===
Line 47: Line 50:
=== Cons (Arguments against "Hiding The Console Window") ===
=== Cons (Arguments against "Hiding The Console Window") ===


==== How do we report unknown games, or games with missing files to users? ====
==== How do we report unknown game versions, or games with missing files to users? ====
: Via a GUI dialog. --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC)
: Via a GUI dialog. --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC)
* Users need to restart ScummVM, to get more feedback on non-critical issues, and might not even be able to reproduce the bug/issue.
:: And how do we handle mass adding of games? which usually provides too much output for GUI display, and is more frequently used now. [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)
 
==== Users need to restart ScummVM, to get more feedback on non-critical issues, and might not even be able to reproduce the bug/issue. ====


==== Many of the current warnings (i.e. loading related, missing code or features) in source code, can provide useful feedback to users. ====
==== Many of the current warnings (i.e. loading related, missing code or features) in source code, can provide useful feedback to users. ====
Line 56: Line 61:
:: Any warnings related to failing when loading the data files, due to corrupt or missing files. Even warnings about missing code or features, or code points which need to be triggered. Many warnings of these types still exist in the current source code of the game engines, although they should be converted to errors or GUI dialog in the future. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
:: Any warnings related to failing when loading the data files, due to corrupt or missing files. Even warnings about missing code or features, or code points which need to be triggered. Many warnings of these types still exist in the current source code of the game engines, although they should be converted to errors or GUI dialog in the future. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
::: Warning about corrupt or missing files should be shown via GUI dialogs, agreed. We should fix those before hiding the console by default. Reports on missing code or features should not affect any officially supported games -- if you know of examples where we print a warning on a not supported feature for an officially supported game, please list them. I am not sure what you mean with "code points which need to be triggered" -- do you mean messages of the type "Tell Fingolfin if and where you saw this warning" ? These are not intended to be seen or acted upon by end users (though of course they are welcome to do so). But maybe you meant something else? --[[User:Fingolfin|Fingolfin]] 09:22, 26 October 2010 (UTC)
::: Warning about corrupt or missing files should be shown via GUI dialogs, agreed. We should fix those before hiding the console by default. Reports on missing code or features should not affect any officially supported games -- if you know of examples where we print a warning on a not supported feature for an officially supported game, please list them. I am not sure what you mean with "code points which need to be triggered" -- do you mean messages of the type "Tell Fingolfin if and where you saw this warning" ? These are not intended to be seen or acted upon by end users (though of course they are welcome to do so). But maybe you meant something else? --[[User:Fingolfin|Fingolfin]] 09:22, 26 October 2010 (UTC)
:::: Several unsupported games (and specific game versions) are still enabled in release versions, where warnings about missing code or features would be of most benefit. And sometimes we do need to know where specific code is used (or if used at all) via warnings (i.e. Tell x where this code is used), which can require wider testing, and can't be turned into errors for the release versions. [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)


==== If a known issue occurs, but isn't suitable for GUI feedback, then users lose that information. ====
==== If a known issue occurs, but isn't suitable for GUI feedback, then users lose that information. ====
Line 63: Line 69:
::: A user notices ScummVM is no longer responding to user input, checks the console window (can still toggle between fullscreen and window), and notices the warning(s). A few wait timeouts can occur in a row, when these bugs occur. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
::: A user notices ScummVM is no longer responding to user input, checks the console window (can still toggle between fullscreen and window), and notices the warning(s). A few wait timeouts can occur in a row, when these bugs occur. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
:::: If we have a hotkey for hiding/showing the console on the fly, the user could still look at the console. But anyway: If we can show a timeout warning, why can't we fix the bug, or at least work around it by shortening the timeout / detecting the bad state and breaking out of it? This seems like a very, very special case, too; do you know of a second example of this or similar kind? --[[User:Fingolfin|Fingolfin]] 09:22, 26 October 2010 (UTC)
:::: If we have a hotkey for hiding/showing the console on the fly, the user could still look at the console. But anyway: If we can show a timeout warning, why can't we fix the bug, or at least work around it by shortening the timeout / detecting the bad state and breaking out of it? This seems like a very, very special case, too; do you know of a second example of this or similar kind? --[[User:Fingolfin|Fingolfin]] 09:22, 26 October 2010 (UTC)
::::: That is a unique example, where overall detection doesn't seem possible. The timeout values match the original versions, and can't be reduce without regressions.
::: Basically if an issue that isn't critical (crash or lockup) occurs, the console could provide information on why that occurs, if there are related warnings. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
::: Basically if an issue that isn't critical (crash or lockup) occurs, the console could provide information on why that occurs, if there are related warnings. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)


==== 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. ====
==== 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.
: I don't see how this is an argument for always showing the console. It is just pointing out a limitation of using a single log file, but obviously the console has the exact limitation. Actually, isn't relying on the console alone is worse, as its content is gone as soon as ScummVM quits / crashes? Or does Windows keep the console open in that case?  --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC)
: I don't see how this is an argument for always showing the console. It is just pointing out a limitation of using a single log file, but obviously the console has the exact limitation. Actually, isn't relying on the console alone is worse, as its content is gone as soon as ScummVM quits / crashes? Or does Windows keep the console open in that case?  --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC)
:: If the console was specifically allocated for that executable and has not been attached to by another executable, [http://msdn.microsoft.com/en-us/library/ms683150(v=VS.85).aspx the console dies with the process]. --[[User:Pidgeot|Pidgeot]] 16:23, 25 October 2010 (UTC)
:: If the console was specifically allocated for that executable and has not been attached to by another executable, [http://msdn.microsoft.com/en-us/library/ms683150(v=VS.85).aspx the console dies with the process]. --[[User:Pidgeot|Pidgeot]] 16:23, 25 October 2010 (UTC)
::: Based on what Pidgeot writes, I think this "con" argument is no argument at all. --[[User:Fingolfin|Fingolfin]] 16:46, 25 October 2010 (UTC)
::: Based on what Pidgeot writes, I think this "con" argument is no argument at all. --[[User:Fingolfin|Fingolfin]] 16:46, 25 October 2010 (UTC)
:: Just noting the disadvantages of solely rely on logs. The main advantage of a console window over logs, is immediate information on why a non-critical issue occurs, if there are related warnings. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
:: Just noting the disadvantages of solely rely on logs. The main advantage of a console window over logs, is immediate information on why a non-critical issue occurs, if there are related warnings. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
** If logs files are used, how do we handle multiple ScummVM be run at the same time? I expect this would effect developers more (i.e. when tracing regressions), and not be common with users though.  
 
==== Multiple logs would lead to more confusion, about which file to submit, if that method was used. ====
 
==== If logs files are used, how do we handle multiple ScummVM be run at the same time? I expect this would effect developers more (i.e. when tracing regressions), and not be common with users though. ====


==== 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. ====
Line 78: Line 87:
:: An on-demand console window was previously suggested as an alternative, any user could be requested to display this on-demand console for any bugs/issues that occur. Forcing a user to manually toggle back on window mode, is a kludge. Basically SDL programs for Windows don't handle been dumped back to the desktop, and then been resumed later well, and we should not put users at the risk of further crashes or display issues. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
:: An on-demand console window was previously suggested as an alternative, any user could be requested to display this on-demand console for any bugs/issues that occur. Forcing a user to manually toggle back on window mode, is a kludge. Basically SDL programs for Windows don't handle been dumped back to the desktop, and then been resumed later well, and we should not put users at the risk of further crashes or display issues. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
::: Huh? Where and when do we force the user to toggle back to window mode? As I understand it, the console is *never* visible in fullscreen mode, so to see, the user is already now forced to toggle back to window mode manually. So, maybe it is a kludge (it is indeed one, because we force the user to look at something that only devs should ever have to look at) but then it is a kludge that is already now present, isn't it? --[[User:Fingolfin|Fingolfin]] 09:22, 26 October 2010 (UTC)
::: Huh? Where and when do we force the user to toggle back to window mode? As I understand it, the console is *never* visible in fullscreen mode, so to see, the user is already now forced to toggle back to window mode manually. So, maybe it is a kludge (it is indeed one, because we force the user to look at something that only devs should ever have to look at) but then it is a kludge that is already now present, isn't it? --[[User:Fingolfin|Fingolfin]] 09:22, 26 October 2010 (UTC)
:::: Yes, the users would have to toggle back to window mode either way, if in fullscreen mode. But the point that opening a console option on demand is more risky stands. [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)


==== 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. ====
==== 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. ====
Line 87: Line 97:
:: You comments seem based on experiences on other platforms, we should match the standard behavior of Windows GUI programs, on Windows. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
:: You comments seem based on experiences on other platforms, we should match the standard behavior of Windows GUI programs, on Windows. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC)
::: My comment is based on experiences with good UI design that hold valid on all desktop platforms; *and* is based on experience with Windows. For a polished Windows GUI program, it is very uncommon to show a console dialog. Please don't repeat the "we are beta level" argument, we are not in beta. And I dare say that even among beta programs on Windows, showing a console is not that common (though I must admit that I rarely run beta software on Windows; but e.g. Chrome and Firefox betas don't do that). --[[User:Fingolfin|Fingolfin]] 09:28, 26 October 2010 (UTC)
::: My comment is based on experiences with good UI design that hold valid on all desktop platforms; *and* is based on experience with Windows. For a polished Windows GUI program, it is very uncommon to show a console dialog. Please don't repeat the "we are beta level" argument, we are not in beta. And I dare say that even among beta programs on Windows, showing a console is not that common (though I must admit that I rarely run beta software on Windows; but e.g. Chrome and Firefox betas don't do that). --[[User:Fingolfin|Fingolfin]] 09:28, 26 October 2010 (UTC)
:::: This comment seems under the incorrect section, we are talking about the inconsistent behavior of the current method (disabled by default) used in ScummVM, to disable the console. [[User:Kirben|Kirben]] 13:40, 26 October 2010 (UTC)
: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
: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
:: I am not completely sure at what your comment is directed. Please clarify :) --[[User:Fingolfin|Fingolfin]] 15:56, 25 October 2010 (UTC)
:: I am not completely sure at what your comment is directed. Please clarify :) --[[User:Fingolfin|Fingolfin]] 15:56, 25 October 2010 (UTC)
657

edits