Kodi Community Forum

Full Version: [py] how to refresh 'settings.xml'?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm writing an addon where I make changes to the settings.xml file in order to produce an extra button, but I can't figure out how to tell xbmc to read the xml file again programatically. This is what I'm doing:
I'm trying this command:
__settings__.openSettings()

if "plusurl" in sys.argv[1]:
plus_imdb_url = ' <setting label="IMDB Watchlist URL" type="tex$
SETTINGS_LIST.insert(-11,plus_imdb_url)
newsettings=open(SETTINGS_XML, "w")
for item in SETTINGS_LIST:
newsettings.write("%s" % item)
newsettings.close()
__settings__.openSettings()

openSettings does indeed open the settings window for my addon, but it does not read the file anew. Pressing back, then going forward will reveal the new field.

I see that setting buttons may be conditionally visible, but I don't see how to make the condition the press of a button on the same page, but rather the state of other options. I could, for example, have an enum setting asking how many URL fields are to be used, but I prefer an 'add url' button.
use the api for setting settings.
Another fundamental blunder - excuse me. I can of course just use the script to set a value on an invisible setting, then the extra field should appear once the value changes.
Is it the xbmcaddon.setSetting(id,value) api you refer to? I'm using this and it's not overwriting the "default" value defined in settings.xml. I know the value I'm trying to write is a string, there's no exit error, and I know that section of the code is being triggered. In the meantime I'll just use an enum setting.
I don't think the dialog is refreshed after executing a script with the action="" option.

I have a similar section where I only want to show the next field if the previous field is used. My xml is below:
Code:
<category label="Sources">
    <setting id="auto-play" type="bool" label="30905" default="false"/>
    <setting id="sorting-enabled" type="bool" label="30900" default="false"/>
    <setting id="host-rank" type="text" label="30901" enable="!eq(-1,false)" />
    <setting id="first-sort" type="enum" values="None|Host|Verified|Quality|Views|Multi-part" label="30902" default="0" enable="!eq(-1,false)" />
    <setting id="first-sort-reversed" type="bool" label="30903" default="false" enable="gt(-1,0)+!eq(-2,false)"/>
    <setting id="second-sort" type="enum" values="None|Host|Verified|Quality|Views|Multi-part" label="30904" default="0" enable="gt(-2,0)+!eq(-3,false)" />
    <setting id="second-sort-reversed" type="bool" label="30903" default="true" enable="gt(-1,0)+gt(-3,0)+!eq(-4,false)"/>
    <setting id="third-sort" type="enum" values="None|Host|Verified|Quality|Views|Multi-part" label="30904" default="0" enable="gt(-2,0)+gt(-4,0)+!eq(-5,false)" />
    <setting id="third-sort-reversed" type="bool" label="30903" default="true" enable="gt(-1,0)+gt(-3,0)+gt(-5,0)+!eq(-6,false)"/>
    <setting id="fourth-sort" type="enum" values="None|Host|Verified|Quality|Views|Multi-part" label="30904" default="0" enable="gt(-2,0)+gt(-4,0)+gt(-6,0)+!eq(-7,false)" />
    <setting id="fourth-sort-reversed" type="bool" label="30903" default="true" enable="gt(-1,0)+gt(-3,0)+gt(-5,0)+gt(-7,0)+!eq(-8,false)"/>
    <setting id="fifth-sort" type="enum" values="None|Host|Verified|Quality|Views|Multi-part" label="30904" default="0" enable="gt(-2,0)+gt(-4,0)+gt(-6,0)+gt(-8,0)+!eq(-9,false)" />
    <setting id="fifth-sort-reversed" type="bool" label="30903" default="true" enable="gt(-1,0)+gt(-3,0)+gt(-5,0)+gt(-7,0)+gt(-9,0)+!eq(-10,false)"/>
   </category>

similarly, you could have a list of url fields with an Add button after each one. Start off with only field 1 and button 1 enabled. When the user changes button one, show field two and button two, but hide button one, leaving you with field 1, field 2, and button 2 showing. The buttons could be enums with values of Add and Remove. Hope that helps
it won't write the settings.xml in the add-on folder, correct. we never write that one. we write the one in the userdata/addon_data/<id> folder - where all writing should happen. you cannot assume the addon is running from a writable folder.