Upgradable: Announcing Beta 1 of TiddlyWiki 2.4.0

[Jeremy Ruston]

I'm delighted to announce beta 1 of release 2.4.0 of TiddlyWiki:

http://www.tiddlywiki.com/beta/

There's a full list of changes at
http://trac.tiddlywiki.org/wiki/History. The highlights are:

* Automated core upgrades
* Sensible saving in Safari and Opera, via the newly signed
TiddlySaver java applet
* Easier customisation of toolbars through the new ToolbarCommands
shadow tiddler
* Usability improvements for ImportTiddlers
* New date format symbol TZD for ISO timezone support
* Support for multiple tag selection by holding down the control key
* Enhanced GradientMacro
...and several bug fixes

As ever, this release is very much a group effort, with valuable
contributions from MartinBudden, SaqImtiaz, BidiX, EricShulman, FND,
XavierVerges, JayFresh and many others. I appreciate everyone's help
very much, and I must apologise that I've been personally negligent in
letting this release lag so long after 2.3.0 back in December 2007.

Please reply to this message with any questions or comments. I'd very
much appreciate comments or improvements on the text for the user
interface of the new core upgrade process.

Cheers

Jeremy.

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[wolfgang]

Hi Jeremy,

thanks for the new version. I tried it with a TW I'm working on,
making some StyleSheets compatible with the - not so new anymore -
theme switching mechanism by using Eric's SwitchThemePlugin.

However, that doesn't works anymore at all. :-(

So I'm wondering if this function to switch themes has been removed? -
Or does it use a different method with which this plugin isn't
compatible any more?

Regards,

W.

Jeremy Ruston schrieb:

[Eric Shulman]

On Apr 13, 5:37 pm, wolfgang <wolfgangl...@gmail.com> wrote:
> Hi Jeremy,
>
> thanks for the new version. I tried it with a TW I'm working on,
> making some StyleSheets compatible with the - not so new anymore -
> theme switching mechanism by using Eric's SwitchThemePlugin.
>
> However, that doesn't works anymore at all. :-(
>
> So I'm wondering if this function to switch themes has been removed? -
> Or does it use a different method with which this plugin isn't
> compatible any more?

GRRRR!! This is frustrating...

The problem is that the values for tracking the current pageTemplate,
styleSheet, and colorPalette used to be stored in an object called
config.refreshers.* (for TW231)
but are now stored in
config.refresherData.* (for TW240b1)

HOWEVER... there are several places in the TW240b1 core implementation
of the switchTheme() function that are still referencing
config.refreshers. In addition, while I had attempted to prepare the
SwitchThemePlugin to work with either object reference, it was not
completely transparent to the core changes for TW240b1.

I'm working on a fix/patch for the plugin that will be compatible with
both TW231 and TW240b1, and I am opening a ticket so that the fixes
can be added to TW240 as well.

I'll post a followup when it is available...

-e

[Eric Shulman]

> I'm working on a fix/patch for the plugin that will be compatible with
> both TW231 and TW240b1, and I am opening a ticket so that the fixes
> can be added to TW240 as well.
>
> I'll post a followup when it is available...

Fixed SwitchThemePlugin for compatibility with both TW231 and TW240b1

Get the updates here:
http://www.TiddlyTools.com/#SwitchThemePlugin
http://www.TiddlyTools.com/#SwitchThemePluginInfo
http://www.TiddlyTools.com/#SwitchThemePluginPatch

Also note a change in the slice name convention used for 'web' (read-
only) themes. Previously, the templates slices were named
WebPageTemplate
WebViewTemplate
WebEditTemplate
However, for compatibility with TW240 core conventions, these are now
PageTemplateReadOnly
ViewTemplateReadOnly
EditTemplateReadOnly

-e

[wolfgang]

My Goodness Eric,

you wrote this patch in just a little over one hour!

> GRRRR!! This is frustrating...

I consider this an amazing frustration management ... ;-)

thanks for this update again,

W.

[FND]

> I'm delighted to announce beta 1 of release 2.4.0 of TiddlyWiki

Good job, everyone!
I think this is an important step forward.

Before I get into overall testing, I have some concerns about the
upgrade mechanism (also posted on Trac[1]):
* using alert() to confirm the upgrade might be a bit crude - a
proper UI notification might be better here
* there is a link to CoreUpgrades on the community wiki - however,
that page does not exist yet (as discussed before, there are also some
issues with establishing that kind of "official" link between TiddlyWiki
itself and the community resource at this point)
* there is no check to prevent upgrading while viewing over HTTP
* it seems that an upgrade is performed regardless of whether a new
core version is available or not - a conditional message displaying the
current status would be highly desirable

About the last issue, checking for a new version before upgrading, this
could be achieved in a number of ways (as discussed in the original
thread[2]):
* Cook generates a simple version info file, which is checked when
opening the upgrade wizard
* instead of having Cook generate the version info file, the SVN
repository's version.js might be used.
* instead of using a version info file, the latest empty.html's
version info is checked
For obvious reasons, the first option is the most desirable one.

-- F.

[1] http://trac.tiddlywiki.org/ticket/554#comment:3
[2] http://groups.google.com/group/TiddlyWikiDev/t/c12866467a03f929/

[Jeremy Ruston]

> * using alert() to confirm the upgrade might be a bit crude - a
> proper UI notification might be better here

I did look at some other options, but the thing here is that the modal
behaviour is desirable, and alert() is easier/shorter than trying to
emulate a modal dialogue with the DOM.

> * there is a link to CoreUpgrades on the community wiki - however,
> that page does not exist yet (as discussed before, there are also some
> issues with establishing that kind of "official" link between TiddlyWiki
> itself and the community resource at this point)

Yeah, I put it there so that people would comment on it :)

I like the idea of linking into the wiki, but yes we'll need some
content there before the beta finishes.

> * there is no check to prevent upgrading while viewing over HTTP

Ooops, thanks for that, could you very kindly raise a ticket?

> * it seems that an upgrade is performed regardless of whether a new
> core version is available or not - a conditional message displaying the
> current status would be highly desirable

> About the last issue, checking for a new version before upgrading, this
> could be achieved in a number of ways (as discussed in the original
> thread[2]):
> * Cook generates a simple version info file, which is checked when
> opening the upgrade wizard
> * instead of having Cook generate the version info file, the SVN
> repository's version.js might be used.
> * instead of using a version info file, the latest empty.html's
> version info is checked
> For obvious reasons, the first option is the most desirable one.

In the interests of keeping things simple, I favour the final option
because it doesn't require changes to the publication process. Could
you kindly ticket it?

Many thanks,

Jeremy

>
>
> -- F.
>
>
> [1] http://trac.tiddlywiki.org/ticket/554#comment:3
> [2] http://groups.google.com/group/TiddlyWikiDev/t/c12866467a03f929/
>
>
>
> >
>

--

[FND]

> I did look at some other options, but the thing here is that the modal
> behaviour is desirable, and alert() is easier/shorter than trying to
> emulate a modal dialogue with the DOM.

I figured it was something like that - fair enough, that should do then.

> I like the idea of linking into the wiki, but yes we'll need some
> content there before the beta finishes.

>> * there is no check to prevent upgrading while viewing over HTTP
>
> Ooops, thanks for that, could you very kindly raise a ticket?

Done:
http://trac.tiddlywiki.org/ticket/584

> In the interests of keeping things simple, I favour the final option
> because it doesn't require changes to the publication process.

The problem with this approach is that it takes a rather long time to
load the entire empty.html.
Generally that's not a huge problem - but it kinda prevents an
(optional) macro to periodically check for updates...

> Could you kindly ticket it?

Done:
http://trac.tiddlywiki.org/ticket/585

-- F.

[Simon Baird]

On Mon, Apr 14, 2008 at 3:52 PM, Eric Shulman <elsd...@gmail.com> wrote:

HOWEVER... there are several places in the TW240b1 core implementation
of the switchTheme() function that are still referencing
config.refreshers.

Aren't these bugs, ie hopefully to be fixed before 2.4 comes out of beta?

--
simon...@gmail.com

[Eric Shulman]

> Aren't these bugs, ie hopefully to be fixed before 2.4 comes out of beta?

Yes, they are... of course, that's why there is a beta...

-e

[FND]

> Yes, they are... of course, that's why there is a beta...

If they're core bugs, you shouldn't have to adjust your plugins though?!

Anyway, could you raise a ticket, maybe even submit a patch?

-- F.

[Eric Shulman]

On Apr 14, 7:31 am, FND <F...@gmx.net> wrote:
> > Yes, they are... of course, that's why there is a beta...
>
> If they're core bugs, you shouldn't have to adjust your plugins though?!

The SwitchThemePlugin implemented some additional handling in TW231
that is supposed to be integrated into the core for TW240. The plugin
patch provides compatibility for current users of TW231 (as well as
temporary fixes for users of TW240b1). Once these fixes are in the
core, the patch will not be needed for TW240 (but will still be useful
for users of TW231 who may not upgrade right away)

> Anyway, could you raise a ticket, maybe even submit a patch?

I will be doing so shortly.

-e

[bob]

I wish import had an option to skip/ignore shadow tiddlers, so only
user content would be imported.
--
Bob

[Paco Rivière]

With this new upgrading feature it would make a lot of sense to add an
option to chose the interface language, that would import the
corresponding Lingo tiddler, therefore making finally TW really
multilingual.

On Apr 13, 10:00 pm, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> I'm delighted to announce beta 1 of release 2.4.0 of TiddlyWiki:
>
> http://www.tiddlywiki.com/beta/
>

> There's a full list of changes athttp://trac.tiddlywiki.org/wiki/History. The highlights are:

[Jeremy Ruston]

Yes, that's a great idea, although I guess we also need a better story
for initially downloading and setting up a translated tiddlywiki in
the first instance.

Hmmm although thinking about it, I wonder if this translation
functionality mightn't be simpler if it was separate from the upgrade
process. We could, for instance, add a 'language' tab the backstage
area that let you select a translation lingo tiddler from
tiddlywiki.org to replace any currently loaded lingo tiddler. The
issue of ensuring that the lingo tiddlers were updated during an
upgrade could then be handled as a special case of the mechanism we'll
need for updating plugins during an upgrade.

Cheers

Jeremy

--

[Paco Rivière]

Catalan Lingo for 2.40. beta1 is ready: http://pacoriviere.googlepages.com/TW2.4.0-beta.html

What about a beta version of this functionality?

[Paco Rivière]

It does make less sense for me to add a separate language tab.

[Morris Gray]

Great job! Where would one find the syntax for things like ALT
attribute for images or Enhanced <<saveChanges>> macro to take
optional custom label and tooltip ? I thought the syntax for usage
would be with the code on the ticket like the enhanced gradient macro
has. Where can I find it??

Morris

On Apr 14, 6:00 am, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> I'm delighted to announce beta 1 of release 2.4.0 of TiddlyWiki:
>
> http://www.tiddlywiki.com/beta/
>

> There's a full list of changes athttp://trac.tiddlywiki.org/wiki/History. The highlights are:

[FND]

> I wish import had an option to skip/ignore shadow tiddlers, so only
> user content would be imported.

It's an interesting suggestion, and I've raised a ticket:
http://trac.tiddlywiki.org/ticket/589
However, I doubt that's gonna make it into the 2.4 release. (Beta
testing is mostly to root out bugs; new features should not be added at
this stage.)

-- F.

[FND]

> With this new upgrading feature it would make a lot of sense to add an
> option to chose the interface language, that would import the
> corresponding Lingo tiddler

I agree with Jeremy - this should not be tied to the upgrade mechanism.
Also, where would we get the translations from - and how
reliable/complete are those we already have?
Without having thought about this too much, I tend to favor the plugin
route (as in language-pack tiddler), as I see no real benefit in a
built-in mechanism!?
Nevertheless, I've ticketed it:
http://trac.tiddlywiki.org/ticket/590

(Just to prevent misunderstandings, I think it's important to have a
convenient way to get a localized UI, so I'm not trying to shoot this down.)

Anyway, we should discuss this in a separate thread, as I suspect it's
not something that'll make it's way into the 2.4 release (seeing as
we're already in beta).

-- F.

[FND]

> Where would one find the syntax for things like ALT
> attribute for images or Enhanced <<saveChanges>> macro to take
> optional custom label and tooltip ?

In the code, duh!
Seriously though, that's a good catch. This kind of thing should be
documented on the community wiki - I'll see to that later on.

The ALT attribute is identical to the respective image's title (if
specified).

The SaveChanges macro now takes two optional parameters:
<<saveChanges [label] [tooltip]>>

-- F.

[FND]

> This kind of thing should be
> documented on the community wiki - I'll see to that later on.

And so my horrible memory strikes again - I had added it already, about
a month ago:
http://www.tiddlywiki.org/wiki/SaveChanges_%28macro%29

-- F.

[Paul Downey]

On 15 Apr 2008, at 22:49, Jeremy Ruston wrote:

> let you select a translation lingo tiddler from
> tiddlywiki.org to replace any currently loaded lingo tiddler.

a little off-topic regarding the beta, hence subject change:

In writing some tests for the generateRSS function
I noticed the language element is hard-coded to "en-us".

Some thoughts:

1. if it's hard-coded, it should really be "en-US"

2. maybe this should be taken from "config.locale" value
which is asserted when loading a lingo, e.g.:

http://svn.tiddlywiki.org/Trunk/association/locales/core/zh-Hant/
locale.zh-Hant.js

3. TiddlyWiki.com could offer appropriate lingos based on the
browser language preferences:

http://www.w3.org/International/questions/qa-lang-priorities

Accessing the language from Javascript seems to be available
in most browsers using one of:
navigator.language

window.navigator.language,

navigator.browserLanguage

navigator.userLanguage

Paul
--
http://blog.whatfettle.com

[rhonda]

> * Automated core upgrades

I tested the upgrade feature by downloading an empty 2.4, creating a
couple of tiddlers, saving and then using the Upgrade link in
Backstage...I expected to get the "fake" upgraded page that's
mentioned in the release info.

Instead, I got an automatic "downgrade" to 2.3, plus the test tiddlers
I had created were gone. Does it work this way for others? Not sure if
it's a problem in 2.4 or just what's linked to on tw.com...

Also, Eric, I know you probably have stuff in the new core that many
of us have used Core Tweaks or perhaps plugins for; would it be a pain
to post a list of what we can delete now?

Thanks,
R.

[FND]

> Instead, I got an automatic "downgrade" to 2.3, plus the test tiddlers
> I had created were gone. Does it work this way for others? Not sure if
> it's a problem in 2.4 or just what's linked to on tw.com...

Good catch - seems like a bit of an oversight*.
We'll take care of that, probably releasing a second beta very soon.

-- F.

* actually, Jeremy intentionally put that in there to see whether
anyone's paying attention - looks like you're the only one...

[Paco Rivière]

I was not speaking at code level, but at user interface level. No
matter whether it is with the same code module or not. But think it
should be as an option in the same tab. The option may be disabled if
translations are not available.

Dowey idea about using browser preferences seems the right way to
explore.

FND objection about translations being reliable brings an interesting
point to consider seriously if TW has to be really multilanguage: Is a
lingo checking mechanism necessary?

[Jeremy Ruston]

> Instead, I got an automatic "downgrade" to 2.3, plus the test tiddlers
> I had created were gone. Does it work this way for others? Not sure if
> it's a problem in 2.4 or just what's linked to on tw.com...

Oooops, my mistake. There's supposed to be a little plugin called
BetaUpgradeTestPlugin that overwrites the upgrade source from
"http://www.tiddlywiki.com/empty.html" to point at the fake beta
upgrade at "http://www.tiddlywiki.com/beta/upgrade.html". However, the
plugin is only included in beta/index.html, and not beta/empty.html.

I'll upload a revised beta shortly, but in the meantime you can test
the upgrade mechanism either by importing that BetaUpgradeTestPlugin
from http://www.tiddlywiki.com/beta/index.html, or by testing with
index.html instead of empty.html.

Cheers

Jeremy

>
> Also, Eric, I know you probably have stuff in the new core that many
> of us have used Core Tweaks or perhaps plugins for; would it be a pain
> to post a list of what we can delete now?
>
> Thanks,
>
>
> R.
>
> >
>

--

[Eric Shulman]

> > Anyway, could you raise a ticket, maybe even submit a patch?
>
> I will be doing so shortly.

see http://trac.tiddlywiki.org/ticket/594

-e

[Martin Budden]

Actually, the correct thing to do here is to put the beta at:

http://www.tiddlywiki.com/upgrade/

since the only people doing upgrades are people with the beta. This
means we test the actual upgrade mechanism, rather than a proxy.

(Of course for 2.5, or whatever the next release is, we *will* need to
have a beta upgrade path, eg

http://www.tiddlywiki.com/beta/upgrade/

)

Note also I'm using a more descriptive pathname for the upgrade as well.

Martin