StreamDeckDotnet

StreamDeckDotnet is a full framework for handling communication with an Elgato Stream Deck. It uses a Giraffe-like pipeline builder for simple, readable, and concise event pipelines.

Events are handled in a pipeline with filters:

open StreamDeckDotnet
open StreamDeckDotnet.Routing.EventBinders
open StreamDeckDotnet.Types.Received

let routes : EventRoute = choose [
    // functions can be added to the pipeline, like this logging function,
    // which appends a log to the context's events to send back to the Stream Deck
    KEY_DOWN >=> Core.log "in KEY_DOWN handler" >=> tryBindKeyDownEvent errorHandler keyDownHandler
    PROPERTY_INSPECTOR_DID_APPEAR >=> Core.log "in WILL_APPEAR handler" >=> tryBindEvent errorHandler appearHandler
  ]

tryBindKeyDownEvent will bind the payload from a KEY_DOWN event and pass that to the given handler, allowing you to skip right to the parts you care about.

The handler also gets an EventContext, which it writes outbound events to and can peek at event metadata when needed.

let keyDownHandler (keyPayload : KeyPayload) next (ctx : EventContext) = async {
  match ctx.TryGetContextGuid() with
  | Some contextId ->
    // helper functions allow for chaining
    let ctx = ctx |> addLogToContext $"In Key Down Handler for context %O{contextId}" |> addShowOk
    return! next ctx
  | None ->
    // The context itself is an object, so it can have fields modified.
    ctx.AddLog($"In key down handler, no context was found")
    ctx.AddAlert()
    return! next ctx
}

Creating the stream deck itself only requires the application arguments and the routes:

[<EntryPoint>]
let main argv =
  let args = ArgsParsing.parseArgs argv
  let client = StreamDeckClient(args, routes)
  client.Run()

See the ExampleProject folder for a full example of a plugin, a Fable-based Property Inspector, and a shared data structure between them.

NuGet

Package	Stable	Prerelease
StreamDeckDotnet
StreamDeckDotnet.Fable

Testing and developing a plugin

On macOS:

Plugins live in ~/Library/Application Support/com.elgato.StreamDeck/Plugins/ Logs live in ~/Library/Logs/StreamDeck/

Debug a property inspector from this link - See this link from elgato for more info

elgato docs: https://developer.elgato.com/documentation/stream-deck/sdk/events-received/#didreceivesettings

Stream Deck Mimic

This in-progress tool is designed to mimic a Stream Deck Application but with more visibility into what exactly is being sent & received. It is best to test with the real Stream Deck software when possible, but if you need to peek more into what is being sent, this tool can help.

Currently, the tool has barely any events implemented. Pull requests welcome! There's a lot I want to exapnd on with it and just haven't had the time for it yet.

---

Todos

Mimic

• Set action state
• Set action coordinates
• Batch send events with delays
  • allows testing "double tap key" event types (as an example)
  • allows stress testing
• test multi instance & combine with batch send
• Save last command run
• Save/cache commands to run later
• Load manifest(s) for actions
• Figure out packaging/distribution for consuming
• Figure out how to host the property inspector as well
  • Tie the plugin & the backend together

SD.NET

• Minimize deploy size, either as part of this package and/or as an example
• Do we need some way to send events outside of handling events? eg, timer?

---

Builds

GitHub Actions

---

Developing

Make sure the following requirements are installed on your system:

• dotnet SDK 5.0.404 or higher

or

• VSCode Dev Container

---

Environment Variables

• CONFIGURATION will set the configuration of the dotnet commands. If not set, it will default to Release.
  • CONFIGURATION=Debug ./build.sh will result in -c additions to commands such as in dotnet build -c Debug
• GITHUB_TOKEN will be used to upload release notes and Nuget packages to GitHub.
  • Be sure to set this before releasing
• DISABLE_COVERAGE Will disable running code coverage metrics. AltCover can have severe performance degradation so it's worth disabling when looking to do a quicker feedback loop.
  • DISABLE_COVERAGE=1 ./build.sh

---

Building

> build.cmd <optional buildtarget> // on windows
$ ./build.sh  <optional buildtarget>// on unix

The bin of your library should look similar to:

$ tree src/MyCoolNewLib/bin/
src/MyCoolNewLib/bin/
└── Debug
    ├── net461
    │   ├── FSharp.Core.dll
    │   ├── MyCoolNewLib.dll
    │   ├── MyCoolNewLib.pdb
    │   ├── MyCoolNewLib.xml
    └── netstandard2.1
        ├── MyCoolNewLib.deps.json
        ├── MyCoolNewLib.dll
        ├── MyCoolNewLib.pdb
        └── MyCoolNewLib.xml

---

Build Targets

• Clean - Cleans artifact and temp directories.
• DotnetRestore - Runs dotnet restore on the solution file.
• DotnetBuild - Runs dotnet build on the solution file.
• DotnetTest - Runs dotnet test on the solution file.
• GenerateCoverageReport - Code coverage is run during DotnetTest and this generates a report via ReportGenerator.
• WatchTests - Runs dotnet watch with the test projects. Useful for rapid feedback loops.
• GenerateAssemblyInfo - Generates AssemblyInfo for libraries.
• DotnetPack - Runs dotnet pack. This includes running Source Link.
• SourceLinkTest - Runs a Source Link test tool to verify Source Links were properly generated.
• PublishToNuGet - Publishes the NuGet packages generated in DotnetPack to NuGet via paket push.
• GitRelease - Creates a commit message with the Release Notes and a git tag via the version in the Release Notes.
• GitHubRelease - Publishes a GitHub Release with the Release Notes and any NuGet packages.
• FormatCode - Runs Fantomas on the solution file.
• BuildDocs - Generates Documentation from docsSrc and the XML Documentation Comments from your libraries in src.
• WatchDocs - Generates documentation and starts a webserver locally. It will rebuild and hot reload if it detects any changes made to docsSrc files, libraries in src, or the docsTool itself.
• ReleaseDocs - Will stage, commit, and push docs generated in the BuildDocs target.
• Release - Task that runs all release type tasks such as PublishToNuGet, GitRelease, ReleaseDocs, and GitHubRelease. Make sure to read Releasing to setup your environment correctly for releases.

---

Releasing

• Start a git repo with a remote

git add .
git commit -m "Scaffold"
git remote add origin https://github.com/user/MyCoolNewLib.git
git push -u origin master

• Create your NuGeT API key

  • Add your NuGet API key to paket

  paket config add-token "https://www.nuget.org" 4003d786-cc37-4004-bfdf-c4f3e8ef9b3a

  • or set the environment variable NUGET_TOKEN to your key

• Create a GitHub OAuth Token

  • You can then set the environment variable GITHUB_TOKEN to upload release notes and artifacts to github
  • Otherwise it will fallback to username/password

• Then update the CHANGELOG.md with an "Unreleased" section containing release notes for this version, in KeepAChangelog format.

NOTE: Its highly recommend to add a link to the Pull Request next to the release note that it affects. The reason for this is when the RELEASE target is run, it will add these new notes into the body of git commit. GitHub will notice the links and will update the Pull Request with what commit referenced it saying "added a commit that referenced this pull request". Since the build script automates the commit message, it will say "Bump Version to x.y.z". The benefit of this is when users goto a Pull Request, it will be clear when and which version those code changes released. Also when reading the CHANGELOG, if someone is curious about how or why those changes were made, they can easily discover the work and discussions.

Here's an example of adding an "Unreleased" section to a CHANGELOG.md with a 0.1.0 section already released.

## [Unreleased]

### Added
- Does cool stuff!

### Fixed
- Fixes that silly oversight

## [0.1.0] - 2017-03-17
First release

### Added
- This release already has lots of features

[Unreleased]: https://github.com/user/MyCoolNewLib.git/compare/v0.1.0...HEAD
[0.1.0]: https://github.com/user/MyCoolNewLib.git/releases/tag/v0.1.0

• You can then use the Release target, specifying the version number either in the RELEASE_VERSION environment variable, or else as a parameter after the target name. This will:
  • update CHANGELOG.md, moving changes from the Unreleased section into a new 0.2.0 section
    • if there were any prerelease versions of 0.2.0 in the changelog, it will also collect their changes into the final 0.2.0 entry
  • make a commit bumping the version: Bump version to 0.2.0 and adds the new changelog section to the commit's body
  • publish the package to NuGet
  • push a git tag
  • create a GitHub release for that git tag

macOS/Linux Parameter:

./build.sh Release 0.2.0

macOS/Linux Environment Variable:

RELEASE_VERSION=0.2.0 ./build.sh Release