Save string-valued params in SystemSettings

[Pavlo Shchelokovskyy]

Hi all,

is it possible to save string-valued parameters in SystemSettings tiddler of new TW 2.6.2? I have just upgraded and can not set the name of the folder for backups. When i put

txtBackupFolder: bak

the TW complains about "ReferenceError: bak is not defined" while loading, and if I put

txtBackupFolder: "bak"

then backup folder is literally with quotes "bak" (like ~/mytiddly/"bak"/).

Another strange thing happens with customizing appearance through SystemSettings. Say, I would like to have "Tags" navigation tab be visible at start up, so I try to put

txtMainTab: "Tags"

in the SystemSettings. When I hit "Done" and exit the tiddler, the quotes are not saved, and even more interesting, now this line in real time shows which tab is opened - if I choose Timeline tab, the text in the tiddler also changes to Timeline. And when restarting TW, it complains again with ReferenceError.

Bottom line - is it possible to save any string-valued option as persistent in SystemSettings of TW 2.6.2 or only booleans are allowed there?

[okido]

Hi Pavlo,

Create a tiddler with the name zz_config and tag it systemConfig.

In text area enter:

config.options.txtBackupFolder="bak";


Goodluck, Okido


On Jan 11, 4:27 pm, Pavlo Shchelokovskyy <shchelokovs...@gmail.com>
wrote:

[Pavlo Shchelokovskyy]

Thank you Okido,

actually I used this trick to have persistent settings in the previous version, I was just wondering is this possible with the new Persistent Settings feature.

[PMario]

hi,
do __not__ tag SystemSettings with systemConfig

txtBackupFolder: bak

works fine for me.
-m

On Jan 11, 4:27 pm, Pavlo Shchelokovskyy <shchelokovs...@gmail.com>
wrote:

[rakugo]

Yes you can save strings to SystemSettings
For example adding
txtMainTab: Recent

No need for quotes.
I believe pmario might be right that you may incorrectly have it
tagged systemConfig Can you confirm?

Note the current implementation of SystemSettings is that if you mark
a setting as persistent it will persist each time you save it. For
instance if you set txtMainTab to recent and then change the tab to
tags, it will resave to tags. This has mainly been designed for cases
where you want to share the TiddlyWiki with another user and have
confidence that settings will be the same on their version.

For instance if you set chkAutoSave you may want to make sure that
anyone you send your TiddlyWiki to gets chkAutoSave set as well. In
this case you set it as persistent. Likewise you may want to use your
TiddlyWiki on lots of different computers in which case it may be
useful to persist certain options you use.

Note if you want to force an option for instance make the Tags tab
always open on start the most recent it's best to do what okido
suggests..
Jon

[Pavlo Shchelokovskyy]

Thanks PMario and rakugo,

the problem was really the systemConfig tag. After de-tagging everything is fine. Is this explained somewhere in the docs? I totally missed it :(

And I also came to a conclusion that SystemSettings is saving the state of the TW, not forces it. So for those cases I will use the trick okido points to.

Cheers,

Pavlo.

[Eric Shulman]

> the problem was really the systemConfig tag. After de-tagging everything is
> fine. Is this explained somewhere in the docs? I totally missed it :(
> And I also came to a conclusion that SystemSettings is saving the state of
> the TW, not forces it. So for those cases I will use the trick okido points
> to.

option values are initialized from 4 possible sources, in this order:

1) TW core (hard-coded)
2) cookie value (browser)
3) SystemSettings (tiddler)
4) plugins (tiddlers)

Some plugins use syntax like:
config.options.txtSomePluginOption="somedefaultvalue";
to *hard-code* their default option values. Note: you can assign a
custom value that *overrides* a hard-coded plugin value by creating a
separate "configuration plugin" tiddler, tagged with systemConfig,
that has the re-defined initialization:
config.options.txtSomePluginOption="customdefaultvalue";
Because plugins are processed in alphabetic order by title, the
configuration plugin is traditionally named something like
[[zzConfigSettings]]. The "zz" prefix in the title ensures that it is
the last plugin processed during startup.

Note: while option values may be changed during a TiddlyWiki session,
this type of initialization *ignores* values from steps 1-3, and
always applies the plugin-based settings, even if browser-based cookie
values are available. This effectively turns all option settings into
'session-only' values... reloading the document returns all settings
to their previous, fixed values.

Fortunately, some plugins use a more flexible, conditional approach to
initialization so that values retrieved during steps 1-3 can still be
used, with a *fallback* to the hard-coded value only if no other value
has been defined:
if (config.options.txtSomePluginOption===undefined)
config.options.txtSomePluginOption="somedefaultvalue";
In in addition to allowing cross-session cookie-based options to be
used, this approach to initialization has the advantage of allowing
you to use *any* name for your custom "configuration" tiddler, rather
than forcing you to use the "zz" prefix to control the order of
processing.

Unfortunately, it's important to note that this approach still does
not permit complete portability of settings, as it relies upon browser-
based cookies to hold any non-default persistent values, rather than
storing them in the document, so that they can be applied regardless
of the browser you are using or the storage location of the document.

One way to address this, and achieve truly portable, document-based
settings, is to use
http://www.TiddlyTools.com/#CookieSaverPlugin
Whenever a TiddlyWiki option setting changes, the plugin automatically
stores the value in a systemConfig-tagged tiddler named [[CookieJar]],
containing generated javascript assignment statements using the same
syntax as the 'traditional' zzConfigSettings tiddler (e.g.:
config.options.someTiddler="somevalue";

Because the CookieJar is processed as a plugin, the values stored in
the CookieJar are applied during the normal startup processing.
However, unlike a hand-maintained zzConfigSettings tiddler, the
CookieJar values always reflect the most recent activities. Note: As
with the zzConfigSettings method, you can control the order in which
the CookieJar is processed during startup by adding a prefix to it's
title. You can use a prefix of "." to ensure that the CookieJar is
processed *before* all other plugins, or use a prefix of "_" (or "zz")
to ensure that the CookieJar is processed *after* all other plugins.
Note: you will also need to add the following line (to the .CookieJar)
config.options.txtCookieJar=".CookieJar";
so that the CookieSaverPlugin can still find and automatically update
the renamed tiddler.

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios