#7504 closed feature request
GUI: Friendlier "Add Game" session
| Reported by: | salty-horse | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Using current SVN
When trying to look for a game and no game is found, an error is popped up and the file browser is closed.
Usually, after such an error you'd want to keep looking for the game, so the browser should remain open.
Ticket imported from: #1522626. Ticket imported from: feature-requests/320.
Attachments (1)
Change History (14)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
> the right fix would be to show the error alert box *atop* the browser dialog, never closing it.
That's exactly I meant.
comment:3 by , 18 years ago
> Rather, if we want to let the user keep browsing, then IMO > the right fix would be to show the error alert box *atop* > the browser dialog, never closing it.
I agree. Unfortunately, since that's a bit harder to implement. Unfortunately, by the time we do the actual game detection we've already closed the browser dialog. I guess what we need is some sort of validation stage in the browser, and to do the detection from there.
After several false starts, I came up with the attached patch. Unfortunately - again - it only affects ScummVM's dialogs, i.e. it does nothing about the native Macintosh dialog.
comment:4 by , 18 years ago
Come to think of it, I guess the Mac version would have to use a native alert dialog to go over the native file dialog.
Since my only book on Macintosh programming is a) a Turbo Pascal manual from the eighties, and b) packed up in a box at the moment, I'll let someone else worry about that, though. :-)
comment:6 by , 18 years ago
Fingolfin, did you have any thoughts on this? I'm afraid recent changes have broken the patch, and I haven't bothered to update it yet.
comment:7 by , 18 years ago
I can easily code a mac alert box that is shown when validation fails.
However, running the whole edit dialog from atop the browser won't work, and IMO isn't quite how it should be done...
Rather, I'd envision it as follows: In GameBrowserDialog::validateSelection() just run the detector. If that find nothing, return an error, else accept the choice. To avoid running the detector twice, store the output of the detector (i.e. instead of "String _domain", I guess you'd have a "DetectedGameList _candidates").
Then, keep most of the logic in LauncherDialog::addGame (instead of moving it to GameBrowserDialog::validateSelection, I mean).
That way, only a simple alert box has to be shown atop the browser (and I can implement that natively, too). Of course this also means that if you cancel the "Edit Game" dialog there, it won't restart the browser... Whether that is bad or good probably is highly subjective... I persnally prefer it that way, but again I think this purely subjective.
comment:8 by , 17 years ago
This is a great idea, sometimes adding games to ScummVM is a bit annoying because closing the browser dialog when not game is detected. Even not stores the last used path when opening the browsing dialog again...
comment:9 by , 17 years ago
| Summary: | Friendlier "Add Game" session → GUI: Friendlier "Add Game" session |
|---|
comment:10 by , 17 years ago
To elaborate a bit more on the scheme I sketeched below: The browser dialog could also be made a bit wider, adding a field where it says: "The following games have been detected in the current/selected directory:" or so...
comment:12 by , 15 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:13 by , 5 years ago
| Component: | → GUI |
|---|
I am not convinced. I do agree that the current behavior is not optimal, but the proposed solution doesn't seem satisfactory to me...
Rather, if we want to let the user keep browsing, then IMO the right fix would be to show the error alert box *atop* the browser dialog, never closing it. Or alternatively, we could the "Add" button if no game resides in the selected dir (the latter might or might not be confusing to users, and it might be impossible due to speed reasons on some target syystems).