-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GLC2 platform discussion #71
Comments
EDIT: Moved this comment to (#39 (comment)) |
Hey there.
The reason for that is that the project has grown to be quite big and feature-rich (e.g. images in terminal) and I want people to be able to use the core to make their own apps (a good example would be an integration with PowerToys or voidtools everything). As for the plugins; it's a little tricky. On one hand I'd like to have a separate plugin for each platform (personally I'm only interested in 5 platforms) but I understand that it would quickly lead to a messy repo. Perhaps the best thing to do would be to have the extension base in a separate repo, release it as a nuGet package, and implement all the 'official' platforms in that repo. The glc app would be able to download the plugins from there. We could use the platform scanning implementations from your What are your thoughts? |
Oh no worries, I totally understand burnout. I dunno. I understand the benefits of loosely coupled extensibility, but a plugin model adds complexities for both users and maintainers, and attempts to decrease the burden on one is often at the expense of the other. Not that I wouldn't find it an interesting learning exercise in any case. |
FYI, GameCollector v3 now implements all of the platforms supported here. |
As you, @Solaire , have mentioned a few times, the idea for GLC 2.0 is to separate platforms into plugins. I've got a couple of questions:
What will this look like in practice, i.e., do you have the idea that this will be like Playnite or GOG Galaxy, where these are going to be maintained in separate repositories (potentially by separate individuals)? How will users discover these plugins? Would the user have to download each separately, and copy them to their plugin folder? We could have various built-in automation methods and/or websites to handle these things, but that seems like it adds a lot of work for both us and our users for minimal benefit.
Note that the EA Desktop fix for EA: New installed games aren't found #66 was based mostly on GameFinder's wiki, but not so much on its code. After examining it further, however, I found there were a lot of aspects that I liked, and thought it would be nice to use its various NuGet packages as references (there are separate ones for each store handler). I thought this would simplify things for us, and it would be nice to share the burden of discovering/fixing breaking changes for the various launchers/APIs. But the current implementation is rather limited for our purposes, and it only supports a few platforms. In this issue, I asked to what extent @erri120 would be interested in--with my help--increasing the scope of his project for uses like ours, and he was, quite understandably, loath to do so. So I've been toying with a rebranded fork (with attribution) of his project here: GameCollector. I'm learning some new tricks from examining his code, and I've started by moving to a generic record type with more fields, and adding additional handlers. However, at this point I'm wondering how well this might or might not dovetail with your plans for GLC2.
The text was updated successfully, but these errors were encountered: