frontend: Load plugins from config folder in portable mode

[Penwy]

Description

This makes obs look for plugins in the config folder when running in portable mode.
Plugins installed there are expected in the same individual folder structure as plugins installed to C:\ProgramData or ~/.config.
On linux, this restores previous functionality, on windows this is a new addition.

Motivation and Context

This has three purposes :

• It allows keeping core and third-party plugins separate, even when in portable mode.
• On the user's end, it allows for an easier check and removal of third-party plugins.
• On the plugin maintainer's end, this allows for an easier packaging as both portable and non-portable install can now use the same folder structure.

It was motivated by this feature request.

How Has This Been Tested?

Ubuntu 24.04 and Windows 11, ran obs in portable and non portable mode, checked that plugins were loaded correctly.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PatTheMav]

Technically this looks fine, but conceptually I'm not sure I'm the right person to review this.

In my entirely personal opinion the current state of possible locations for plugins on Windows is a bit chaotic:

• Plugins can just be copied into the program installation directory, where they are required to adhere to a specific directory structure, OR
• Plugins can be copied into ProgramData, where they are required to an entirely different directory structure
• This adds yet another possible directory, and I'm not sure which directory structure is required for those to work?

So, again, I'm fine with providing a "portable" plugin location for the portable mode, but I dunno if the config directory is the correct/canonical location for this on Windows and which "plugin standard" (in-tree vs out-of-tree for ProgramData) plugins need to follow for this.

Probably better for some Windows maintainers to respond to.

[Penwy]

As explained in the description, this requires the same structure as the ProgramData plugins, in fact, it works simply by adding the AppConfig path where the non-portable mode adds the ProgramData path.
This is consistent with an intention I saw expressed to make the ProgramData the "correct" install path for third parties on windows non-portable, to keep them distinct from first-party ones.
It also simplifies the headache of knowing what folder structure to use, as there is then one single folder structure that can work for both portable and non-portable, both windows and linux.

There is currently no "canonical" install path dedicated to third party plugins for portable mode on windows, as portable mode only loads from the first party directory. I'm open to having it be another folder on windows, but I'm unsure where else in a portable install it would fit.

[PatTheMav]

As explained in the description, this requires the same structure as the ProgramData plugins, in fact, it works simply by adding the AppConfig path where the non-portable mode adds the ProgramData path. This is consistent with an intention I saw expressed to make the ProgramData the "correct" install path for third parties on windows non-portable, to keep them distinct from first-party ones. It also simplifies the headache of knowing what folder structure to use, as there is then one single folder structure that can work for both portable and non-portable, both windows and linux.

Great, that makes it consistent with where plugin loading should go in the future.

There is currently no "canonical" install path dedicated to third party plugins for portable mode on windows, as portable mode only loads from the first party directory. I'm open to having it be another folder on windows, but I'm unsure where else in a portable install it would fit.

Yeah I think the suggestion in the PR is a decent one, I just didn't want to be the final arbiter of that as a non-Windows user.

[Trouffman]

@PatTheMav as a mutli-OS (Windows / Mac) user and especially user of the portable mode on windows, I can vouch for this approach.

The suggested approach make sense to have :

• The plugin structure in Portable mode, the same as in new default %PROGRAMDATA%
• This would avoid confusion for users as to which "archive" they need to install in portable mode.

Only potential drawback i can see with the code suggested is if the OBS Portable mode is expected to be available for anything else than Windows (aka Linux/MacOS - But this is officially not supported).

Since moving to the new plugin location, we had to re-build some of the logic to have the correct structure for the DistroAV plugin, this is a suggested PR to the plugin-template as well..

I personally would support a unified approach straight in OBS with the same folder structure no matter if portable mode is used or not.

Change Management to consider :

• Plugin in multiple locations - Addressed at PR libobs: Only load modules once #12285
• Most plugin will need to update their archives to provide the proper path (which is already the case to use %PROGRAMDATA% and would be simpler as the Windows Archive will be a drop-in solution.

[Penwy]

Only potential drawback i can see with the code suggested is if the OBS Portable mode is expected to be available for anything else than Windows (aka Linux/MacOS - But this is officially not supported).

While not supported with the released executable, portable mode is available on Linux, and this PR also takes care of that, making plugins load from the config folder on portable mode Linux the same way it does on non-portable Linux, once again with the same, unified, folder structure.

Portable mode is not doable on macos at all afaik.

[Trouffman]

Indeed, I looked again at the code and it is as you described.

Good for me.

[PatTheMav]

@Warchamp7 We should try to lock down the directory names here to get this over the finish line - it's already too late for 31 (due to no fault of the PR itself).

Correct me if I'm wrong but on Windows, the portable structure looks something like this?

.
├── <config>
└── <obs-studio>
    ├── <bin>
    ├── <data>
    └── <obs-plugins>

Which seems wrong to me already, as it requires the user to create a "package" directory first (possibly named "obs-studio") just to house the application and the configuration in the same package.

Ideally you would unzip OBS Studio somewhere, you get an obs-studio directory, and you copy just that one around.

In a good and just world, I'd actually suggest this outcome:

.
└── <obs-studio>
    ├── <bin>
    ├── <config>        # For portable only
    ├── <core>
    ├── <plugins>       # For portable only
    ├── <data>          # Legacy, ignored with v33+
    └── <obs-plugins>   # Legacy, ignored with v33+

OBS Studio's own modules would live in core, using the same structure as third party plugins (each being a package of DLL and associated data). Portable plugins can be placed in the admittedly unintuitively named "plugins" directory, while "legacy" plugins still live in obs-plugins and data until v33 with deprecation warnings attached until we remove support for those directories entirely.

We need to pull the ripcord on this and we need to do it sooner rather than later, hence why I want to have consensus on the outcome first so I can try and put in the work to make this transition happen possibly for v32.

---

I'd love to get rid of the bin directory on Windows as well and also rename the binary to just OBS.exe (the ARM64 binary, if we ship both in the same package would then be called OBSa.exe following some existing practices on Windows), but that would possibly break Windows performance settings that are attached to executable paths and not "app identifiers". So it's probably here to stay.

[Penwy]

Correct me if I'm wrong but on Windows, the portable structure looks something like this?

You are mistaken, both on linux and windows, the config folder is in the same folder as bin, data and obs_plugins, the one "snag" is that the config folder gets created on launch, not on unzip.
Right now the portable structure is

.
└── <base_folder>
    ├── <bin>
    ├── <config>
    ├── <data>
    └── <obs-plugins>

base_folder is usually named obs-studio, but doesn't strictly need to, it's just a containing folder.

[PatTheMav]

Correct me if I'm wrong but on Windows, the portable structure looks something like this?

You are mistaken, both on linux and windows, the config folder is in the same folder as bin, data and obs_plugins, the one "snag" is that the config folder gets created on launch, not on unzip. Right now the portable structure is

.
└── <base_folder>
    ├── <bin>
    ├── <config>
    ├── <data>
    └── <obs-plugins>

base_folder is usually named obs-studio, but doesn't strictly need to, it's just a containing folder.

Interesting, because the CONFIG_PATH is defined as ../../config on Windows and starting at the bin path that should have ended up one level above the base directory.

Oh wait, I forgot the 64bit inside bin, didn't I?

[Penwy]

Oh wait, I forgot the 64bit inside bin, didn't I?

Yup exactly, and that's why it's only .. on linux, because on linux the 64bit folder isn't there.