Configure settings from URL parameter

[lyze]

Thank you for taking a look at PR #19 earlier today. I followed the documented contributing process and I wasn't aware there I had to consult beforehand, so I apologize for that. I don't mind if this turns out to be wasted work: it was very little work for me in the first place.

I do want to address some of your comments to see if I could clarify the story around this particular FR.

tl;dr: This would be nice to have, but there's a reasonable workaround with persistent storage in the OBS BrowserSource plugin.

there is no way to provide a user with a valid URL as there is no way to know what host/port they are using

The socket service in ember works already with ACT with the HOST_PORT parameter. This parameter is obtained from the ACT-websocket plugin address, and so is expected to be user-provided.

and instructing users to add a &settings querystring parameter while maintaining the WSServer-generated URL and not breaking the hash routing

For example, running this with the local development environment (with the ACT websocket port open on 10501) gives a URL of

http://localhost:3000/?HOST_PORT=ws://127.0.0.1:10501/&settings=<the_settings>

which works correctly with the hash routing. This gives a hash URL of

http://localhost:3000/&HOST_PORT=ws://127.0.0.1:10501&settings=#/

No special handling is needed, and when I clicked around, everything seemed to work correctly. (Of course I could have missed something.)

would be far more trouble for 99% of users than just copying and pasting the settings key.

Apart from everything else said above, I do agree with you on this particular topic: This "power user" feature has the possibility to be confusing and complex.

I was wrong about OBS BrowserSource plugin not having persistent storage because it in fact does have persistent local storage. (There was a configuration error on my part that obscured this feature.) However, the interaction feature in OBS is quite limited and hard to use, and the settings panel doesn't work, so a user needs to configure ember first with the vanilla overlay plugin, and then transfer the settings key over.

Other downsides:

1. The URL becomes confusingly long.

2. The behavior of modifying settings with is not obvious: modifying the settings will persist them, but reloading the URL with the settings parameter will revert to the provided settings.

(1) is a cosmetic issue, but potentially not a big deal since the URL is not exposed, unless you are also giving out the ACT-websocket address to others. This can be addressed by rewriting the URL to omit the session parameter.

(2) can potentially also be addressed in the same way by rewriting the URL.

Thank you again for considering this change!

[GoldenChrysus]

The main concerns I have with this are that it requires maintaining a feature that maybe 1% of users would use, it's for something that theoretically only needs to be done once (changing settings in an OBS BrowserSource), and I'm not sure if it actually substantially improves the process.

Some of my concerns:

1. Users are often correctly told (by other people unrelated to Ember, such as the people in the ACT FFXIV Discord) to copy the URL provided by either WSServer or ACTWS into their OBS. It may be confusing to users if we have to instruct them to add &settings=<key> to their URL -- and this runs the risk of confusing non-power users as this instruction would have to be displayed somewhere in Ember or the README near the other setup instructions.

2. As you mentioned, the URL becomes very long. This runs the very small risk of creating a URL that exceeds a browser's limits (depending on the user's settings -- for example, someone could add a substantial amount of CSS and this will become part of the encoded string). But beyond this, we also have to instruct users to remove the &settings=<key> from the URL once it's been added to OBS because, as you mentioned, it will continue to errantly overwrite any post-import changes (especially since things that can easily be changed via interact like the currently active tab are technically part of the settings). Once the URL is exceptionally long, it may be difficult for users to identify what exact piece needs to be removed without breaking their WebSocket connection.

3. I don't necessarily see how this process improves the user experience, even for a power user. If anything, it seems more confusing and time consuming. The current process is to set up a non-OBS overlay, copy the export key, copy the WSServer URL to an OBS BrowserSource, use interact, navigate to import, and paste the key. This is all done via a UI whereas the process this change invites is: set up a non-OBS overlay, copy the WSServer URL, copy the export key, add the export key to the URL, copy this final URL to an OBS BrowserSource, remove the key from the URL, reload the BrowserSource. It's difficult to see any valuable time savings in this process.

You may be interested to know that there is a planned to change to make the UI for exporting and importing more user friendly. Some users report issues either copying or pasting the key based on the relevant version of Chromium, so there will soon be buttons that automatically copy the export key and paste the export key, which has been tested to work as far back as the Chromium version used in version 0.3.4.0 of OverlayPlugin (Chromium 45.0.2454.85). This is documented in #17.

[GoldenChrysus]

This is mostly resolved by the current staging release 0.22.0-alpha which allows the settings panel to work independently of OBS. Information will be added to the streamer installation guide on how to access the settings panel if importing does not work (Streamlabs OBS) or if the user prefers to setup directly in OBS. May also recode the setting cog button to redirect the overlay to the settings URL if it detects it is running inside of OBS, instead of attempting to open a new settings window (not possible in OBS).