1,489
edits
Difference between revisions of "Windows/Console"
Jump to navigation
Jump to search
m
Formatted my comments properly
m |
m (Formatted my comments properly) |
||
| Line 42: | Line 42: | ||
: 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) | ||
* 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. | ||
: | : 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 --[[User:Md5|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. --[[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) | ||
* 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. | ||
*** | *** Yes, but noone notices the console in this case anyway --[[User:Md5|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? --[[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 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 54: | Line 54: | ||
::: 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) | ||
* 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. | ||
: 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 --[[User:Md5|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). --[[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) | ||
* 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]] | |||
:: 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. --[[User:Fingolfin|Fingolfin]] 15:37, 25 October 2010 (UTC) | :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. --[[User:Fingolfin|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. --[[User:Pidgeot|Pidgeot]] 16:23, 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. --[[User:Pidgeot|Pidgeot]] 16:23, 25 October 2010 (UTC) | ||