[Scummvm-devel] Windows console

[Travis Howell]

On 28/10/2010 9:11 PM, Willem Jan Palenstijn wrote:
> On Thu, Oct 28, 2010 at 03:44:34PM +1100, Travis Howell wrote:
>> I'm basing my opinion, more on what would be best for the project.
>> Windows continues to be one of our main platforms, and we are relying
>> even more on release versions for feedback, due to reduced testing
>> during release cycles. The console can provide useful information for
>> feedback on bugs/issues, and even useful information for users (no
>> matter how un/experienced) at times.
>
> This is getting rather repetitive; you've raised these points on the wiki
> too. IMO this is mixing several issues and claiming that a console is somehow
> the best solution for all of these instead of looking at each issue
> separately and determining what would be the best way to address it.

Please try to keep general discussion of pros and cons to the wiki page, 
otherwise we are just duplicating the discussion again and again.

> Looking at the wiki which has mostly converged by now, the main points for
> which a console are potentially useful are:
>
> * Detailed information for bug reports
>
> Log files would seem to be better than the console here since they're easier to
> attach to bug reports, have no arbitrary limit on size, and no weird copy-paste
> semantics.

I already stated the console has the clear advantage of immediate 
feedback, for any non-critical issues that occurs.

> * User feedback for bugs
>
> This is the one that most confuses me. I think we need _concrete_ examples of
> such things before deciding. If a single AGOS timeout issue is the only one, I
> don't think it warrants all that much consideration, to be honest.

There are warnings for the workarounds of several original bugs in the 
sword2 game engine too. There are warnings for load failures, which 
could cause related bugs. There are warnings about missing code/features 
in unsupported games and unsupported game versions (several which are 
still enabled in release versions).

> * User feedback for detection
>
> If it's important enough to show to users, we should consider GUI dialog boxes.
> I can imagine that failed detection in a directory would qualify.  If a user
> says "add a game" and scummvm replies "sorry, can't find anything", more
> immediately available info would be useful.

Yes, information which the GUI currently doesn't provide, and no one 
seems to be working on. With the GUI currently only stating no game was 
found, and providing no further details at all.

>> Actually this whole discussion has focused on changing the Windows
>> builds to no console by default, rather than previously showing a
>> console window by default. While the few requests in the past, have been
>> only to add an manual option for no console window. Which I would be
>> more agreeable to, even if the implementation can't be perfect.
>
> Of course the discussion is focused on that. Given that mature GUI programs
> _don't_ have a console as a rule, it seems clear that we should aspire to the
> same. If there are reasons we need a console, we should _address_ those
> reasons, rather than single-mindedly sticking to a console.

I already stated above, that we aren't a mature and stable GUI program, 
due to the serious lack of release testing. Especially for regressions, 
for the majority of games which are supported.

Dosbox and WinUAE are other examples of open source projects that use or 
have used the console window for feedback of issues.

There are numerous warnings (which I have given examples of) in the 
current source code of ScummVM, which can provide useful information at 
times, to any user.

It has been stated that many of these warnings should be reported via 
other means (debug message, error message or GUI dialog). But no one 
seems to be working on those changes, and not all warnings can be 
changed to other types either.

It doesn't help, when most of the con side, is based on future code 
changes, which might or might not happen in the future.

> (And if a user request an option to disable it, that would seem to me to
> reflect a desire to _use_ that option and disable it.)

Enabling the console window by default in Windows builds, means users 
are offered information that can be useful, and can help feedback of 
non-critical bugs/issues. Changing the default behavior means most users 
won't even know that information exists, and can lead to less useful 
feedback in some cases (i.e. non-critical bugs, or bugs related to 
loading failures).

Any users who would rather no console, can simply use the option (via 
command line or config file) to disable the console window.