As you might know, the Google Chrome browser does not store cookies for local files - which means TiddlyWiki user options cannot be saved.*
The developers have decided not to fix this issue, for now:
> marking as WontFix. People can still comment on the bug if they feel > it's important, and we can always revisit later on.
So you might want to alert them that this is not an insignificant issue: http://code.google.com/p/chromium/issues/detail?id=535 (All you need is a Google account, which you probably already have for posting on the TiddlyWiki groups.)
> Some example questions: should cookies for file:///c:/foo/ be shared with
> file:///c:/bar/? what about cookies for file://otherhost/baz? should
> cookies from ftp://example.com be shared with http://example.com? what
> about HTML files downloaded to local disk from the Internet, should they
> keep their original context, or intrude that of any HTML code installed
> locally? Lacking clear and consciously defined rules, this is a ticking
> time bomb.
This highlights a systemic problem with TiddlyWiki that anyone with
more that one TiddlyWiki has experienced from time to time. (My
backup files are a mess no matter how hard I try)
On the long term (Google Chrome won't be going away nor changing the
cookie problem) should there be consideration given to using something
like an *.ini type file section in 'store' for storing the present
cookie information?
Morris Gray wrote: > On the long term (Google Chrome won't be going away nor changing the > cookie problem) should there be consideration given to using something > like an *.ini type file section in 'store' for storing the present > cookie information?
I've had wierdness with cookies and TW, upgrades, backups etc. Never quite understood what's was going right or going wrong. An TW option for plain old .ini files would be great.
Another approach which perhaps can be made to work now quickly for GoogleChome woudl be to use the Flashplayers' own cookie system. Some people love to hate Flash, but I believe it has a *lot* to offer TW and vice versa [audio video cookies javascript flex air etcetc]. Adobe AIR for example should make it very easy to have TW truly running as a standalone desktop web app, since AIR speaks javascript actionscript and HTML.
Flash Cookies are known as 'local shared objects' LSO - similar to HTTP cookies, but the default storage size is 100Kb :-) JSON formatted data should work fine to smooth the transmission between TiddlyWiki and Flash
oops, I forgot this link from my previous reply...
HOWTO: SharedObjects for Local Storage AS3
January 10, 2008 drawk
Using SharedObjects in Flash is very simple. Flash has SharedObjects that have been in the player since Flash6 when the introduction of Flash Communication Server which is now Flash Media Server which is releasing version 3 soon (also remote SharedObjects in Red5 <http://osflash.org/red5> is an open source RTMP media server that is based on Flash Media Server). So we can thank this release for SharedObjects, Camera objects, Audio, lots of the NetConnections, protocol enhancements and many other things. However to keep the tips simple we will just touch on the local usage and post a series of posts on these objects.
An alternative to an ini file is to save the settings in the
TiddlyWiki file itself. Heres a plugin I wrote a while ago, that while
far from perfect, allows you to do that:
> > Some example questions: should cookies for file:///c:/foo/ be shared with
> > file:///c:/bar/? what about cookies for file://otherhost/baz? should
> > cookies fromftp://example.combe shared withhttp://example.com?what > > about HTML files downloaded to local disk from the Internet, should they
> > keep their original context, or intrude that of any HTML code installed
> > locally? Lacking clear and consciously defined rules, this is a ticking
> > time bomb.
> This highlights a systemic problem with TiddlyWiki that anyone with
> more that one TiddlyWiki has experienced from time to time. (My
> backup files are a mess no matter how hard I try)
> On the long term (Google Chrome won't be going away nor changing the
> cookie problem) should there be consideration given to using something
> like an *.ini type file section in 'store' for storing the present
> cookie information?
I don't think we should be campaigning to make Chrome do cookies for local files. I think rather it's time we make TiddlyWiki stop using cookies for TW settings. I don't think it was a great idea to begin with.
On Sun, Sep 7, 2008 at 5:45 PM, lewcid <lew...@gmail.com> wrote:
> An alternative to an ini file is to save the settings in the > TiddlyWiki file itself. Heres a plugin I wrote a while ago, that while > far from perfect, allows you to do that:
> > > Some example questions: should cookies for file:///c:/foo/ be shared > with > > > file:///c:/bar/? what about cookies for file://otherhost/baz? should > > > cookies fromftp://example.combe shared withhttp://example.com?what > > > about HTML files downloaded to local disk from the Internet, should > they > > > keep their original context, or intrude that of any HTML code installed > > > locally? Lacking clear and consciously defined rules, this is a ticking > > > time bomb.
> > This highlights a systemic problem with TiddlyWiki that anyone with > > more that one TiddlyWiki has experienced from time to time. (My > > backup files are a mess no matter how hard I try)
> > On the long term (Google Chrome won't be going away nor changing the > > cookie problem) should there be consideration given to using something > > like an *.ini type file section in 'store' for storing the present > > cookie information?
> it's time we make TiddlyWiki stop using cookies for TW settings.
While I generally wouldn't mind that, there are two different types of settings: document configuration and user preferences (think authors vs. readers). I'd love to have an alternative to manually putting code into a ConfigTweaks tiddler - but I how could we allow different users to have different settings (e.g. username, animations) if not with cookies?
Either way, we should have this discussion on [twdev].
> I don't think we should be campaigning to make Chrome do cookies for local > files. I think rather it's time we make TiddlyWiki stop using cookies for TW > settings.
I agree with Saq and Simon, options are mainly attached to a TiddlyWiki, not its location. A kind of ini tiddler that fixes default options in the TiddlyWiki but that can to be set and changed easily with a macro like <<option>> should be great. Ideally changes could affect :
- the default option values and saved in the TiddlyWiki - or temporary option values in the running session.
Also some options can't be set in the TiddlyWiki itself (for example password), but in a kind of user profile attached to a TiddlyWiki (not a location). This user profile could also supersede some default options.
> A kind of ini tiddler that fixes default options in the TiddlyWiki but that
> can to be set and changed easily with a macro like <<option>> should be
The <<cookieManager>> interface includes a "bake cookies" button to
instantly generate a [[CookieJar]] tiddler containing simple
javascript assignment statements that hard-code all of the current
cookie-based settings values using a 'systemConfig' tiddler... and,
the generated code is wrapped in a conditional test, using:
if (config.options.txtUserName="...")
so that the stored settings will only be applied for the current user.
Once the <<cookieManager>> has generated a [[CookieJar]] tiddler, it
can easily be edited to change the values of the individual assignment
statements by hand, or simply re-use the <<cookieManager>> to generate
a new CookieJar based on whatever the current settings are.
By using javascript within the CookieJar instead of creating an
entirely new special-use syntax for that purpose, we get an instantly
robust syntax: not only can you assign the desired values to option
settings, you can also use the CookieJar to reconfigure *any* TW
settings that might have user-specific preference values...
and, if someone knows a little bit of javascript, they can even add
conditional assignments or other programmatic logic to calculate
various option settings dynamically, based on current conditions.
enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
On Sun, Sep 7, 2008 at 7:47 PM, FND <F...@gmx.net> wrote:
> > it's time we make TiddlyWiki stop using cookies for TW settings.
> While I generally wouldn't mind that, there are two different types of > settings: document configuration and user preferences (think authors vs. > readers). > I'd love to have an alternative to manually putting code into a > ConfigTweaks tiddler - but I how could we allow different users to have > different settings (e.g. username, animations) if not with cookies?
Personally I don't care about different users having different settings. For me TW is a single user app hence username doesn't serve much purpose. And if I was publishing something, inconsistent user experience is a negative thing IMO.
On Sun, Sep 7, 2008 at 9:21 PM, Eric Shulman <elsdes...@gmail.com> wrote:
> > A kind of ini tiddler that fixes default options in the TiddlyWiki but > that > > can to be set and changed easily with a macro like <<option>> should be
Coincidently, before the Google Chrome was released I was
experimenting with ways to overcome the irritations caused by cookies
controlling so much and being carried over from one TiddlyWiki to
another (I have a lot of them). I have been using ConfigOptionsMacro
in a few TWs, was trying out Eric's CookieManagerPlugin and had
already loaded StickyOptionsPlugin and finally tried it out today when
the post here reminded me..
With the option "Trigger autosave when an option is saved" ticked;
StickyOptionPlugin seemed to be dragging its feet while I typed a
backup file folder name. It quite humorously was creating a backup
folder for every letter of the name I typed, 'StickyBackup' 12 folders
in all. That's as far as I got. Either it or I needs some tweaking.
ConfigOptionsMacro seems to be reasonably stable but there are a few
things that won't stick like the TiddlySpot password. The backup
folder is not stable it seems to be almost random about using the
folder assigned and keeps adding the backup folder name in front of
every individual TiddlyWiki backup, very odd maybe other TiddlyWikis
are interfering.
Eric's solution works fine however it's a several step process
designed to overcome a built in problem which makes saving/changing
options not as straightforward as it would be if designed into
TiddlyWiki from scratch.
I tried SettingsPlugin a year or more ago, had some problems with it
but never got any replies so I dropped it.
There is no reason why users shouldn't expect to tick options in a
TiddlyWiki without them disappearing when it's uploaded, or affecting
more than one TiddlyWiki, or options disappearing when they clear
their cookies, or finding after creating several dozen tiddlers they
were all done by UserName :-)...... yet again!!
Perhaps if Eric's cookie baking operation could be made automatic and
transparent to the user to the point no secondary actions at all are
required for setting or resetting options we could have the best of
both worlds.
Morris
On Sep 7, 5:45 pm, lewcid <lew...@gmail.com> wrote:
> An alternative to an ini file is to save the settings in the
> TiddlyWiki file itself. Heres a plugin I wrote a while ago, that while
> far from perfect, allows you to do that:
> > > Some example questions: should cookies for file:///c:/foo/ be shared with
> > > file:///c:/bar/? what about cookies for file://otherhost/baz? should
> > > cookies fromftp://example.combeshared withhttp://example.com?what > > > about HTML files downloaded to local disk from the Internet, should they
> > > keep their original context, or intrude that of any HTML code installed
> > > locally? Lacking clear and consciously defined rules, this is a ticking
> > > time bomb.
> > This highlights a systemic problem with TiddlyWiki that anyone with
> > more that one TiddlyWiki has experienced from time to time. (My
> > backup files are a mess no matter how hard I try)
> > On the long term (Google Chrome won't be going away nor changing the
> > cookie problem) should there be consideration given to using something
> > like an *.ini type file section in 'store' for storing the present
> > cookie information?
> My wish is that such a thing would not be required. And that a new user can
> configure TiddlyWiki in an intuitive way.
http://www.TiddlyTools.com/#CookieManagerPlugin provides a very simple, easy-to-use form for viewing, changing or
removing individual cookies, as well as providing the "bake cookies"
and "bake options" buttons. Just one click and the current settings
are preserved in a [[CookieJar]] tiddler that is tagged with
'systemConfig' so it is processed during document startup, the same as
any other plugin. What could be simpler?
In addition, I am working on an update to CookieManager that will
automatically bake the cookie values each time a cookie is set (by
hijacking the core's saveOptionCookie() function), so that the
settings will simply be saved in a [[CookieJar]] tiddler without you
having to do anything at all (except for remembering to save the file
at the end, so the changed settings are preserved).
Of course, the CookieManager interface is not the only way to present
the various settings that the user can configure...
The TW core uses the <<options>> macro to render a table of TW
settings (displayed in the [[AdvancedOptions]] shadow tiddler) to
which plugins can programmatically add their own options. However,
many plugins simply display a self-contained set of option checkboxes
and input fields directly within the documentation of the plugin
tiddler itself, often in a section labeled "Configuration" (or
something similar).
To make it easier to access these individual plugin settings, you can
use
http://www.TiddlyTools.com/#AdvancedOptionsPlugin which automatically gathers all the plugin-defined options together
and assembles a single set of tabs (one for each plugin) that is then
appended to the regular [[AdvancedOptions]] shadow tiddler content
(just below the TW standard <<options>> table). In addition,
http://www.TiddlyTools.com/#CookieManagerPlugin also automatically transcludes its control panel form and generated
CookieJar output into [[AdvancedOptions]] so that all settings,
whether defined by the TW core, individual plugins, or browser-based
cookies, are collected together in one place for easier review and
management.
Lastly, it should be noted that there are some values for which
browser-based cookies are totally appropriate. For example, various
options that modify core behaviors (e.g., animations, autosave,
backups, key-by-key search, etc.) are generally supposed to be
associated with the personal preferences of the *reader*, rather than
the particular document they happen to be viewing at the time.
In addition, TW keeps track of certain ephemeral, transient 'state'
information, such as the open/closed state of sliders and the current
selected tabs in tabsets. These would seem to be a perfect use for
cookies, as these bits of information shouldn't really require any
kind of active, deliberate management by the end user and can easily
and quickly change values many times during the TW document session.
> Perhaps if Eric's cookie baking operation could be made automatic and
> transparent to the user to the point no secondary actions at all are
> required for setting or resetting options we could have the best of
> both worlds.
I'm working on an update to CookieManagerPlugin that will provide
exactly that ability.
> > Perhaps if Eric's cookie baking operation could be made automatic and
> > transparent to the user to the point no secondary actions at all are
> > required for setting or resetting options we could have the best of
> > both worlds.
> I'm working on an update to CookieManagerPlugin that will provide
> exactly that ability.
On Sep 7, 10:21 am, Eric Shulman <elsdes...@gmail.com> wrote:
> thoughts?
> -e
> Eric Shulman
> TiddlyTools / ELS Design Studios
Eric...
I don't yet know enough to judge the possible effect of the existence
of a mass-produced (distro?) disc that includes TW and ...
... a comprehensive library of all of its plugins, as well as pre-
assembled user-generated MicroContent modules, and some supporting
Trust-worthy data source files, and copies of all of the major
browsers, etc...
might affect this "architectural" discussion.
However, I thought I'd at least mention that this is something I am
planning to test relatively soon, just so see if this comment is on
interest within the community.
Regards, (and thanks again for TiddlyTools)
Hans Wobbe
> As you might know, the Google Chrome browser does not store cookies for
> local files - which means TiddlyWiki user options cannot be saved.*
> The developers have decided not to fix this issue, for now:
> > marking as WontFix. People can still comment on the bug if they feel
> > it's important, and we can always revisit later on.
> So you might want to alert them that this is not an insignificant issue:
> http://code.google.com/p/chromium/issues/detail?id=535 > (All you need is a Google account, which you probably already have for
> posting on the TiddlyWiki groups.)
> > As you might know, the Google Chrome browser does not store cookies for
> > local files - which means TiddlyWiki user options cannot be saved.*
> > The developers have decided not to fix this issue, for now:
> > > marking as WontFix. People can still comment on the bug if they feel
> > > it's important, and we can always revisit later on.
> > So you might want to alert them that this is not an insignificant issue:
> > http://code.google.com/p/chromium/issues/detail?id=535 > > (All you need is a Google account, which you probably already have for
> > posting on the TiddlyWiki groups.)
> I don't understand what I should do or where to use this?
Modify the target location of your Google Chrome shortcut, e.g. "C:\Programs\Google Chrome\chrome.exe" --enable-file-cookies (It's been a while since I've done this on Windows, so the placement of the quotation marks might be off.)
