Windows/Console

Windows Console - Blessing or Curse?

Current situation

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-

Proposed alternative

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.).

Discussion

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, it seems we have mostly consensus (have we?) that log files should be introduced, which could be erased (or rotated) every time ScummVM starts. There are some concern over details (e.g. what if a log file grows very large due to using "-d9"?) which however should be resolvable.

In addition, according to Fingolfin, 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. 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. 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. --Fingolfin 09:13, 26 October 2010 (UTC)

I don't see how an extra console window appearing in the background, suddenly confuses users either. 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. --Fingolfin 09:13, 26 October 2010 (UTC)

• 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. --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 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. --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).

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. Kirben 23:22, 25 October 2010 (UTC)

Name concrete examples, please. --Fingolfin 09:13, 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 "Hiding The Console Window")

• How do we report unknown games, or games with missing files to users?

Via a GUI dialog. --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.
• 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

There are some warnings that are important for users and that we do not show anywhere except for the console. I consider these to be bugs, and should be identified and fixed. Then, there might be some output that could be potentially for a few power users. These users can simply switch the default back to always showing the console. I do not believe, however, that the average user would benefit from seeing the warnings. Please give concrete examples of messages you think regular users would benefit from seeing, so that we can discuss them specifically. I don't think it makes sense to stay abstract on this point. --Fingolfin 15:37, 25 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. Kirben 00:23, 26 October 2010 (UTC)

• 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

How exactly does the console help in this case? Does it show a message saying "You may think the engine is locked up, but it isn't, this is really a bug that is happening right now!" ? I don't think so... So, can you please explain how having the console visible helps the user, so that we can better discuss this point? --Fingolfin 15:37, 25 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. 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. 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.
  • 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? --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, the console dies with the process. --Pidgeot 16:23, 25 October 2010 (UTC)

Based on what Pidgeot writes, I think this "con" argument is no argument at all. --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. 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.
• 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

How is this an argument for showing the console by default? If the user is in full screen mode, he cannot see the console anyway. If at all, this is an argument against having a simple hotkey for toggling the console visibility. However, this hotkey would not be used by regular users anyway. And if we are *really* concerned, we could disable the hotkey while in fullscreen mode. We could even make it so that showing the console is delayed until the user manually switches back to windowed mode (its trivial to implement this, too). --Fingolfin 15:37, 25 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. Kirben 00:23, 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.

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

I do not consider the option inconsistent at all. If one starts from a console, then that is a different situation than starting ScummVM by other (more GUI like) means. Why should two very different situations be considered inconsistent if they behave differently, as long as the behavior is consistent with how other apps behave in such a situation? Point in case, if I start an application on Linux or Mac OS X (or Windows, for that matter) from a console I opened, I would expect the console to stay open, and to block until the program exits. That is the normal behavior everywhere. On the other hand, if I launch a program via the GUI, I do *not* expect a console to pop up. Hence, I think the *current* behavior is inconsistent with everybody else. --Fingolfin 15:37, 25 October 2010 (UTC)

On Windows, it *is* actually very common for GUI programs to not block the console ever - but then, those programs don't use the console for anything. It makes sense to block in our case, because we *do* use it, but in my experience it's much more common to use a logfile. --Pidgeot 16:23, 25 October 2010 (UTC)

You comments seem based on experiences on other platforms, we should match the standard behavior of Windows GUI programs, on Windows. Kirben 00:23, 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

I am not completely sure at what your comment is directed. Please clarify :) --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 --m_kiewitz 18:07, 25 October 2010 (UTC)

Showing the Windows console "on-demand" is not common behavior on Windows - you either open the console at the same time as your program, or you don't open it at all. If we were talking about the "internal" console, or a separate GUI window, it can work, although it's not ideal either. --Pidgeot 16:23, 25 October 2010 (UTC)

Yes, I have not come across any Windows program that will show the console window on demand in that way. Kirben 00:23, 26 October 2010 (UTC)