14
edits
Difference between revisions of "Windows/Console"
Jump to navigation
Jump to search
→Most Windows applications do not display a console window. It is hence confusing for users.
| (17 intermediate revisions by 5 users not shown) | |||
| Line 2: | Line 2: | ||
=== Current situation === | === Current situation === | ||
Currently, Windows Release Builds (1.2.0 and earlier) open a console window in addition to the normal ScummVM GUI window. | 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(). | 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 console window is closed together with the ScummVM GUI window if it was run from the GUI. It's kept open when ScummVM was run from the command line. | ||
There is a perennial argument as to whether this is a good or a bad thing, mainly with respect to novice Windows users. | |||
=== Proposed alternative === | === Proposed alternative === | ||
| Line 27: | Line 29: | ||
:: 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 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) | ||
:::: You are welcome to class ScummVM as alpha, beta, gamma or any other greek letter you like, and you can even class it a banana, but this is really totally irrelevant. ScummVM is *not* a beta, period. Feel free to try to convince the rest of the team to imitate Google and slap a big "Beta" badge over everything, but right now, this is not the case. --[[User:Fingolfin|Fingolfin]] 21:03, 26 October 2010 (UTC) | |||
::::: Not irreverent at all, you can't state ScummVM release versions are stable, when we no longer thoroughly testing the majority of games. We are currently relying on public feedback from the wider testing of release versions for even regressions, no matter how much you want to deny that fact. [[User:Kirben|Kirben]] 05:23, 28 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) | ||
::: A Windows build of ScummVM will still briefly show a console window, when the console window is disabled, no matter which method is used. So if users truly are confused, that confusion might continue. [[User:Kirben|Kirben]] 05:23, 28 October 2010 (UTC) | |||
:::: There *are* workarounds for that: We can use a second stub executable which launches ScummVM and tells it to attach to the console allocated for this stub, or we can choose to always allocate a new console if we want one; maybe we even want to create an actual GUI window so it's easier for users to copy/paste. Actually, the brief console flash might be okay, as long as it's brief; it's more likely to be passed off as some kind of loading message (and we could choose to write such a message until the console is hidden). --[[User:Pidgeot|Pidgeot]] 21:45, 28 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) | ||
| Line 38: | Line 45: | ||
:: 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) | :::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) | ||
| Line 54: | Line 54: | ||
:: 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) | :: 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) | ||
::: Quite easily, we could have a graphical display to the mass add detection screen of how many games were not found (e.g. "Not recognized: 2"). The user can then consult the log file, where he can find the full paths of the aforementioned games, along with their MD5 checksums --[[User:Md5|Md5]] 13:53, 26 October 2010 (UTC) | ::: Quite easily, we could have a graphical display to the mass add detection screen of how many games were not found (e.g. "Not recognized: 2"). The user can then consult the log file, where he can find the full paths of the aforementioned games, along with their MD5 checksums --[[User:Md5|Md5]] 13:53, 26 October 2010 (UTC) | ||
:: You need to think a bit more outside the box. We don't have to (and in fact, most definitely should not) turn every warning directly into a dialog one-to-one. It's not hard to come up with several ways to design a mass add dialog that provides all this information, and more, in a concise fashion to the user. For that matter, though, I am not sure what console output from the mass detection you would want to see in the GUI... reports about partial matches that hint at a directory that might contain an incomplete game? --[[User:Fingolfin|Fingolfin]] 21:01, 26 October 2010 (UTC) | |||
::: Yes, reports about partial games (which can be due to missing files) or unknown games versions. For example: A user could use the mass add option on the whole CD of a foreign language version of a game from Humongous Entertainment. Which could detect several unknown game versions, since many games demos are bundled with each games from Humongous Entertainment. [[User:Kirben|Kirben]] 05:23, 28 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. ==== | ==== Users need to restart ScummVM, to get more feedback on non-critical issues, and might not even be able to reproduce the bug/issue. ==== | ||
| Line 63: | Line 65: | ||
::: 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) | :::: 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) | ||
::::: I disagree, very few people bother to report these. The "please talk to X about this" should usually be errors (like we did with the workarounds for script bugs in SCI), or GUI popups, where possible --[[User:Md5|Md5]] 13:55, 26 October 2010 (UTC) | |||
:::::: In these particular cases, we only need a single users to report where the message occurred though. We usually don't turn message of this type into errors in release versions, due to the negative effects it could have on game play. [[User:Kirben|Kirben]] 05:23, 28 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 72: | Line 76: | ||
::::: 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. | ::::: 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) | ||
:::: If ScummVM crashes, the log file will contain all the warnings before the error anyway, so I find this point a bit moot --[[User:Md5|Md5]] 13:56, 26 October 2010 (UTC) | |||
::::: But a console can show message at the exact time a non-critical issues occurs. While a log file could have various other unrelated messages, before or after that non-critical issues occurs, and might not be as helpful. We would still need to know the exact time a non-critical issue occurred in that case, even if we could time stamp all messages sent to log files. [[User:Kirben|Kirben]] 05:23, 28 October 2010 (UTC) | |||
:: | |||
==== 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 89: | Line 85: | ||
::: 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) | :::: 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) | ||
::::: No, it does not stand from my point of view. I explained, in particular, that the hotkey for toggling the console could easily be implement in a way that would *not* forcefully exit fullscreen mode. So far I countered every point your raised here in detail, and you have still to reply to that. From my point of view this "con" argument has been effectively refuted, unless you can either explain why my approach would not work, or bring up further issues. --[[User:Fingolfin|Fingolfin]] 20:55, 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 99: | Line 96: | ||
::: 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) | :::: 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 | ::::: We can also switch ScummVM to windowed app type and it won't wait *BUT* actually ScummVM *is* also a charmode app. In the windowed app case, "scummvm -?" won't work anymore and I don't think that this would be desired behaviour. So the current new way of hiding the console in case, we are started directly, makes actual sense. Oh and actually cmd.exe waits for programs marked as windowed apps. The application itself doesn't do anything itself. So its either windowed app *or* charmode app. There is nothing inbetween --[[User:M kiewitz|M kiewitz]] 18:30, 27 October 2010 (UTC) | ||
:::::: Yes, researching further shows there seems to be no simply solution to allow console output from any argument(s) passed, while freeing/returning the prompt if launched without argument, when using a command prompt. Since how a Windows programs interacts with a console, is decided at the link time. I noticed Cygwin was able to do this for programs in the past, but that seems a rather unique case. [[User:Kirben|Kirben]] 05:23, 28 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.) --[[User::m_kiewitz|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) | ||
::: We currently hide the console right at the start. We could theoretically show it again, when the user tries to add an unknown game. This would make it possible to copy the md5 out of the window. Of course it's not common behaviour, but it would solve some of our hiding problems --[[User:m_kiewitz|m_kiewitz]] 18:07, 25 October 2010 (UTC) | ::: We currently hide the console right at the start. We could theoretically show it again, when the user tries to add an unknown game. This would make it possible to copy the md5 out of the window. Of course it's not common behaviour, but it would solve some of our hiding problems --[[User:m_kiewitz|m_kiewitz]] 18:07, 25 October 2010 (UTC) | ||
| Line 105: | Line 104: | ||
::: Yes, I have not come across any Windows program that will show the console window on demand in that way. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC) | ::: Yes, I have not come across any Windows program that will show the console window on demand in that way. [[User:Kirben|Kirben]] 00:23, 26 October 2010 (UTC) | ||
::: I agree, suddenly and unexpectedly showing the console like that seems worse to me (from a UI design point of view) than always showing the console. To iterate it once more: If there are messages the user should see, we must not rely on the console output, but rather must display the information to the user by other means, such as GUI dialogs. And this holds true regardless of how the discussion here is settled in the end. --[[User:Fingolfin|Fingolfin]] 09:30, 26 October 2010 (UTC) | ::: I agree, suddenly and unexpectedly showing the console like that seems worse to me (from a UI design point of view) than always showing the console. To iterate it once more: If there are messages the user should see, we must not rely on the console output, but rather must display the information to the user by other means, such as GUI dialogs. And this holds true regardless of how the discussion here is settled in the end. --[[User:Fingolfin|Fingolfin]] 09:30, 26 October 2010 (UTC) | ||
=== Pros (Arguments for logging to a file) === | |||
* Users need to restart ScummVM, to get more feedback on critical issues, 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. | |||
* 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. | |||
* A log file can be easily submitted via the bug tracker, even if it is big. | |||
* A log file is often much easier for the developers to analyze than a screenshot. | |||
=== Cons (Arguments against logging to a file) === | |||
==== 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. ==== | |||
: 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) | |||
::: 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) | |||
::: This advantage is only there for people who actually have the console visible and look at it (many people, in my believe in fact most, have the console minimized or play in fullscreen mode). If we have a hotkey to toggle the console on, the user still retains this ability. Self-declared "power users" would still be able to have the console *always* visible, too. --[[User:Fingolfin|Fingolfin]] 20:50, 26 October 2010 (UTC) | |||
==== Multiple logs would lead to more confusion, about which file to submit, if that method was used. ==== | |||
: I don't think so. The lognames would have names like "scummvm-20101026-202614.log" and thus would automatically be sorted by date to the user; they could simply pick the latest. Or if unsure, they could simply pick *all* of them and let us sort out which is the right one. Anyway, this is beyond the actual point we are discussing here. From my point of view it would be completely sufficient to use only a single log file, as that would provide exactly the same information as the console, only better as it stays around even when ScummVM crashes. --[[User:Fingolfin|Fingolfin]] 18:28, 26 October 2010 (UTC) | |||
:: The position of day and month in dates, varies between different countries, meaning any dates based only on numbers only can be confusing at times. While sending multiple logs can be a hassle if not archived, since only one file can be added to a bug report at a time. Agreed, that multiple logs would not be worth it. [[User:Kirben|Kirben]] 05:23, 28 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. ==== | |||
: If we use multiple log files, this is trivial (and a standard practices). Just insert a random component into the log file names. Anyway, these arguments start getting a bit far-fetched :). --[[User:Fingolfin|Fingolfin]] 18:29, 26 October 2010 (UTC) | |||