Mirrored_Repos/obs-websocket
1
0
Fork 0
mirror of https://github.com/Palakis/obs-websocket.git synced 2024-08-30 18:12:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

Docs: Update contributing doc

Browse Source
This commit is contained in:
tt2468 2021-06-14 23:31:42 -07:00
parent 39f2db8723
commit 5e3ed3d167
1 changed files with 20 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
CONTRIBUTING.md
View File

@ -16,9 +16,9 @@ Localization happens on [Crowdin](https://crowdin.com/project/obs-websocket)
* Request and Event names should use MixedCaps names. Keep naming conformity of request naming using similar terms like `Get`, `Set`, `Get[x]List`, `Start[x]`, `Toggle[x]`. * Request and Event names should use MixedCaps names. Keep naming conformity of request naming using similar terms like `Get`, `Set`, `Get[x]List`, `Start[x]`, `Toggle[x]`.
* Request and Event json properties should use camelCase. For more detailed info on property naming, see [here](https://gist.github.com/tt2468/59390b99e7841b28f56dffb3dd622ec9) * Request and Event json properties/fields should use camelCase. Try to use existing property names.
* Code is indented with Tabs. Assume they are 8 columns wide * Code is indented with Tabs. Assume they are 4 columns wide
* 80 columns max code width. (Comments/docs can be larger) * 80 columns max code width. (Comments/docs can be larger)
@ -30,23 +30,31 @@ These are required to automatically generate the [protocol specification documen
* Favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this: * Favor return-early code and avoid wrapping huge portions of code in conditionals. As an example, this:
```cpp ```cpp
if (success) { if (success) {
return req->SendOKResponse(); return RequestResult::Success();
} else { } else {
return req->SendErrorResponse("something went wrong"); return RequestResult::Error(RequestStatus::GenericError);
} }
``` ```
is better like this: is better like this:
```cpp ```cpp
if (!success) { if (!success) {
return req->SendErrorResponse("something went wrong"); return RequestResult::Error(RequestStatus::GenericError);
} }
return req->SendOKResponse(); return RequestResult::Success();
``` ```
* Try to use the [built-in](https://github.com/Palakis/obs-websocket/blob/master/src/requesthandler/rpc/Request.h) request checks when possible.
* Refer to existing requests for usage examples.
* Some example common response/request property names are: * Some example common response/request property names are:
* `sceneName` - The name of a scene * `sceneName` - The name of a scene
* `sourceName` - The name of a source * `inputName` - The name of an input
* `fromScene` - From a scene - scene name * `sourceName` - The name of a source (only for when multiple source types apply)
* `sceneItemEnabled` - Whether a scene item is enabled
* Response parameters which have no attributed data due to an invalid state should be set to `null` (versus being left out)
* For example, when `GetSceneList` is called and OBS is not in studio mode, `currentPreviewSceneName` will be `null`
* If a request's core response data depends on a state, an error should be thrown unless `ignoreNonFatalRequestChecks` is set. See `GetCurrentPreviewScene` as an example.
### Commit Guidelines ### Commit Guidelines
@ -64,11 +72,11 @@ return req->SendOKResponse();
**Example commit:** **Example commit:**
``` ```
Requests: Add GetTransitionPosition Requests: Add GetSceneList
Adds a new request called `GetTransitionPosition` which gets the current Adds a new request called `GetSceneList` which returns the current
transition's state from 0.0f to 1.0f. Works with both auto and manual scene, along with an array of objects, each one with a scene name
transitions. and index.
``` ```
### Pull Requests ### Pull Requests
@ -76,7 +84,5 @@ transitions.
* Pull Requests must never be based off your fork's main branch (in this case, `master`). * Pull Requests must never be based off your fork's main branch (in this case, `master`).
* Start your work in a newly named branch based on the upstream main one (e.g.: `feature/cool-new-feature`, `bugfix/fix-palakis-mistakes`, ...) * Start your work in a newly named branch based on the upstream main one (e.g.: `feature/cool-new-feature`, `bugfix/fix-palakis-mistakes`, ...)
* Only open a pull request if you are ready to show off your work.
* If your work is not done yet, but for any reason you need to PR it (like collecting discussions, testing with CI, getting testers), * If your work is not done yet, but for any reason you need to PR it (like collecting discussions, testing with CI, getting testers),
create it as a Draft Pull Request (open the little arrow menu next to the "Create pull request" button, then select "Create draft pull request"). create it as a Draft Pull Request (open the little arrow menu next to the "Create pull request" button, then select "Create draft pull request").