Skip to content
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

[Discussion] Improvement ideas #207

Open
koplo199 opened this issue Dec 25, 2022 · 5 comments
Open

[Discussion] Improvement ideas #207

koplo199 opened this issue Dec 25, 2022 · 5 comments

Comments

@koplo199
Copy link
Contributor

Issue where new ideas could be discussed, before they are approved by a member of the @bottlesdevs organization.
I'll begin:

  • Automate components testing from PR's by simulating/using code from the Bottles back-end (download, decompress, check if directory exist with the righ name, maybe even try to select component...). This would benefit mainly PR's from the CI, so we're sure they don't break things unexpectedly before merging them.
    Difficulty: I'm not familiar enough with the Bottles source code so I'm unsure what would be the difficulty of this task.
  • Add experimental builds of dxvk-async for parity, as dxvk already supports experimental builds.
    Difficulty: easy
@Kinsteen
Copy link
Contributor

For the first suggestion, it needs a lot of dev time imo. Either:

  • we have a separate program that test this the same way Bottles does, which means more maintenance work as code is duplicated, and also stuff can break because the code is inherently not the same
  • we create a new main that calls the appropriate functions of the Bottles backend, but it requires some work as a lot of classes won't be available as they're tied to the UI. Some overriding of functions that calls GTK/GLib would also be needed, at first glance.

I agree with the idea as it would definitely be very great, but it also feels like a ton of work... But this development is beneficial either way as that would essentially create unit/integration tests, which is always good (but annoying to do lol)

@koplo199
Copy link
Contributor Author

@Kinsteen Oh, that indeed sounds... challenging haha :')
This is probably something that should be incrementally built over time, starting with the easiest checks to implement, in your opinion what a good first target would be?

Replacing the main and using the official functions looks like the way to go, as it should be a lot more easier to maintain than another standalone implementation, in addition to be less error prone: worst case scenario it pass the CI implementation, and not the official one shipped in Bottles, this is not something we want to happen

@Kinsteen
Copy link
Contributor

Maybe using a Python testing framework could be nice, I never worked with that so I'm not even sure how it would work. Then testing function like download in the component manager could be nice as it would test the index downloading, parsing, the downloading of components, the folder structure etc... It should be doable, but I'm not sure if the maintainers want to implement this type of testing

@koplo199
Copy link
Contributor Author

I agree, a testing framework should probably be used here in order to be as clean as possible. I did some research and it appears that pytest is often recommended, it also seems easy to use

@koplo199
Copy link
Contributor Author

koplo199 commented Mar 25, 2023

It seems dxvk-async isn't maintained anymore, a fork has been created (Sporif/dxvk-async#64 (comment)) which supports the latest dxvk version in addition of allowing the use of async and gpl at the same time. It probably needs more testing (nvidia gpus?), but may be worth adding as an unstable/experimental component.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants