Skip to content

Implementing plugins for better separation#39

Merged
luttje merged 87 commits intomainfrom
feature/plugins
Oct 14, 2023
Merged

Implementing plugins for better separation#39
luttje merged 87 commits intomainfrom
feature/plugins

Conversation

@luttje
Copy link
Collaborator

@luttje luttje commented Jun 4, 2023

I want to include midi functionality through DryWetMIDI, but that got me thinking: I'm creeping in so many features and dependencies, perhaps some users don't want all that functionality. Or perhaps they want custom features that I'm not adding. I feel plugins would be a good solution to this, besides being fun to implement.

Key2Joy.Plugin.Midi in this branch shows an early example (e.g: Key2Joy.Plugin.Midi /Mapping/Actions/GetHelloWorldAction.cs). I hope to expand it to a plugin that will add Midi Controller trigger and some Midi writing action capabilities.

Plugins would add:

  • More customization options
  • Lower barrier to contribute
  • Possibility to add features without bloating the main project
  • Possibility to add features without having to wait for me to merge your PR
  • Ability to license plugin code differently from the main project
  • Ability to 'sandbox' plugin code

Some negatives:

  • More complexity
  • More work to maintain
  • Versioning challenges
  • Possible slowdown from inter-process communication
  • Harder to debug: exceptions inside a plugin (or even inside the PluginHost) are hard to catch or notice.

PR Checklist

  • Security risks:
    • Mitigated with code (using AppDomain)
    • Vulnerabilities Tested
    • Users informed
  • Examples and documentation:
    • A plugin example (Key2Joy.Plugin.HelloWorld)
    • Plugin Hosting doesn't feel any slower. Either through optimizations or by pre-loading plugin content (upon enabling the profile).
    • Moved the FFMPEG dependency to a plugin (Key2Joy.Plugin.Ffmpeg) while tackling AnimationFromImagesAction fails due to ffprobe.exe missing #36
    • Have BuildMarkdownDocs also generate plugin markdowns

Postponed

I've crossed these off the original PR checklist. I'm postponing them until I've fixed most bugs people are currently encountering:

  • Considered how to version plugins and implement versioning
  • Designed a way to share and distribute plugins
  • Written documentation on how to create a plugin
  • Diagram of Plugin <- PluginHost -> Key2Joy interaction
  • A plugin example that adds Midi Controller trigger and Midi writing action capabilities (Key2Joy.Plugin.Midi)
  • Moved one of the scripting languages to a plugin (to serve as an example and test case for complex plugins)

These postponed points have been moved to #51 and #52 for tracking)

@luttje luttje added the enhancement New feature or request label Jun 4, 2023
@luttje luttje self-assigned this Jun 4, 2023
@luttje
Copy link
Collaborator Author

luttje commented Jun 7, 2023

Along with this plugin system a lot of refactoring is happening. I'll track bug fixes, features and breaking changes in this post.

⚠ Breaking Changes

  • Old presets will no longer work and will have to be reconfigured. This is due to heavy refactoring and moving from Newtonsoft.Json -> System.Text.Json.
  • The legacy PressAndRelease has been removed. I doubt anyone used it and I shouldn't be supporting legacy stuff before 1.0.0 launch anyway.

New features

  • Plugins
  • In Tools there's a new function to quickly generate the opposite mappings of all mappings selected.

Bugs

  • Fixed crash caused by mouse button trigger capture (when switching to other trigger and clicking somewhere over the mouse button textbox)
  • Fixed action group headings appearing twice in the main form

Known Issues

  • A NullReferenceException occurs in NLua when a user:
    1. Creates a Lua script to show a MessageBox and bind it to a key
    2. Enable mappings
    3. Press the key to open the MessageBox and leave it open
    4. Abort mappings (by pressing escape)
    5. Now close the MessageBox
    6. A NullReferenceException is thrown from inside NLua
      I assume this is because NLua invokes the method and waits for the response. The response is delayed while the MessageBox is open. As soon as we close the MessageBox, I'm fairly certain it's the Lua state, and NLua trying to push the results onto it. By removing environment.Dispose(); the problem is solved. However I need to consider the ramifications of leaving the Lua scripting environment running in the background. It would be nicer to keep track of still running/not yet resolved (scripting) methods (or action Execute for that matter),
      (fixed with daef2f2)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Development

Successfully merging this pull request may close these issues.

1 participant