Feature request: Running with hard set ports and other options should show in the settings

[inquam]

If the server is run with ports and other options set at the program launch I think that these settings should be reflected in the settings page and perhaps even grayed out so it's obvious it can't be changed. The rationale is if you have a init.d or service start up script that is written to always start without browser and run on port 9999 it would be a bit counter intuitive to have the appearance of being able to change it only to have it start at 9999 every time.

I understand that there can be times where you manually want to start at a given port to be able to set another port in the settings and then restart without a manually set port to use the one you just added to the settings. But perhaps a flag to make options set during launch unchangeable in the settings tab (for the above mentioned scenario for example) would be a nice middle road.

[lad1337]

okay how about
if you set an option by launch argument the option is disabled (only gui)
if you set an option by launch argument and add --allow-option-overwrite the current behavior is used
if you set an option by launch argument and add --set-options the given values are set and changing them is allowed

while we are at it i will try to implement a argument syntax and logic that allows to set/overwrite any configurable value such as plugin values
(only setting them for this runtime might be complicated, for plugin config values)

[inquam]

Would be super... I'm packaging XDM for Amahi Home Server as a 1-click install application and since that creates virtual hosts for applications so that they can be accessed by name and that in turn proxies to the correct port on the server having the user change the ports would break that. Or force people to manually alter the apache vhost config files.

Would --allow-option-overwrite first check config in db and use that if a setting exist or how would it determine if it should use the setting from the command line or the config?

[lad1337]

Would --allow-option-overwrite first check config in db and use that if a setting exist or how would it determine if it should use the setting from the command line or the config?

it would just enable the configuration on the page even if the command line option was set...
then again when XDM restarts it restarts with the given command line options -> neglecting the new configuration

do you have any thoughts on how it should work ? :/

edit: oh and awesome you are working an amahi app :)

[inquam]

omg I wrote such a long an detailed reply that got lost in cyberspace... Well... the condensed version is that what is probably good enough for most cases is.

• Use and show the value of supplied command line arguments instead of values from the DB
• Grey these values out in settings and lock them from being changed
• Display information to the user that these options were supplied by command line and therefore can't be changed without altering the command used to start XDM

This could be extended to allow custom info messages on locked options, the option to lock individual options also receding in DB from being altered and so on. But the above covers most use-cases I think.

Ohhh... I miss my long reply with different perspectives and stuff 😃

[lad1337]

example config file:

{
  "de.lad1337.system":{
    "Default":{
      "port": 8888,
      "show_feed": {"store": true, "value": false, "visable": false},
      "extra_plugin_path": "/Users/lad1337/workspace/xdm-anime-plugin-repo/",
      "login_password": "",
      "login_user": ""
    }
  }
}

this structure allows to define settings for any plugin
the GUI right now has no knowledge of this overwrite !

ps i just noticed the typo in "visable" -> "visible"