I didn't think I'd be able to make remotely usable requests using OBS'
existing projector API, but I'm actually pretty happy with how it
turned out.
Closes#929
Co-authored-by: Brendan Allan <brendonovich@outlook.com>
It was requested via Discord to be able to modify the private settings
of any private source, since that functionality is used by some client
software to store stateful data. As private settings are in territory
that no normal user should ever tread into, these requests will be left
undocumented.
More docs-related commits will follow, but this needs to be merged in order to continue with other development.
* Docs: Overhaul docs generator (beginning)
* docs: Rename comments file
* docs: Move comments gitignore
* docs: Initial request documentation
* docs: Improvements to comment processing
* docs: More improvements
* docs: Add enum functionality for protocol.json
* WebSocketServer: Document enums
* RequestHandler: Document RequestStatus enum
* Base: Move ObsWebSocketRequestBatchExecutionType to its own file
Moves it to its own file, renaming it to `RequestBatchExecutionType`.
Changes the RPC to use integer values for selecting execution type
instead of strings.
* docs: Update introduction header
Removes the enum section, and documents RequestBatchExecutionType.
* WebSocketCloseCode: Shuffle a bit
* Base: Use `field` instead of `key` or `parameter` in most places
* RequestStatus: Mild shuffle
It was really bothering me that OutputPaused and OutputNotPaused
had to be separated, so we're breaking it while we're breaking
other stuff.
* docs: Delete old files
They may be added back in some form, but for now I'm getting them
out of the way.
* docs: Add enum identifier value
Forgot to add this before, oops
* docs: Document more enums
* docs: Add basic protocol.md generator
* docs: More work on MD generator
* docs: MD generator should be finished now
* docs: More fixes
* docs: More fixes
* docs: More tweaks + add readme
* docs: Update readme and add inputs docs
* docs: More documentation
I realized that it was not entirely fair to expect users to fetch a
scene's item list, then search the list on the client in order to find
an item ID, so this is a compromise. This will also help developers
move from the 4.x scene item functionality to 5.x's
Operating on scene items by relying on source name can be dangerous
and in some cases exhibit what would be considered undefinied behavior.
Operating on scene items using IDs is best practice.
