feat: configure syslog from launcher

[phillipivan]

Follow on from #3506 allowing configuration of syslog transport from the electron launcher. It is exposed and hidden by the same cog that reveals the Devloper modules path.

Occasionally after changing parameters an error is returned:

This doesn't seem to be contingent upon if the parameter is valid, and will occasionally trigger from simply enabling syslog. I do not understand why this is.

The logs prior to one such error:

launcher-enable-syslog: true
2025-07-06T09:30:01.386Z Application: trigger companion restart
2025-07-06T09:30:01.386Z Application: trigger companion restart
2025-07-06T09:30:01.714Z Application: Companion exited with code: 1
2025-07-06T09:30:01.714Z Application: Restart Count: 4
2025-07-06T09:31:16.649Z Application: Companion process stopped
2025-07-06T09:31:16.664Z Application: Companion process started

Other than that it seems to work.

@Julusian I'm sure you had something far more elegant in mind, UI wise. If you can point me towards some examples of what you had in mind I will do my best.

[Julusian]

I think this needs to be done in a settings modal/window.
With the amount of fields this adds, it makes this window rather messy, especially when only a tiny fraction of users will need to interact with these fields.

Unfortunately I don't have any examples to point to for this, as this current ui of the launcher is incredibly minimal and basic. It might be time to make this ui be its own vite project, or maybe the settings window could be done as its own html file inside the same webui bundle? (the challenge then would be serving that ui when the companion http isnt running)
It would make sense to use the same ui style as the main ui (or it could be styled on its own.

If you don't feel up to figuring out that workflow, I can deal with this (ideally the module path would move there too) then you can add the syslog stuff there once the structure is in place

[dnmeid]

Wow, Companion v36! Future is calling.

What do you think about replacing the cog that reveals all options by an accordion?
There could be one section for the developer modules and one for the syslog.
This would also be good for another 2-4 sections before we need to rethink the overall design of the launcher.

[Julusian]

What do you think about replacing the cog that reveals all options by an accordion?

I suspect that will be tricky to make nice. I remember when first making this dual height it was a bit fiddly to get that to work correctly on every os. When the cog is clicked that triggers a size check and explicit resize of the window. But it would be fine if done without animations.
But if making it an accordian is not too painful to do then I am open to that

[phillipivan]

If you don't feel up to figuring out that workflow, I can deal with this (ideally the module path would move there too) then you can add the syslog stuff there once the structure is in place

Pragmatically this is going to produce the fastest and best result, whether a modal is used or an accordion. This is really my first stab at anything 'frontendy' so Im sure it will be full of misteps.

[arikorn]

As long as you're talking about redesigning this, it might be nice to give that window the standard title bar and caption controls. (I just figured out, while typing this, how to minimize the launcher window -- silly how much we depend on the standard cues, but that's life...)
BTW, in terms of layout, increasing width, rather than height of the window for this new stuff, might look neater -- although maybe not compatible with accordion?

[arikorn]

Another issue: if you turn the cog "off" (i.e. hide the dev modules path), it disables the dev module. This behavior made sense in previous version where it would just revert to the non-dev version of the module. But in v4.0+ it results in an error instead, since you explicitly select the dev module in the Connections tab and it doesn't automatically revert to a non-dev module (regardless of Update Policy). See screenshot.

My preference would be to allow the dev module regardless of the cog state. I could probably fix this myself, but don't want to cause a code-conflict with this work. Let me know either way if one of you can do it, or I should raise a separate issue and fix it myself, or....? Thanks!

[Julusian]

I am taking a bit of a look at this, while I still have some motivation for UX polishing. I havent really touched the settings side of this yet, but tweaking the other bits:

BTW, in terms of layout, increasing width, rather than height of the window for this new stuff, might look neater -- although maybe not compatible with accordion?

This might be an idea, a toggle to show/hide a right panel attached to this, for the advanced configuration stuff.

But I worry that this will make this panel feel messy, and a bit jarring. I like the simplicity and sleek look of this window currently, so am still leaning towards a 'full' larger config window. I dont know if there are more things we will add to it over time, but there are things that probably should be defined in it.
For example, if we want to start down the route of making companion actually 'secure' we should offer an option to disable executing shell scripts, that would only work if defined in this launcher.
Maybe we should let the user change the loglevel that gets written to disk?
I've been wanting a way to let the user cleanup the dbs from old companion versions, which would be better to do here than inside companion
Im sure there are more, so making this into more a more fleshed out 'environment settings' ui would make sense