Open main menu

Difference between revisions of "Windows/Console"

952 bytes added ,  16:23, 25 October 2010
Line 51: Line 51:
** Multiple logs would lead to more confusion, about which file to submit, if that method was used.
** 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 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 - Md5'''
** '''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). --[[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 - Md5'''
** ''' 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
** 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)


: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)
:: 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. --[[User:Pidgeot|Pidgeot]] 16:23, 25 October 2010 (UTC)
14

edits