check this

[a-detiste]

http://www.phoronix.com/scan.php?page=news_item&px=GNOME-Games-3.18&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Phoronix+%28Phoronix%29

[ssokolow]

Interesting. Not sure I'll use that code, given that I'm trying to banish GTK+ 3.x apps from my desktop as I migrate from GTK+ 2.x to Qt, but I could probably at least copy the algorithms they use to discover installed games.

(When I have time to work on this again, I intend to continue moving code out of the GTK+ 2.x-specific frontend so it can be used by the Qt frontend. My end goal being to rely on a specific desktop frontend as little as possible.)

Judging from the blog post, though, I probably won't be getting much out of it. I already know how to discover ROMs and packages for things like the LÖVE engine and they don't seem to have put much into discovering non-web games that are neither in Steam nor in the XDG launcher menu system.

They do show off how much work they put into being a nice Libretro frontend, but that's not all that special. The main focus of my codebase is in solving the hard problems like auto-discovering games that were distributed as a zip/tar archive containing no XDG install script and no .desktop file. (For example, I'm quite proud of the effectiveness of my code for guessing a game's human-readable name from the raw filename.)

If they want to adopt my code (or my algorithms) as a backend, then I'll have done my job.

[a-detiste]

I think the same about GTK vs Qt, still I'll gladly take a GTK application if I don't have the choice (e.g. gnome-mastermind).

The main focus of my codebase is in solving the hard problems like auto-discovering games

Didn't read your codebase yet, but seems interresting !

This problem can be brute-forced: just have checksums for all files for all possible versions of all games :wink: . That's just what I'm doing, seems a lot of work, but I've written tools to automate it.

This way data coming from random sources can be rubber stamped as valid. (or not)

they don't seem to have put much into discovering non-web games

Haven't yet looked at their code yet either, was more interrested in the PR aspect: what people thinks of this ? is there a need ?

My LXQT menu is totaly unusable, the omni-box (Alt-F2 + typing) works, but that's not nice for someone who wants to discover the games. Even something like the Windows 3.1 program manager would be better.

I've added some code in game-data-packager to detect game assets locations in .scummvmrc. Tha'ts quite trivial, didn't even bother to 'stole' it from an other project.

        rcfile = os.path.expanduser('~/.scummvmrc')
        if not os.path.isfile(rcfile):
            return

        config = configparser.ConfigParser(strict=False)
        config.read(rcfile, encoding='utf-8')
        for section in config.sections():
            for gameid in gameids:
                if section.split('-')[0] == gameid:
                    path = config[section]['path']
                    if os.path.isdir(path):
                        yield path

[ssokolow]

I think the same about GTK vs Qt, still I'll gladly take a GTK application if I don't have the choice (e.g. gnome-mastermind).

Basically the same position I'm in... though games aren't as big a deal since they tend to minimize their use of things which GTK+ 3.x changed for the worse, like the Open/Save dialogs.

This problem can be brute-forced: just have checksums for all files for all possible versions of all games :wink: . That's just what I'm doing, seems a lot of work, but I've written tools to automate it.

The whole point of my codebase is to provide something that can work Well Enough™ both automatically and without requiring the cooperation of some third-party source to provide checksums. (eg. I've already got options if I want to limit myself to what's been catalogued. I want a launcher that will display everything I've got installed, even if it's some niche thing nobody has heard of.)

Haven't yet looked at their code yet either, was more interrested in the PR aspect: what people thinks of this ? is there a need ?

I'm honestly not sure. It's unclear which specific niches they're trying to serve. (eg. For mine, integrating ROMs isn't a high priority because I think of them separately from native games and they'd just dilute the listing and make it less useful.)

My LXQT menu is totaly unusable, the omni-box (Alt-F2 + typing) works, but that's not nice for someone who wants to discover the games. Even something like the Windows 3.1 program manager would be better.

Sounds like the reason I make sure to unpack my GOG games without installing them. (Thus making filesystem discovery more necessary)

I've added some code in game-data-packager to detect game assets locations in .scummvmrc. Tha'ts quite trivial, didn't even bother to 'stole' it from an other project.

I've been meaning to do that but, at the moment, my ScummVM and ResidualVM code just parses the output of scummvm -t to be absolutely sure that the result will be valid input for scummvm <game_id>. I figured that code could wait until I'd cleaned up, added unit tests to, and split out the icon discovery routines into something usable outside the fallback backend.

[a-detiste]

Gnome-Games

I've had a look at the code, that doesn't do that much & I'd like to stick to Python and not some exotic new language; as I'm still learning it and will apply for new jobs very soon.

I know I should also have some RedHat experience too (last version I have used is 5.2, the one from 1998, not the one from 2008), so I'm thinking of making this Debian project cross-distro as a starter.

I want a launcher that will display everything I've got installed, even if it's some niche thing nobody has heard of

So you'll easily find all those .desktop files with Categories=Game; only extra-step needed is to de-duplicate those against .scummvmrc :smile:

Some scummvm games have mutlilangual support in one set of files, but only for one version of a game (e.g. kyrandia2 has en+de+fr) & scummvm must be launched with the correct -q option

It would be nice if scummvm provided an --identify that does the same autodetection as adding a when a game is added to the gui but can be called unattendre and directly output a scummvmrc blurb on stdout

[ssokolow]

So you'll easily find all those .desktop files with Categories=Game; only extra-step needed is to de-duplicate those against .scummvmrc :smile:

You completely missed my point. Over 90% of my installed games have no .desktop files. (And not all of them by choice)

As for the ScummVM games, none of them have .desktop files because, stubborn person that I am, I manually extracted the resources from the GOG installers using innoextract and then placed just the required files in /srv/fservroot/Games/ScummVM-Compatible. (Even if they've since gained Linux installers, I don't want duplicate ScummVM installs and, in most cases, my rips lack icons because I didn't think to grab them at the time.)

[a-detiste]

I missed one sentence: you can just use some (or all) of game-data-packager as a backend to find these scummvm games by hash & (optionally) create the .desktop file.

[a-detiste]

This feels like a quite generic problem:

http://forums.scummvm.org/viewtopic.php?t=11754&sid=bf3d8ce4d83cb7f3c7faebcd9b7d9afa

[ssokolow]

you can just use some (or all) of game-data-packager as a backend to find these scummvm games by hash

Now that is something I might be open to. At present, my codebase just assumes that ScummVM will already be configured while I work on the more interesting problems. However, tying game-data-packager to a frontend that adds any found games to .scummvmrc could be a nice complement to my code.