add getSceneItemList, getSceneItemTransform & getBrowserInputSettings…#500
Conversation
|
Hi! Just checking in to see if there’s anything I can do to help get this PR reviewed :) I’m happy to split the functionality into smaller PRs or make any changes needed to align with project expectations, just let me know what needs to be done! Thank you and thanks a lot for maintaining the project. |
|
At a glance there doesn't seem to be anything major that you need to do. We review things as we have time, resources, and as priorities allow. |
|
👋 Hey friends, super interested in this as it'd unlock quite a bit for us with automating scene layout bits within a browser source. Anything I can do to help move this forward? |
| Permissions required: READ_USER | ||
| ```js | ||
| /** | ||
| * @typedef {Object} SceneItem |
There was a problem hiding this comment.
Would love to see transform (or at least position) information included for these, if that would be possible?
There was a problem hiding this comment.
I built the feature as closely as possible to the existing WebSocket implementation, and that implementation does not include this.
I also don’t think this needs to be added directly to SceneItem:
With my implementation, you can first retrieve a scene item and then call getSceneItemTransform to get everything you might need: position, rotation, scale, bounds, and even whether it’s cropped (see screenshot 2 above).
There was a problem hiding this comment.
Ah sorry I completely missed that getSceneItemTransform exposes all the scene items and not just the browser source itself!
|
I would love to have this also. Bump |
|
I see that this change allows a browser source to get a list of all the items in a scene, but how would it get its own name and/or sceneItemId? From what I understand, it needs that Id in order to get its own info from |
Call Iterate over them and call (There can be a scenario where a user duplicates a browser source in the same scene where you would end up finding twice or more sources with the same href - but that could and should also be handled easily, if you detect your own href is twice in the scene list -> show error message to the user. If its onces in the lists - its yours. Usually you also don't want to have users add your browser sources more than once per scene - so you can even prevent them to do that with this update.) |
Ah, ok. so similar to how you would do it with obs-websocket. I was asking because a browser source having easy access to it's own name/source ID is something I've been hoping could be added to obs-browser for a long time. It would be very useful to have a source able to manipulate itself with the new functions in this PR or via obs-websocket without having to go through and check all the urls. FWIW, I do actually sometimes find it useful to have multiple browser sources in a scene that are separate sources but have the same url. For instance, having sources of the same page but with a different browser size to use in different circumstances or having sources of the same url using query strings that may currently be the same but have the option to be different. |
This is a follow up to: #499 as the previous approach failed when duplicating a browser source reference.
This time I tried to stay with the implementation more closely with how the WebSocket handles it and giving developers the same flexibility.
Description
This new feature adds:
Motivation and Context
I decided to bundle these three functions into a single PR since they are closely related:
How Has This Been Tested?
Environment: Windows 11 x64, OBS Studio 31.1.2 (build 104)
Types of changes
New feature (non-breaking change which adds functionality)
Documentation (a change to documentation pages)
Checklist: