gh-obsproject/obs-browser

Watch

Fork 0

Inconsistancy with JS hooks #72

New issue

Closed

opened 2017-04-14 15:02:36 -05:00 by SReject · 4 comments

SReject commented

2017-04-14 15:02:36 -05:00

(Migrated from github.com)

1 - Passed Data Typings

With the obsSceneChanged event, <event>.detail is a JS object, similar to:

{height:1080,name:"brb",width:1920}

But with window.obsstudio.getCurrentScene() when the callback is called, the data argument is a non-parsed JSON string, resulting in data having to be passed through JSON.parse() before it is usable:

// data as String: {"height":1080,"name":"brb","width":1920}
window.obsstudio.getCurrentScene((data) => {
    console.log(data); // results in a string
    console.log(JSON.parse(data)); // results in a js object
});

I feel the JSON data of the latter should be parsed into a JS object as it is with the former.

2 - Different design patterns for similar functionality

The interface is all over the place on design for similar functionality sets. For example .onVisibilityChange is a property that gets set with a handler function while other events use the window.addEventListener() methodology.

3 - Incompleteness

Scenes have a getCurrentScene method and an onSceneChange event, but onVisibilityChange doesn't have an accompanying getter function; nor do the obsStreaming* and obsRecording* events.

Win10 - Home Edition
OBS Studio: 18.0.1
BrowserSource: v1.29.0

# 1 - Passed Data Typings With the `obsSceneChanged` event, `<event>.detail` is a JS object, similar to: ```js {height:1080,name:"brb",width:1920} ``` But with `window.obsstudio.getCurrentScene()` when the callback is called, the `data` argument is a non-parsed JSON **string**, resulting in `data` having to be passed through `JSON.parse()` before it is usable: ```js // data as String: {"height":1080,"name":"brb","width":1920} window.obsstudio.getCurrentScene((data) => { console.log(data); // results in a string console.log(JSON.parse(data)); // results in a js object }); ``` I feel the JSON data of the latter should be parsed into a JS object as it is with the former. # 2 - Different design patterns for similar functionality The interface is all over the place on design for similar functionality sets. For example `.onVisibilityChange` is a property that gets set with a handler function while other events use the `window.addEventListener()` methodology. # 3 - Incompleteness Scenes have a `getCurrentScene` method and an `onSceneChange` event, but `onVisibilityChange` doesn't have an accompanying getter function; nor do the `obsStreaming*` and `obsRecording*` events. Win10 - Home Edition OBS Studio: 18.0.1 BrowserSource: v1.29.0

SReject commented

2017-04-15 18:39:42 -05:00

(Migrated from github.com)

I've taken a bit of time, from a ES/JS developer standpoint, to write a short draft of what the interface should look like; it can be found HERE

I've taken a bit of time, from a ES/JS developer standpoint, to write a short draft of what the interface should look like; it can be found [HERE](https://gist.github.com/SReject/ca752da90608363e564d3add5d2c9dbb)

styler commented

2017-11-08 18:36:34 -06:00

(Migrated from github.com)

Any updates regarding this?

OsirisNL commented

2017-12-11 07:56:40 -06:00

(Migrated from github.com)

should be solved now, the code now does JSON.parse on the json string before sending it back, so you get a JS object instead of just a string.
This is probably due to the fact that visibility is not an event fired from the obs frontend api. Not sure since I didn't write that part.
Afaik it is not possible for the source to know if it is visible or not, since there can be multiple instances of the same source in the scene collection and they can all have different visibility states.

1. should be solved now, the code now does JSON.parse on the json string before sending it back, so you get a JS object instead of just a string. 2. This is probably due to the fact that visibility is not an event fired from the obs frontend api. Not sure since I didn't write that part. 3. Afaik it is not possible for the source to know if it is visible or not, since there can be multiple instances of the same source in the scene collection and they can all have different visibility states.

WizardCM commented

2019-12-25 03:13:54 -06:00

(Migrated from github.com)

Alrighty, please review & test #186 which should cover requests 2 and 3. Let me know if I've missed anything you need!

archiver-bot referenced this issue from a commit

2026-09-23 09:56:20 -05:00

obs-browser: merge upstream changes (#137)

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-obsproject/obs-browser#72

No description provided.

Rows
Columns