[Scummvm-devel] consoles, warnings, errors and so forth

[A. Milburn]

Hi Max,

Thanks for the reply!

On Wed, Jun 01, 2011 at 02:42:50PM +0200, Max Horn wrote:
> If somebody here can tell me why exactly the console is off and how to re-enable it, please let me know. Even better, just implement the fix. 

LordHoto's comment on the forum was "Because the sdl-config script of the
prebuilt SDL development files for MinGW does pass -mwindows to the linker".

> > It's also important to me that I be able to ask users which warnings they
> > saw from scummvm when they have problems - although not necessarily in
> > real-time.
> 
> Sure, I think we all agree on that.

It isn't clear to me from the "Many of the current warnings (i.e. loading
related, missing code or features) in source code, can provide useful
feedback to users" section of the console discussion on the wiki whether
this is generally agreed on or not, so I thought I would be clear about it.

> I originally suggested an kInfo type for that, but I think it was rejected back then, forgot why exactly... I think one of the reasons was that we don't want to put non-warning non-error user info into the logs exclusively. Anyway, sure, in principle, we could do this.

Right, I was definitely thinking of it just on top of whatever else. But if
it's not rejected, it would be a quick fix to allow people to look in the
logs for the md5s.

> We could try to add some code that allows to unify these three use cases (and maybe yours in LB) in a good way. One way: Just add a function somewhere that does the logging and optional GUI reporting. Another idea is to remove this output completely from the detectors. Instead, augment the data they return to contain information about the (failed) detection. Then, the code which called the detectors could (a) log it, in a uniform manner, and (b) display suitable GUI dialogs to the user containing the information in an appropriate form.

That would be very nice. One annoying thing about the LB detector right now
is that it sometimes duplicates the output of the Advanced Detector's own
md5 mismatch code - because it seems to make much more sense for LB to try
and do a generic fallback which matches all LB games, rather than a
ADFileBasedFallback with a huge list of known filenames as well as the
fallback detection for anything which isn't known, but maybe that's silly..

> Approach b) seems better to me, at least on desktop machines. Show something like this:
>  "While adding new games, ScummVM noticed some file that look like currently unknown game variants
>   (King's Quest 4, Monkey Island and 5 more).
>   Please report them to the ScummVM team, by sending us your log file found at
>    C:\Path\To\LogFile.txt

I would personally prefer the option to have both, at least when not
mass-adding, but I can't say I mind too much - but you'd presumably want the
plain md5 view for non-mass-add so that people could take photographs or
write down things from their non-desktop devices? I don't know how annoying
it is for people to have to install and run ScummVM on a desktop box with
the same data. Maybe it's a non-existant problem.

> We could do that, sure. Although right now there is no console in the launcher, and you can't open the console if an error dialog is up. Also, there is no copy & paste in the console, and it is overall rather limited. Yet esp. on handheld devices, this might be quite helpful.

Mostly I was thinking of people e.g. being able to take photographs when an
error pops up.. this could be replaced with (for example) an error dialog
with a scrollable text widget with the contents of the log? But I suppose
that the console would still be very helpful, and we could always *add*
trivial copy/paste if we add clipboard code to the backends anyway?

(If some errors are caused by being out-of-memory then perhaps this isn't
a good solution. I don't know what typical errors from all the engines /
platforms are like.)

> Many games seem to support Ctrl-D, but not all. A uniform keystroke (as with the GMM) would be a good thing. You got my support ;)

I seem to remember that Ctrl-D conflicted with a built-in game keystroke of
some kind. And I don't know if it works on handheld devices?

> That would be nice. And easily doable on Mac, probably on Windows, not so sure on Linux. Alas, this would be encapsulated in an OSystem API, and I think it would be good to have this, at least everywhere we can implement it.

> For Unices in general, I see no alternative to providing the path to the log in the dialog / providing instructions to find it, sadly. But for Windows & Mac, an "open log" button would clearly superior. Let's do it ;).

I was thinking we could just name the log files with ".txt" and then call
xdg-open, which I hope is present on most Linux machines, or Notepad on
Windows, or TextEdit on Mac, or whatever the equivalent is on other OSes.

- fuzzie