1,079
edits
Difference between revisions of "Windows/Console"
Jump to navigation
Jump to search
→Cons (Arguments against "Hiding The Console Window")
| Line 54: | Line 54: | ||
: 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. --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC) | : 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. --[[User:Fingolfin|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. [[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) | |||
* 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. | ||
** 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. | ||
| Line 59: | Line 60: | ||
:: 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? --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC) | :: 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? --[[User:Fingolfin|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. [[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) | |||
::: 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. | ||
| Line 71: | Line 73: | ||
: 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). --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC) | : 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). --[[User:Fingolfin|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. [[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) | |||
* 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. | ||
: This already happens with the currently submitted patch by m_kiewitz --[[User:Md5|Md5]] | : This already happens with the currently submitted patch by m_kiewitz --[[User:Md5|Md5]] | ||