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

Provide adaptation updates also outside of main program releases #233

Open
christofmuc opened this issue Feb 19, 2023 · 3 comments
Open
Labels
Epic Large task

Comments

@christofmuc
Copy link
Owner

          For linux, an import dialog would work, or dragging an adaptation onto the program window. 

If you have a separate repo, as a first iteration KnobKraft could look at the the releases there (curl or github API), and download new releases. It's probably too much hassle tracking versions for all adaptations separately, and you want to have them in a repo anyway so that you can track changes.

Originally posted by @bboc in #219 (comment)

@christofmuc christofmuc added the Epic Large task label Feb 19, 2023
@christofmuc
Copy link
Owner Author

The idea here would be that we want a quicker turnaround and easier distribution for community provided adaptations.

Current state:

  • Known good Adaptations are shipped with the installer/DMG file. To update these, I need to push them/accept a pull request to the main repo, and release a new version of the Orm. I think we have passed the point where updates to the main program are necessarily more frequent than adaptation updates, so this process has been good for a while but now should change
  • The Orm allows the user to specify a user adaptation directory (defaulting to User/KnobKraft Adaptations/, which is useful when having no overlap with the shipped adaptations. As soon as users start to modify/improve shipped Adaptations, versioning get's more tricky (which is Versioning / Version check of adaptations #123 ). The Orm issues a warning that a shipped adaptation is overridden by a user adaptations in the log.
  • There is already Python helper code shipped by Orm, e.g. a generic Sequential and a generic Roland module of higher complexity. This should probably stay with the main release, but it makes Adaptations using that no longer standalone and introduces a version dependency between adaptation and Orm main version which is currently unmanaged.
  • Adding new "free" Adaptations simply required to put the adaptation Python file into that directory and then restart. If the Adaptation is faulty though, it could still do harm to the Orm in the worst case preventing proper startup. The user then is somewhat stuck (change of settings file to point to a different directory required, like a safe-boot mode).
  • Distribution of user Adaptations is also unclear, currently everybody is nice enough to let me know and help, and they all end up here, kind of a curated list of Adaptations as I can code review if desired, but of course I cannot test the devices which I do not have.

Ideas:

  • If we change the adaptation extension to .knobkraft or similar, we could associate the Orm with that file extension and a simple double click could make it import that adaptation file (needs existing check/versioning warning...) This would also better differentiate adaptations from helper functions.
  • The Orm could also get a simple "import adaptation" function, which exposes this method. Probably the setup page is the right place for this.
  • In terms of distribution, we'd like something with versioning. So the first idea would be to use a separate github repo and maybe have the Orm use the github REST API to pull adaptations from there. We probably need some user interface to show the user the currently installed adaptation versions, and the available versions, and a way to update or rollback? A bit like the pip dialog of PyCharm. Question is how people get write access to that repo if they want to contribute.
  • We could also forsake the github repo and just use an Internet database like Firebase or Dynamo to put stuff. But that has less transparency. Only advantage would be that we have no problems with permissions as we can control it.

@christofmuc
Copy link
Owner Author

One more idea came up in #276 by @mslinn:

"How might people contribute pull requests from their adaptions? The most manageable approach would require the user to fork the KnobKraft-orm repository.

One way to do this would be to add a new menu item that would convert the user adaptation directory into a git repository containing a Partial Clone With Sparse Checkout of the KnobKraft-orm fork. The GitHub command line tool can provide the necessary functionality, and it is available as a Python library. A second new Knobcraft menu item would create a pull request for the new adaptation."

@christofmuc
Copy link
Owner Author

One more from #281:

About shipping adaptations: you could pack one or several adaptations into a zip-file, and change the extension to .knobkraft. The app can register that extension and import the contents when the user double-clicks the file.

Originally posted by @bboc in #219 (comment)

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

No branches or pull requests

1 participant