Support importing games from q4wine and extracting icons from .exe

[gabriele2000]

Is your feature request related to a problem? Please describe.
It's just something that will make me uninstall q4wine just to use this newer application.

Describe the solution you'd like
q4wine is quite old and this is a new app, so it would be cool if I could just import stuff from q4wine, the ability to extract icons from .exe would be quite nice too.

[Arcitec]

I am just a contributor but I can say that I doubt we'll add support for q4wine for the simple reason that it's an old and unpopular launcher.

I can see that they literally came out in 2008! Yet they only have 179 GitHub stars:

https://github.com/brezerk/q4wine

It's a dead and unpopular project and I don't personally think it makes sense to support importing from a project that nobody uses, and to clutter up the GUI with it. But it's up to @kra-mo.

One potential solution for all these obscure launchers that some people are using, would be that we think about a plugin system for Cartridges, where it can import .py (python) files that follow a strict format of providing a few things:

• The name of the module/source (like "q4win"). This should be taken from the .py file itself. Like heroic.py = heroic, q4win.py = q4win, etc.
• The module just has to provide a class named import_<modulename> like import_heroic, import_q4win.
• The class has to provide a few static fields: .api = which module version/spec it uses (so that we can detect outdated modules in the future). .platforms = ["linux", "windows"] = so we know what platforms the module supports. .display_name = "Q4Win" = a nice display-name for the GUI, which will allow module authors to name their file efficiently but still have a nicer display name in the GUI (in the + > Import From > Q4Win menu).
• And a function list_games() for fetching a list of all games and their "command line" launchers. Meaning, the game title, game publisher, cover art file or internet URL (if any), and the "executable" (given as a list[] with one element per argument). Which the module author can implement any way they want.

That way we don't have to support or maintain obscure launchers, but people who want them can still make modules for them that can be easily added to Cartridges. General users of Cartridges won't have to see import-sources used by 1 person, but everyone who actually uses the obscure sources will be able to do it via custom modules. Win-win.

When we import games, we simply name their JSON and Cover files as <modulename>_<gameid>.<ext> to keep things separated and easy to identify the source of the imported game. The game IDs will be automatically handled without the module authors needing to do anything, since our module system will automatically do something like gameid = sha256(shlex.join(game["executable"])) to de-duplicate based on the launch arguments the module gave us.

Edit: It might be a good idea in general to refactor all of our current Heroic, Steam and Bottles importers to use this modular system, thus decoupling Cartridges from the game-import sources.

Restructuring things in this way also means that if someone creates a high-quality import module that turns out to be popular and people want it, we can then simply add it to the main project by default.

It also lowers the barrier to contributing more import modules, so that we can speed up development by outsourcing module creation to the people who are passionate about the source they're trying to add. Since it's mostly gonna be sources that nobody on the team uses. That way the team can focus on the core launcher and core (popular) modules. But it will still be flexible enough to support obscure sources.

Edit: Oh and regarding Flatpak permissions, the people who install and use custom modules would simply have to add :ro read-permissions to whatever game-launcher paths their custom modules want to access. Very easy. Module authors would simply have to tell users to run a single "flatpak" command in the terminal to add the required permission for Cartridges. That's up to the module authors.

[gabriele2000]

The simplest way would be to implement the importing of .desktop files (for now) and for each game you fill the .exe path manually.
That way at least you can have the icons and the name.

[Arcitec]

@gabriele2000 Definitely, and desktop file import is one of the most wanted features right now. We have to figure out some things there too, as you can see in the ticket about desktop file importing. But it's something that's definitely high on the list of to-dos. :)

[kra-mo]

@gabriele2000 Would your issue be resolved by the desktop file importer? If so, I'd probably close this issue.

[gabriele2000]

@gabriele2000 Would your issue be resolved by the desktop file importer? If so, I'd probably close this issue.

Yeah!
Awesome work!