requesthandler: Add Canvas support

[exeldro]

Description

Add Canvas support

Motivation and Context

Scenes in not the main canvas are now not accessible

How Has This Been Tested?

using different obs-websocket clients, calling the new GetCanvasList and calling the other scene call with and without a canvas
Tested OS(s): Windows 11

Types of changes

• New request/event (non-breaking)

Checklist:

• I have read the Contributing Guidelines.
• All commit messages are properly formatted and commits squashed where appropriate.
• My code is not on master or a release/* branch.
• The code has been tested.
• I have included updates to all appropriate documentation.

[PatTheMav]

Canvases (at least per their original concept) are a data structure to allow OBS Studio as well as plugins to generate and access "outputs" that exist in the application. I'd be interested to learn what the use case for a websocket-based client would be to get direct access to this internal data object?

Conceptually a remote control client (what websockets is made for) should not futz around with canvases - it can interact with OBS (which then uses canvases to achieve the required result) or possibly with a plugin (which again might use a canvas to do so), but the fact that canvases exist is not something an external API should even know about.

[pwnyy]

Canvases (at least per their original concept) are a data structure to allow OBS Studio as well as plugins to generate and access "outputs" that exist in the application. I'd be interested to learn what the use case for a websocket-based client would be to get direct access to this internal data object?

Conceptually a remote control client (what websockets is made for) should not futz around with canvases - it can interact with OBS (which then uses canvases to achieve the required result) or possibly with a plugin (which again might use a canvas to do so), but the fact that canvases exist is not something an external API should even know about.

Adding canvas support seems rather important for applications that are communicating over the websocket server, to control and alter scenes, sources and filters on a different canvas. This would be especially true for those people that, for example were previously using a plugin to have a vertical "canvas" and with a third-party application that uses the websocket client alter/create/remove these scenes, sources or filters.

Currently this is not really possible anymore, as the plugin also switched over to the canvas system.

I can potentially see why you don't want the whole canvas object exposed, however a way to differentiate canvases with what scenes or sources are on which canvas and to be able to directly target these things is something that still should be considered. Same as maybe an optional parameter to target a specific canvas, if not set it will use the main canvas, to target things.
Being able to get a list of scenes and their sources etc. in each canvas would be needed in that regard as well, which at the very least this PR would provide

Maybe I'm misunderstanding why it wouldn't be a good idea tho.

[nyewkey]

Canvases (at least per their original concept) are a data structure to allow OBS Studio as well as plugins to generate and access "outputs" that exist in the application. I'd be interested to learn what the use case for a websocket-based client would be to get direct access to this internal data object?

Conceptually a remote control client (what websockets is made for) should not futz around with canvases - it can interact with OBS (which then uses canvases to achieve the required result) or possibly with a plugin (which again might use a canvas to do so), but the fact that canvases exist is not something an external API should even know about.

This change unintentionally breaks workflows for thousands of users relying on tools like Streamer.bot, MixItUp and the Aitum Vertical plugin.

Without Canvas support, external apps can no longer detect or control sources/scenes in vertical canvases; which were fully functional prior to 32.x.

Re-enabling access (even just via an optional canvas parameter) would restore compatibility without exposing internal structures unnecessarily.

This regression effectively breaks compatibility with popular automations and streaming workflows that depend on OBS websocket control.

[PatTheMav]

Maybe I'm misunderstanding why it wouldn't be a good idea tho.

Because canvases as we designed them are black boxes that have no context or meaning to anyone but the creator of a canvas.

OBS Studio knows what its canvases "are" (which one is the main video output, which one is the virtual camera, which one might be OBS Studio's built-in vertical output, whenever the app might get one). Likewise Aitum knows what their canvases "are", their meaning and usage.

But OBS Studio has no clue what those canvases "mean" and it keeps its hands off them: Only Aitum interacts with its canvases, only OBS Studio interacts with its canvases, anything that has no clue about canvases is implicitly interpreted to target the "main" canvas.

Canvases in that sense are designed and implemented to be a data management object for some part of the program to create and manage an output.

Anything beyond that has no contextual information to work with them: Given multiple canvases with vertical resolution, how would another plugin (or websocket client) "know" which one is Aitum's and which one is OBS Studio's? Or the one by yet another plugin (even the multi-track code just picks canvases based on output resolution, not by creator)?

At best you could hope that each creator has used a meaningful human-readable name that allows users to distinguish them, but there is zero concern for that in the design of canvases right now. We need to stop exposing libobs internals that were not designed nor made for public use just because they are "there".