Announcing Tiddlywiki 2.5.2

[Jeremy Ruston]

We've just released TiddlyWiki version 2.5.2 at:

http://www.tiddlywiki.com/

(We released a version 2.5.1 yesterday, but found and fixed a problem
with the upgrade mechanism almost immediately, hence the re-release).

The big change is the start of the process of breaking off some of the
unique bits of functionality that TiddlyWiki possesses into separate
jQuery plugins that can be used by other developers in other projects.
Besides being good to bring things like local file operations to a
wider audience, part of the benefit will be that the quality of these
pieces of code
will improve through wider usage. For this release, we've concentrated
on TiddlyWiki's cryptographic library, stylesheet manipulation
functions, and local file system code. There's some documentation here:

http://jquery.tiddlywiki.org/

Besides the pluginification, there's the usual mix of bug fixes and tweaks:

- Improved separators and "more/less" extenders for toolbars
- Added plugin version information to the PluginManager
- Fixed Tags macro to respect the excludeLists tag
- Fixed problem with saving of extended tiddler fields

For the full list of changes see http://trac.tiddlywiki.org/wiki/History

Many thanks to the contributors and testers for this release. Please
let us have any comments here,

Cheers

Jeremy

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

[Gnosos]

Thanks for the update and the great service!

Now my question.

I noticed that the $.twFile documentation doesn't have the Demo yet.
Yet it seems to address my current need (http://groups.google.com/
group/TiddlyWiki/browse_thread/thread/60fd809a5a8d5204). So, my
question is would the following work to bring a javascript into the
current page?

$.twFile.load(<local path to a *.js file>);
$.twFile.init();

On Jun 24, 9:04 am, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> We've just released TiddlyWiki version 2.5.2 at:
>
> http://www.tiddlywiki.com/
>
> (We released a version 2.5.1 yesterday, but found and fixed a problem
> with the upgrade mechanism almost immediately, hence the re-release).
>
> The big change is the start of the process of breaking off some of the
> unique bits of functionality that TiddlyWiki possesses into separate
> jQuery plugins that can be used by other developers in other projects.
> Besides being good to bring things like local file operations to a
> wider audience, part of the benefit will be that the quality of these
> pieces of code
> will improve through wider usage. For this release, we've concentrated
> on TiddlyWiki's cryptographic library, stylesheet manipulation
> functions, and local file system code. There's some documentation here:
>
> http://jquery.tiddlywiki.org/
>
> Besides the pluginification, there's the usual mix of bug fixes and tweaks:
>
> - Improved separators and "more/less" extenders for toolbars
> - Added plugin version information to the PluginManager
> - Fixed Tags macro to respect the excludeLists tag
> - Fixed problem with saving of extended tiddler fields
>

> For the full list of changes seehttp://trac.tiddlywiki.org/wiki/History

[FND]

N.B.:
Strictly development-related issues are better discussed on the dev group:
http://groups.google.com/group/TiddlyWikiDev/
You're more likely to get competent help there.

> would the following work to bring a javascript into the current page?
> $.twFile.load(<local path to a *.js file>);
> $.twFile.init();

That alone would not suffice, as you'd only be loading the file contents
into a variable (although your sample code is missing the variable
assignment) without actually evaluating the code.

If you just want to dynamically load JavaScript files, try the following:
var filePath = "..."; // relative or absolute URI
jQuery('<script type="text/javascript">').attr("src", filePath).
appendTo(document.body);

However, if you're loading TiddlyWiki plugins there, you might run into
load-order and variable-scope issues with some of them. (See the
previous discussions on this subject.)

-- F.

[Paulo Soares]

Thank you all for the release.

Can anyone say a few words about:

# Toolbar command ">" now toggles between more/less (ticket #608)
# Toolbar command ">" displays additional commands on separate line
(ticket #608)

I don't see this working on tiddlywiki.com.

Cheers,
--
Paulo Soares

On 24 Jun, 14:04, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> We've just released TiddlyWiki version 2.5.2 at:
>
> http://www.tiddlywiki.com/
>
> (We released a version 2.5.1 yesterday, but found and fixed a problem
> with the upgrade mechanism almost immediately, hence the re-release).
>
> The big change is the start of the process of breaking off some of the
> unique bits of functionality that TiddlyWiki possesses into separate
> jQuery plugins that can be used by other developers in other projects.
> Besides being good to bring things like local file operations to a
> wider audience, part of the benefit will be that the quality of these
> pieces of code
> will improve through wider usage. For this release, we've concentrated
> on TiddlyWiki's cryptographic library, stylesheet manipulation
> functions, and local file system code. There's some documentation here:
>
> http://jquery.tiddlywiki.org/
>
> Besides the pluginification, there's the usual mix of bug fixes and tweaks:
>
> - Improved separators and "more/less" extenders for toolbars
> - Added plugin version information to the PluginManager
> - Fixed Tags macro to respect the excludeLists tag
> - Fixed problem with saving of extended tiddler fields
>

> For the full list of changes seehttp://trac.tiddlywiki.org/wiki/History

[Alex Hough]

If you put "<" into ToolbarCommands, a 'less' is produced when the
toolbar is expanded....

ALex

2009/6/24 Paulo Soares <psoar...@gmail.com>:

--
http://www.multiurl.com/g/64

[Eric Shulman]

> If you put "<" into ToolbarCommands, a 'less' is produced when the
> toolbar is expanded....

ToolbarCommands definitions now support the following special symbols:

> = more - menu items following > are hidden until "more" is clicked
< = less - hides menu items
| = line - visual group seperator (no action)
* = newline - insert linebreak in menu (multi-line menu)

for example

foo bar > < * mumble frotz | gronk snork snerfle

looks like:
foo bar more
and, when 'more' is clicked:
foo bar less
mumble frotz | gronk snork snerfle

enjoy,
-e

[Måns]

It's great to have upgrades to a program with so much devellopment and
involvement going on. I believe it must be quite difficult to renew
the core, with stepping on too many peoples feet.
I admire your effort in making TiddlyWiki fresh and new - and applause
that you have taken the radical step to add a few tweaks and giving
wise priority to what TiddlyWiki can better than any of the
competitors - namely work with the local filesystem...

I'd like some updates to the documentation of adaptions- and uses of
TiddlyWiki though.
When you click some of the links the targets are missing - They
clearly out of date.(or there is something wrong with my
internetconnection...)

Maybe there should be less links to individual testcases in favor of a
very few links to the TWs which are made for and dedicated to
beginners and afficionados:
You know which TWs I refer to - Eric Shulmans Quickstartdocuments,
(should be mentioned here - as they are superbly balanced examples of
CSS+Html and javascript and delivers perfect startingpoints for
everyone who needs a little more than the empty TiddlyWiki - but
hasn't the faintest idea of those things... )
Morris Grays TW-notes and TwT-notes, Dave Giffords NoBrainer-notes -
all very welldocumented and selfdocumenting TWs with their own Help
for beginners and forTheRestOfUs - all Eric Shulmans plugins are very
welldocumented either pr tiddler or with an extra infoTiddler.. Good
reading, which will guide you to get ideas within the boundaries of
the chartered part of TW possibilites...

It's overwhelming for a newcommer to see so much documentation,
presented in a "pure" TW as is the case with TiddlyWiki.com.
Hasn't it grown a lot during the past 3 upgrades?

How much the community actually means for beginners can't really be
described on the mainsite - but links to some of the clarifying
threads (pickup the best from the past) - for example - Tiddly Survey:
http://groups.google.com/group/TiddlyWiki/browse_thread/thread/63c4c9d759a531d8/4eac15cd05fd85c9?hl=en&lnk=gst&q=fun#4eac15cd05fd85c9

I think like this: if TiddlyWikiversions has fairly short
lifecycluses (as I understand much of the devellopment is invisible
for the average user - because of things happening on the
jqueryrewriting of plugins - and replacing javascriptstuff) - why not
also focus on updating the documentation - and the looks of the
documentation on the mainsite (tiddlywiki.com) - either by eliminating
much of the text instead redirect newcommers to the beforementioned
dedicated TWs ? They are all better examples of how to present stuff
(and TiddlyWiki - than the original document)
- or -
you could have two layers of tiddlyWiki.com - One showing the plain
TiddlyWiki - with less info - and as a second TWlayer: a dedicated
beautifully designed "presenterTW" - showing tables with pieces of
info, scripts, plugins, links and usercases in iframes, minibrowsers
or whatever (So the visitor stays on the site for further
investigations in the TWVerse - instead of being directed
elsewhere...)
I hope you understand that I am very thankfull - and admire your
efforts with TiddlyWiki. I use it for almost everything and owe you
much for sharing this thing called TiddlyWiki with everyone - That's
why I'd love to see a facelift (or "face down") on the mainsite - I
think it is a little bloated at the moment.... -

Again Thank you for the good work with TiddlyWiki - The best thing
that has happened to the digital world next to the OpenSource concept
itself and the collaboration around the LinuxCore - and since internet
became publicly accessible.

Thanks..

YS Måns Mårtensson

[Måns]

Oh - I forgot to mention Wolfgangs MenuFlex - Which must be on the
linklist - It's a showcase if any TW's are - on the great
possibilities TiddlyWiki offers - wellpresented and very well
documented!!

> threads (pickup the best from the past) - for example - Tiddly Survey:http://groups.google.com/group/TiddlyWiki/browse_thread/thread/63c4c9...

[Alex Hough]

Great post Måns!

I agree that the links and help should be refresh. Personally I liked
the original TW page before the revamp, which didn't try and teach you
about it while you looked at it. It had charm in that it was written
by Jeremy, the TW creator. I liked that. Jeremy also wrote something
about 'encouraging a new type of writing', while the narrative of the
current page is from a technical perspective.

Come on Jerm, lets have you re-write the page?

Alex
ps I love the way of your English. Its it taking on a TiddlyWiki
syntax? For example "beforementioned" , "welldocumented and
selfdocumenting" , "jqueryrewriting" :

2009/6/24 Måns <huma...@gmail.com>:

--
http://www.multiurl.com/g/64

[wolfgang]

> We've just released TiddlyWiki version 2.5.2 at:
>
> http://www.tiddlywiki.com/

Thanks for the latest release and everything that went into it.

> Oh - I forgot to mention Wolfgangs MenuFlex - Which must be on the
> linklist - It's a showcase if any TW's are - on the great
> possibilities TiddlyWiki offers - wellpresented and very well
> documented!!
>

I'm with your enthusiasm when I'm browsing through MenuFlex's with
FireFox.
But with IE it's completely broken, and could only serve on a link
list for perfectly broken TiddlyWikis :-(.

Of all the experiments to adapt former inventions of Fred, Ocat and
Eric, to a fresh 2.5 TW version - dynamically widening menus,
switching menus and nested popups - neither works with IE in the
least.
Trying to find its reason, I now even broke originals MenuMore's
ability to switch to different tiddlers with a menu switch...

... also I don't think that this approach is really the best, because
by populating the main menus - for showcase reasons - with menus
possible with various plugins - I also realized that the switching
method with display:none/display:block refreshes all these menus all
at once during any edit action, which therefore could make edits very
slow.

What would be really needed, is a doubled tiddler display, where the
left would be used for menu's display..

> It's a showcase if any TW's are ..

though not well documented, maybe this would fit this bill - in size
and themes - the closest:

http://change.tiddlyspot.com/download

kind regards..

[Alex Hough]

Suggestion (not a new one) : a new downloaded TW should have the same
search plugin as tiddlywiki.com

Alex

[Måns]

Translation issue
I'd like to be able to make the neccesary translation for the added
elements - without having to to translate everything once again...
Is it possible to get only those strings that needs to be added to the
existing translation I've made to http://svn.tiddlywiki.org/Trunk/association/locales/core/en/locale.en.js
?
It would be a nice touch :-)
Untill now I have translated the more/less by translating a word or
two in Eric Schulmans CoreTweaks - I miss the option to translate it
in 2.5.2 (more was in the old locale.en.js so it was only 'less' I had
to translate...)

YS MånsMårtensson

On Jun 24, 9:04 pm, Jeremy Ruston <jeremy.rus...@gmail.com> wrote:
> We've just released TiddlyWiki version 2.5.2 at:
>
> http://www.tiddlywiki.com/
>
> (We released a version 2.5.1 yesterday, but found and fixed a problem
> with the upgrade mechanism almost immediately, hence the re-release).
>
> The big change is the start of the process of breaking off some of the
> unique bits of functionality that TiddlyWiki possesses into separate
> jQuery plugins that can be used by other developers in other projects.
> Besides being good to bring things like local file operations to a
> wider audience, part of the benefit will be that the quality of these
> pieces of code
> will improve through wider usage. For this release, we've concentrated
> on TiddlyWiki's cryptographic library, stylesheet manipulation
> functions, and local file system code. There's some documentation here:
>
> http://jquery.tiddlywiki.org/
>
> Besides the pluginification, there's the usual mix of bug fixes and tweaks:
>
> - Improved separators and "more/less" extenders for toolbars
> - Added plugin version information to the PluginManager
> - Fixed Tags macro to respect the excludeLists tag
> - Fixed problem with saving of extended tiddler fields
>

> For the full list of changes seehttp://trac.tiddlywiki.org/wiki/History

[wolfgang]

> If you just want to dynamically load JavaScript files, try the following:
> var filePath = "..."; // relative or absolute URI
> jQuery('<script type="text/javascript">').attr("src", filePath).
> appendTo(document.body);
>

<<tiddler {{
var filePath = "js/TiddlerTweakerPlugin.js"; // relative or absolute

URI
jQuery('<script type="text/javascript">').attr("src", filePath).
appendTo(document.body);

'';}}>><<tiddlerTweaker>>

works perfect!

how would a switch for toggling StyleSheets look like?

regards..

[wolfgang]

> <<tiddler {{
> var filePath = "js/TiddlerTweakerPlugin.js"; // relative or absolute
> URI
> jQuery('<script type="text/javascript">').attr("src", filePath).
> appendTo(document.body);
> '';}}>><<tiddlerTweaker>>
>
> works perfect!
>
> how would a switch for toggling StyleSheets look like?
>

Or would this new jQuery plugin added to the core require again a
plugin like already existing ones?


Somehow I was under the impression that some time ago there quite some
talk about stripping TW to its really essential core, externalizing
what's not really essential to external plugins to choose from. It
appears just the opposite happening now ?

regards

[FND]

> It's great to have upgrades to a program with so much devellopment and
> involvement going on. I believe it must be quite difficult to renew
> the core, with stepping on too many peoples feet.

Indeed it is - but that's just natural.

> I'd like some updates to the documentation [...]

I think we all agree that there remains lots of work to be done on
tiddlywiki.com - but it's nearly impossible to satisfy everyone.

I believe that much of what's been mentioned actually belongs on a site
that is maintained by the community as a whole - i.e. TiddlyWiki.org.
(There are precedents in many other FOSS communities.)
However, there have been very few substantial contributions to the
community site there.
Perhaps that's due to it being a MediaWiki instance, so we might set up
TiddlyWebWiki there at some point in the future if that's desired - but
I don't think that alone would resolve the issue.
Such a discussion is beyond the scope of this thread though.

-- F.

[FND]

> I'd like to be able to make the neccesary translation for the added
> elements - without having to to translate everything once again...
> Is it possible to get only those strings that needs to be added to the
> existing translation

There was supposed to be a diff, but I guess that didn't quite
materialize yet.
Hopefully we can provide this next week - if not, please remind us over
on the developers' list.

-- F.

[Jeremy Ruston]

> Somehow I was under the impression that some time ago there quite some
> talk about stripping TW to its really essential core, externalizing
> what's not really essential to external plugins to choose from. It
> appears just the opposite happening now ?

I think you're describing a sort of microkernel pattern, where the
goal is to move as much as possible into plugins so as to make it
easier to keep things trim by omitting sections of the code. Although
this has been discussed quite a lot on the list, it's pretty tough to
do with a mature code base like TiddlyWiki.

What we're actually doing is therefore to focus on modularising just
those bits of code that are generic enough to be used elsewhere. It's
less about enabling people to trim the core down to a minimum, and
more about improving the quality of TiddlyWiki's code through more
people using it.

[wolfgang]

> Perhaps that's due to it being a MediaWiki instance, so we might set up
> TiddlyWebWiki there at some point in the future if that's desired - but
> I don't think that alone would resolve the issue.

Great Idea, Fred. I tried only once to register and contribute to a
media wiki, which was tiddlywiki.org. Since this failed I never tried
it again.

> > talk about stripping TW to its really essential core, externalizing
> > what's not really essential to external plugins to choose from. It
> > appears just the opposite happening now ?
>

> goal is to move as much as possible into plugins so as to make it
> easier to keep things trim by omitting sections of the code. Although
> this has been discussed quite a lot on the list, it's pretty tough to
> do with a mature code base like TiddlyWiki.
>

Thanks for the answer Jeremy. Must have been absent when this policy
change happened. Though I do remember the difficulties when the first
tiny bits where removed. Making the DeprecatedFunctionsPlugin
necessary for many plugins which hadn't been maintained since, and
thereby sort of nullifying these efforts again:
http://www.tiddlywiki.com/coreplugins.html#DeprecatedFunctionsPlugin

> What we're actually doing is therefore to focus on modularising just
> those bits of code that are generic enough to be used elsewhere. It's
> less about enabling people to trim the core down to a minimum, and
> more about improving the quality of TiddlyWiki's code through more
> people using it.
>

Does 'modularizing' mean taking bits out of original core and
implementing these - like jQuery.twFile, jQuery.twStylesheet and
jQuery.encoding.digests.sha1.html - as separate modules?

Or could 'elsewhere' mean this new approach is actually //adding//
plugins - not via a systemConfig tag, but by adding them to the core -
and making the TiddlyWiki core to sort of a code repository to use
with htmls other than TiddlyWikis?

If this would be the case - which is hard for me to believe - than
TiddlyWiki very soon might shoot up the 1/2 - 1 MB marks, and making
this ever lean again even less possible!

1.0.0 Sep 20, 2004 50 KB
2.0.0 Jan 5, 2006 145 KB
2.5.2 June 24, 2009 346 KB
3.0.0 June 2012 ???? KB

Though I might have misunderstood you here: Wouldn't it make much more
sense to allow everyone decide - if one wants to be one of those 'more
people' (with which the quality might or might not improve) - by
distributing them using a systemConfig tag as it is done with every
other plugin?

Regards..

[Jeremy Ruston]

> Great Idea, Fred. I tried only once to register and contribute to a
> media wiki, which was tiddlywiki.org. Since this failed I never tried
> it again.

I think we're all a bit sad about the barriers to contribution on the
mediawiki instance at tiddlywiki.org. And the dissonance between
mediawiki and tiddlywiki is awkward.

>> > talk about stripping TW to its really essential core, externalizing
>> > what's not really essential to external plugins to choose from. It
>> > appears just the opposite happening now ?

As I say, there's been a lot of discussion over the years about the
microkernel approach, I think it has a rather elemental appeal as a
concept. But I don't think we've ever committed to that approach;
personally, I've never been able to resolve some of the conflicts
between the microkernel approach and the existing implementation. My
own conclusion is that modularising the core isn't worth it, if the
only goal is to enable individuals to omit parts of it. There's a
tradeoff between having a stable core that's common to all
implementations versus making it easier for a few well informed
individuals being able to slice 20% off the core code size.

> Thanks for the answer Jeremy. Must have been absent when this policy
> change happened.

I don't think there's been a policy change, or it doesn't feel like that to me.

> Though I do remember the difficulties when the first
> tiny bits where removed. Making the DeprecatedFunctionsPlugin
> necessary for many plugins which hadn't been maintained since, and
> thereby sort of nullifying these efforts again:
> http://www.tiddlywiki.com/coreplugins.html#DeprecatedFunctionsPlugin

I think this is a different issue, but perhaps they're more related
than I perceive.

Moving the deprecated functions into their own plugin was a bit of
housekeeping to try to clarify the core API by clearly marking
interfaces that are really only there for backwards compatibility.

>> What we're actually doing is therefore to focus on modularising just
>> those bits of code that are generic enough to be used elsewhere. It's
>> less about enabling people to trim the core down to a minimum, and
>> more about improving the quality of TiddlyWiki's code through more
>> people using it.
>>
>
> Does 'modularizing' mean taking bits out of original core and
> implementing these - like jQuery.twFile, jQuery.twStylesheet and
> jQuery.encoding.digests.sha1.html - as separate modules?

Yes, we've been refactoring these modules so that they are practical
to use outside of the TiddlyWiki core code.

> Or could 'elsewhere' mean this new approach is actually //adding//
> plugins - not via a systemConfig tag, but by adding them to the core -
> and making the TiddlyWiki core to sort of a code repository to use
> with htmls other than TiddlyWikis?

I'm not sure if I understand the question. There are certainly now two
types of plugins in the tiddlywiki universe: jQuery plugins which are
used to encapsulate extensions/enhancements to the JavaScript/HTML/CSS
platform, and TiddlyWiki plugins which are used to extend TiddlyWiki
itself.

It sounds complicated to have two different types of plugin, but they
are exposed to completely different people. TiddlyWiki users use
TiddlyWiki plugins to extend the platform; jQuery developers may use
the TiddlyWiki jQuery plugins to add TiddlyWiki features to other HTML
applications.

> If this would be the case - which is hard for me to believe - than
> TiddlyWiki very soon might shoot up the 1/2 - 1 MB marks, and making
> this ever lean again even less possible!
>
> 1.0.0   Sep 20, 2004    50 KB
> 2.0.0   Jan 5, 2006     145 KB
> 2.5.2   June 24, 2009   346 KB
> 3.0.0   June 2012       ???? KB

Yes, TiddlyWiki has got bigger - alongside processors and RAM etc.
I've always felt the kilobyte count was a bit misleading; it affects
the time to transfer the bytes of TiddlyWiki to a browser. But it
turns out in most situations it's actually the execution speed of the
code that's the issue, not the loading time.

> Though I might have misunderstood you here: Wouldn't it make much more
> sense to allow everyone decide - if one wants to be one of those 'more
> people' (with which the quality might or might not improve) - by
> distributing them using a systemConfig tag as it is done with every
> other plugin?

The intention is to enable people who are developing non-TiddlyWiki
solutions to be able to use these bits of the TiddlyWiki core code.
For example, just recently we've had this:

http://www.simple-kanban.com/

It's a cool little single-html-page-application. The author expressed
a desire to add TiddlyWiki's save routines, but found that it's hard
to extract the code and use it independently. It's desirable for that
saving code to be more widely used because the more people who are
using a bit of code, the more reliable and useful it becomes.

So, making, say, the saving code be a systemConfig plugin really
wouldn't help that situation..

Best wishes

Jeremy

>
> Regards..

[wolfgang]

Thanks for your detailed perspective.

> >> > talk about stripping TW to its really essential core, externalizing
> >> > what's not really essential to external plugins to choose from. It
> >> > appears just the opposite happening now ?
>
> As I say, there's been a lot of discussion over the years about the
> microkernel approach, I think it has a rather elemental appeal as a

> concept. ...
> ...

> I don't think there's been a policy change, or it doesn't feel like that to me.
>

So I must have been mislead to think so by these discussions and such
stripping of non-essential functionality out of the core and into
plugins with Version 2.3.

> > Or could 'elsewhere' mean this new approach is actually //adding//
> > plugins - not via a systemConfig tag, but by adding them to the core -
> > and making the TiddlyWiki core to sort of a code repository to use
> > with htmls other than TiddlyWikis?
>

> I'm not sure if I understand the question. ...
> ...

> It sounds complicated to have two different types of plugin, but they
> are exposed to completely different people. TiddlyWiki users use
> TiddlyWiki plugins to extend the platform; jQuery developers may use
> the TiddlyWiki jQuery plugins to add TiddlyWiki features to other HTML
> applications.

> ...

> So, making, say, the saving code be a systemConfig plugin really
> wouldn't help that situation..

My differentiation lies exactly in modularizing AND replacing existing
essential functionality - like the saving code - which I think is a
very good idea. And on the other side DOUBLING functionality, which
for no uses or plugins are existing yet - as this seems the case with
jQuery.twStylesheet, because there are already existing TW ways to
toggle css.

For such a later case I would wish this would be introduced as a
systemConfig plugin, so I would only have to upgrade to, if this would
work in any way 'better' - as in this example - to SwitchThemePlugin
by Eric, or SelectThemePlugin by Simon.

But now it's to late anyway, as I just realized by trying to stripe
2.5.2 of jQuery unsuccessfully: If I want to use TreeviewPlugin I can
upgrate to TW 2.5.2 - for all remaining uses I'm free to downgrade :-)

> Yes, TiddlyWiki has got bigger - alongside processors and RAM etc.
> I've always felt the kilobyte count was a bit misleading; it affects
> the time to transfer the bytes of TiddlyWiki to a browser. But it
> turns out in most situations it's actually the execution speed of the
> code that's the issue, not the loading time.
>

I agree with you on text bytes and when execution speed is improved
with some more js - but certainly not when it comes to additional
unnecessary javascript kilo bytes invoked at startup.

Though processors and RAM became bigger every year, I hope you don't
expect me to buy the latest computer every two years (gosh, just now I
would have to get out and get a new one! Despite the notebook I've got
working perfectly all right, with the same battery still running for 6
hrs). And what's with the majority of the world population which
haven't even got an Internet connection at home, but available
Internet cafes with terrible speed at high costs? That will always be
the most frequent situation. (And unsustainable consumerism what
caused the mess paper money is in now, with much worse still to
follow.. or should I say much better? ..when it therefore might come
to a full stop in a few decades?)

Please don't take my differing opinion - by trying to look at it from
a bigger perspective - the wrong way, I greatly appreciate the
innovations which were possible by being sponsored by BT. And just as
likely could be proven wrong - which in this case I only hope for.
However, this just has a little bid the flavor of going the corporate
way, for me at this moment.

Just some food thought not only for the left side of the brain...

kind regards..

[FND]

> there's been a lot of discussion over the years about the
> microkernel approach

Just to clarify: I don't think it was realistic to expect that end-users
would have to cook their own TiddlyWiki from various modules
While there might be some minor components that might be externalized,
the standard TiddlyWiki distribution should be a stable platform common
to all regular users.
Someone who wants a more customized version of TiddlyWiki can do so by
using Cook to assemble a version tailored to their needs. (Doing so is
likely to result in incompatibilities with certain plugins.)

> on the other side DOUBLING functionality, which for no uses or plugins
> are existing yet - as this seems the case with jQuery.twStylesheet,
> because there are already existing TW ways to toggle css.

I think this is the basic misunderstanding. There is no doubling of
functionality here.
The code that makes StyleSheet et al. work is essentially still the
same. It's only been refactored[1] (rearranged internally) to be a more
distinct module - in this case a reusable jQuery plugin - which
TiddlyWiki itself makes use of.

> Please don't take my differing opinion - by trying to look at it from
> a bigger perspective - the wrong way

Your thoughts are appreciated, as they highlight the need to more
clearly communicate changes - even though it's not always easy to
explain the significance of certain technical decisions.

> this just has a little bid the flavor of going the corporate way

Believe me, none of the core developers are "enterprisey" in the least,
and there is no pressure from BT to change that.

It's also worth pointing out here that the relation between Osmosoft and
the core-development team is mostly coincidental - it's primarily that
way because no outside developer has stepped up to become a regular core
contributor.
TiddlyWiki is neither owned nor controlled by BT/Osmosoft; it is still a
community project.[2] My own involvement, for example, is driven pretty
much entirely by personal motives rather than some corporate or
financial interest (seeing as I'm writing this very message on a Sunday
morning).
Yet (paraphrasing Chris[3]) there seems to be a perpetuating notion that
Osmosoft is solely responsible for development, documentation,
communication etc. - that I believe to be wrong and unfair.

As previously mentioned, I believe these discussions are beyond the
scope of this particular thread.

-- F.

[1] http://en.wikipedia.org/wiki/Code_refactoring
[2] http://tiddlywiki.org/wiki/UnaMesa
[3] http://groups.google.com/group/TiddlyWikiDev/msg/68c66fe468f8c29b

[Saq Imtiaz]

> It's also worth pointing out here that the relation between Osmosoft and
> the core-development team is mostly coincidental - it's primarily that
> way because no outside developer has stepped up to become a regular core
> contributor.

Correction. From where I'm standing no outside developer has been
afforded the opportunity to become a regular core contributor. This
was a major factor in my decision to scale back time spent on
TiddlyWiki development. Where coincidental or not it is my sincere
belief that it is impossible to contribute to the TiddlyWiki core code
in any meaningful - other than forking the code - for anyone not
working at Osmosoft. I don't for a minute believe that there are any
sinister intentions behind this and it has been an unfortunate by-
product of the fact that Jeremy and Martin both work at Osmosoft..
it's just easier to discuss and develop with those you're in the same
room with. Sadly it means the rest of us don't get an opportunity to
weigh in and contribute. This isn't really meant as criticism, the
community has benefited greatly from the contributions Osmosoft has
made and this is just the flip side of the coin. However I do take
exception to the statement that no one else has "stepped" up.

> Yet (paraphrasing Chris[3]) there seems to be a perpetuating notion that
> Osmosoft is solely responsible for development, documentation,
> communication etc. - that I believe to be wrong and unfair

Solely responsible, definitely not. But fact is that Osmosoft has
restricted discussion on design and development to the Osmosoft circle
and has for the most part failed to share that with the rest of us in
an inclusive manner. In doing so they HAVE assumed a great deal of
responsibility. I don't think it is a coincidence that since the BT
acquisition of Osmosoft, quite a few previously very active TW
developers have gradually made themselves scarce, myself included. The
real danger in this scenario is that if Osmosoft were to decide to
divert focus from TW, it might create a void which otherwise would
have been filled by outside developers as part of the evolution of the
community.... but this might be better continued as a blog post about
the impact of a corporate entity like BT getting involved with an open-
source project.

Once again, I appreciate everything that Osmosoft brings to the
community and the TiddlyWiki ecosphere. While it has resulted in a
change in the way the community operates and has come with its share
of disadvantages, I'd probably wager that we're better off at this
point in time than we would have been without BT/Osmosoft.

Just my two cents worth as someone who I think has earnt the right to
have an opinion on all things TiddlyWiki. ;)
Cheers,
Saq

[wolfgang]

>
> Just my two cents worth as someone who I think has earnt the right to
> have an opinion on all things TiddlyWiki. ;)
>

Not that I would have earned myself any right to have an
opinion... ;-)

> Where coincidental or not it is my sincere
> belief that it is impossible to contribute to the TiddlyWiki core code
> in any meaningful - other than forking the code - for anyone not
> working at Osmosoft.

> ...

> The
> real danger in this scenario is that if Osmosoft were to decide to
> divert focus from TW, it might create a void which otherwise would
> have been filled by outside developers as part of the evolution of the
> community...
>

That's my main concern. TW version 2.5 can already be considered as a
fork, since in this thread it has clearly explained, that a standard
TiddlyWiki now serves 2 purposes, for TW users and developers - as it
has been until recently - but also as a code repository for external
jQuery plugin developers - which is really unique.

The focus has already changed from TW, as now initially and
necessarily much more efforts has to be given for advancing this new
kind of jquery plugins, for which only few or no purposes are
available yet - or already existing the TW way, plus ironing bugs
which such a refactoring might bring. This is such a great task...

.. I slowly start to see the need for a user only oriented fork again
- at least for the next 2-3 years.

This can't be a one man task. Nevertheless, how about starting a TW
fork where jQuerry can be included via MarkupPreHead, as it has always
been the case, but doesn't has to? While including recent bugfixes and
attracting outside developers again, to contribute and being part of a
TiddlyWikis evolution without dependency to jQuery.

What does everyone think?

> Please let us have any comments here, ...

>
> Your thoughts are appreciated, as they highlight the need to more
> clearly communicate changes - even though it's not always easy to
> explain the significance of certain technical decisions.
>

> As previously mentioned, I believe these discussions are beyond the
> scope of this particular thread.
>

> .... but this might be better continued as a blog post about
> the impact of a corporate entity like BT getting involved with an open-
> source project.
>

Clear communication has to occur whenever or wherever bluredness
happens to be perceived. Otherwise it isn't really out in the open
anymore ..therefore, lets discuss it here and now with everyone
invited to participate - with as much mutual respect and contrarily as
possible.

:-)

[Jeremy Ruston]

> That's my main concern. TW version 2.5 can already be considered as a
> fork, since in this thread it has clearly explained, that a standard
> TiddlyWiki now serves 2 purposes, for TW users and developers - as it
> has been until recently - but also as a code repository for external
> jQuery plugin developers - which is really unique.

I'm not sure what you mean by the the "code repository for external
jQuery plugin developers".

To be clear, there have been three changes associated with jQuery:

- the inclusion of the jQuery library by default; this is the decision
that you go on to critique. There was a fair amount of discussion
before we did this; the goal was to enable TiddlyWiki to benefit from
the much higher quality browser compatibility layer in jQuery

- the refactoring of some internal TiddlyWiki functions to use jQuery
functionality where it improves performance or code size

- the refactoring of some internal TiddlyWiki functions so that they
can more easily be reused. This is something that's happened since the
beginning of TiddlyWiki; other open source developers plucking out the
unique bits of functionality in TiddlyWiki for their own projects. All
we've done is rearrange the code to make that easier. It sounds like
one of your concerns is that making this functionality into a jQuery
plugin is akin to bloat, which isn't really the case.

> The focus has already changed from TW, as now initially and
> necessarily much more efforts has to be given for advancing this new
> kind of jquery plugins, for which only few or no purposes are
> available yet - or already existing the TW way, plus ironing bugs
> which such a refactoring might bring. This is such a great task...

I'm not sure what you mean here.

> .. I slowly start to see the need for a user only oriented fork again
> - at least for the next 2-3 years.

I need to understand more about why you think this would be desirable,
and how it would differ from the TiddlyWiki we've got today.

> This can't be a one man task. Nevertheless, how about starting a TW
> fork where jQuerry can be included via MarkupPreHead, as it has always
> been the case, but doesn't has to? While including recent bugfixes and
> attracting outside developers again, to contribute and being part of a
> TiddlyWikis evolution without dependency to jQuery.
>
> What does everyone think?

I'd like to understand more why you think that the integration of
jQuery may be such a big problem. Is it primarily the issue of code
size?

> Clear communication has to occur whenever or wherever bluredness
> happens to be perceived. Otherwise it isn't really out in the open
> anymore ..therefore, lets discuss it here and now with everyone
> invited to participate - with as much mutual respect and contrarily as
> possible.

If people are interested, we could set up another conference call for
a discussion as well,

Best wishes

Jeremy

[wolfgang]

Sorry to everyone with a short attention span for this long post. One
could also proceed to the last paragraph, to get the gist.

> To be clear, there have been three changes associated with jQuery:
>
> - the inclusion of the jQuery library by default; this is the decision
> that you go on to critique. There was a fair amount of discussion
> before we did this; the goal was to enable TiddlyWiki to benefit from
> the much higher quality browser compatibility layer in jQuery

I read parts of them and I'm very well aware that everyone has put
serious consideration before implementing such a big change to the end
of bettering TiddlyWiki. You shouldn't misunderstand my posts, that I
wouldn't want this to happen. On the contrary, I'm still of the
opinion you should go forward with this, and I appreciate you do.

Also my arguments for a fork without jQuerry aren't anything you
haven't heard already and therefore haven't considered before, nor
could I give better ones as those already given by technically more
versed contributors before. I just digested all these different
perspectives (for example:
http://groups.google.co.uk/group/TiddlyWikiDev/browse_thread/thread/c7d270d638383b92#
), multiplied it with the uncertainty factor in life, and salted it
with Saq's perspective. And this is what came out of my pondering...

I think everyone agrees with the direction of development taken, the
advantages of doing so are far too obvious, theoretically.

But considering the limited manpower at Osmosoft, these advantages to
TW users might become obvious in a few months - or a few years - or,
with other uncertainties already talked about, it might make this
advantages more obvious to jQuery developers and less obvious to TW
users - in the end.

That's fine with me this way, and I take the possible risk of never
seeing any real advantages.

Then I thought - for the many reasons already pondered by others -
well, after all it isn't such a big deal, to copy and paste bug fixes
into version 2.4.3 and once more get developers on board for a healthy
competition, for those who may feel there aren't any opportunities
otherwise:

>
> working at Osmosoft. I don't for a minute believe that there are any
> sinister intentions behind this and it has been an unfortunate by-
> product of the fact that Jeremy and Martin both work at Osmosoft..
> it's just easier to discuss and develop with those you're in the same
> room with. Sadly it means the rest of us don't get an opportunity to

> weigh in and contribute. This isn't really meant as criticism, the ..
>

And once this uncertainty - that there might or might not come
betterments to TW end users - has been decided, also the jQuery TW
could only profit from it again (without having to take the
responsibility to look also for such a kind of legacy TW, beside all
the other perceived responsibilities: documentation, tiddly web,
cctiddly, cecily, ripple rap, tiddly hub, jquery ...).

From developers, who otherwise may hold back their involvements,
because they are simply not sitting in the same room and may wrongly
think their forks - if indeed bringing improvements - wouldn't be
received well by the community. (if nothing else, these discussions
show that there is a real demand for a simple stable TW without an
incorporated jQuerry, which at this point is still lacking any
perceivable advantage)

>
> I'm not sure what you mean by the the "code repository for external
> jQuery plugin developers".
>

I mean if an end user needs a piece of functionality he can go to a
systemServer, take a tiddler and tag it systemConfig without having to
import anything else from this repository.

If a jQuerry developer needs a piece of functionality he can come to
any TiddlyWiki and use a piece of code - but without the end user
having ever decided to distribute code he is ignorant of, nor would
know how to use for his own advantage, but costing bandwidth.

Sure, also before this was possible with essential functions of
TiddlyWiki. But jQuery TW plugins are dependent on jQuery library. And
jQuery library dependency wouldn't be necessary for still some time.

>
> we've done is rearrange the code to make that easier. It sounds like
> one of your concerns is that making this functionality into a jQuery
> plugin is akin to bloat, which isn't really the case.
>

At the moment and till above will be decided - in months or years -
jQuery library is the bloat. If I upgrade to it without receiving any
perceivable advantages yet.

>
> I'd like to understand more why you think that the integration of
> jQuery may be such a big problem. Is it primarily the issue of code
> size?
>

Primarily it is the added size without any perceivable improvement.

But I'm aware that this is difficult to understand as a big problem,
if you haven't lived for a while in a developing country. However, you
don't have too! You can't be responsible for everything - should other
developers step up and do it on their own, and for very good reasons
independently.

Further, the difficulty of former attempts to create a micro kernel.
Since this seems to have failed due to the interdependence in the core
- why make it now dependent to anything more and that big as the
jquery library? - Where to make - or should I say: leave - this ever
lean might never become possible again.

TW is to communicate, and does this very well and easy to use for
newbies via the Internet. I'm aware many developers here would never
use it for a website, but this disregard shouldn't lead to the
sentiment - because it isn't reasonable for this purpose in their view
- TW's size is the least issue to consider.

> > The focus has already changed from TW, as now initially and
> > necessarily much more efforts has to be given for advancing this new
> > kind of jquery plugins, for which only few or no purposes are
> > available yet - or already existing the TW way, plus ironing bugs
> > which such a refactoring might bring. This is such a great task...
>
> I'm not sure what you mean here.
>

Now you're busy with modularizing - converting bits of TW code into
jQuery plugins. Consequently done, how long do you reckon this will
take? ...That long no real improvement might become perceivable I
believe. Conservatively, I guess this will take years.

(I'll change my opinion, for example, as soon the new jQuery way of
making a saveChanges seriously cuts down the time it takes to save a
big TW :-)

> > .. I slowly start to see the need for a user only oriented fork again
> > - at least for the next 2-3 years.
>
> I need to understand more about why you think this would be desirable,
> and how it would differ from the TiddlyWiki we've got today.

Better ask: For an user, does the TiddlyWiki today differ from the one
yesterday? Again, there might or might not be any advantages to TW end
users at any point in the future. But that long the question remains -
why increase bandwidth? There are too many who don't have fast
Internet. That doesn't concerns most of us here. But it nevertheless
does make it an exclusive thing for the penniless, the majority on
this planet.

> > there's been a lot of discussion over the years about the
> > microkernel approach
>
> Just to clarify: I don't think it was realistic to expect that end-users
> would have to cook their own TiddlyWiki from various modules
> While there might be some minor components that might be externalized,
> the standard TiddlyWiki distribution should be a stable platform common
> to all regular users.

It is one thing to realize that the TW kernel is too interwoven for
any serious modularization for end users. It is the complete opposite
approach then to proceed and create such a heavy dependency as to the
56 bytes weighting compressed jQuery library.

>
> Someone who wants a more customized version of TiddlyWiki can do so by
> using Cook to assemble a version tailored to their needs. (Doing so is
> likely to result in incompatibilities with certain plugins.)
>

I would say TW without jQuerry was very stable and not less complete.
So - in an ideal world - it should have been the other way around in
my opinion. jQuerry library could have been added with a systemConfig
tag by those who need it, for example for TreeviewPlugin.

>
> > What does everyone think?
>

But we are not living in an ideal world and the Osmosoft team is
clearly overextended, it hasn't been able to set up anything better
for end users documentation and communication than this mailing list
since many years. Now to expect it would have the resources to leave
the existing stable core independent, and optional to include
additional jQuerry functionality - as long as this doesn't bring any
serious advantages - is just too much to expect, I think.

Therefore, though I appreciate your questioning Jeremy, I believe now
it is the time for those developers, who may think they haven't got
any opportunity to make contribution to the core. There is definitely
a demand.

>
> If people are interested, we could set up another conference call for
> a discussion as well,
>

Thanks for your efforts to create consent. But if there is passion for
a slim, stable legacy TiddlyWiki - where jQuery remains optional -
developer will step up and your team can concentrate on your task
without becoming unnecessarily diverted. I agree with Saq, that if the
core remains perceived the sole responsibility of Osmosoft, this very
fast could lead to a dangerous situation.. There is no company too big
to fail.

Best wishes to everyone...

[Morris Gray]

On Jul 8, 8:34 am, wolfgang <wolfgangl...@gmail.com> wrote:

> Thanks for your efforts to create consent. But if there is passion for
> a slim, stable legacy TiddlyWiki - where jQuery remains optional -
> developer will step up and your team can concentrate on your task
> without becoming unnecessarily diverted. I agree with Saq, that if the
> core remains perceived the sole responsibility of Osmosoft, this very
> fast could lead to a dangerous situation..

I swore I would comment no more on this subject on the Developers
group. When it comes to this subject it is like talking into the
wind. So before I go back to trying to make practical applications
for TiddlyWiki I'll just say this.

I'm not sure if there are enough worldly wise people here to see the
unraveling of a cohesive group taking place. An unraveling that can
easily slide into a lowering of moral and dampening enthusiasm for
both users and developers.

The seeds to this potential unraveling were sown when the decision was
made to drastically change the TiddlyWiki core and subject all users
to the vagueness of unfinished software on a regular basis for months
or years.

For the core developers it can be demoralizing because they will feel
unappreciated. The fear of bringing an avalanche of criticism with
each bug, not to mention breaking favourite plugins, will slow
development and quell enthusiasm for them.

Users who long for a stable platform to get real-world applications
done will balk at every disruption to their progress and the extra
uncertainty and distracting discussions that follow.

The hard-headed unwavering decision to ignore having a continuing
stable platform while continuing with a drastic revamp of the core
without having defined separate branches is dangerous. It will create
a de facto set of branches anyhow but more importantly it will put
users and developers into two separate camps.

The argument that users need not follow the the upgrades is a weak one
indeed for it actually fosters those de facto branches mentioned
above. What choice does that leave users, to go out on a limb that
that has been sawed off behind them, or follow the uncertain path
development that doesn't really know where it's going.

The natural flow of TiddlyWiki being improved and tweaked with each
new release will be broken by changing fundamental core functions and
if continued will created a separate branch whether you admit it or
not. How can any application developer feel their product is reliable
enough to be released to the world knowing that the next time their
user upgrades the core something might break.

The changes to the core using jQuery is a good one, holding great
promise. If it is continued as a separate development it will cause
no disruption. People will be eager to follow its progress and help
with the testing and will be drawn to it through curiosity, and
concern they may be left behind, instead of considering it a threat.

Whatever extra work separate branches create, whatever extra time it
takes is worth it because the real or imagined uncertainties of not
doing so will slow its progress even more, or worse divide and lose
both developers and users along the way.

If I was 'in the same room' as you I would emphatically say this - for
it will cost you nothing and you will gain much

Take the 2.5.x development out of the backstage upgrade path to foster
certainty for users.

Continue the jQuery core development with enthusiasm and vigor. Make
regular announcements in both groups of new releases.

But with one addition. Take the time to also develop little
applications as demonstration models for people to try and see some of
the advantages.

This will give you the testers you need, force you to actually test
and document some of the new additions you've made as you go and give
people ideas of how they can be used. Then when the time comes to make
the switch there will already be enthusiastic users and developers,
already knowledgeable and comfortable, to take advantage of it.

The time to put version 2.5.x into the backstage upgrade path will
occur naturally, you will know with certainty when it is the right
time, you will have loyal followers and it may actually be demanded by
popular acclaim.

That's how separate development paths can actually draw people
together instead of one that would divide them.

Morris Gray

On Jul 8, 8:34 am, wolfgang <wolfgangl...@gmail.com> wrote:
> Sorry to everyone with a short attention span for this long post. One
> could also proceed to the last paragraph, to get the gist.
>
> > To be clear, there have been three changes associated with jQuery:
>
> > - the inclusion of the jQuery library by default; this is the decision
> > that you go on to critique. There was a fair amount of discussion
> > before we did this; the goal was to enable TiddlyWiki to benefit from
> > the much higher quality browser compatibility layer in jQuery
>
> I read parts of them and I'm very well aware that everyone has put
> serious consideration before implementing such a big change to the end
> of bettering TiddlyWiki. You shouldn't misunderstand my posts, that I
> wouldn't want this to happen. On the contrary, I'm still of the
> opinion you should go forward with this, and I appreciate you do.
>
> Also my arguments for a fork without jQuerry aren't anything you
> haven't heard already and therefore haven't considered before, nor
> could I give better ones as those already given by technically more
> versed contributors before. I just digested all these different

> perspectives (for example:http://groups.google.co.uk/group/TiddlyWikiDev/browse_thread/thread/c...

[Alex Hough]

+1 for this:
"[...]little applications as demonstration models for people to try

and see some of the advantages.

2009/7/8 Morris Gray <msg...@symbex.net.au>:

--
http://www.multiurl.com/g/64

[mauve]

+1
I utterly agree with Morris Gray's wise words !

[Eric Weir]

On Jul 7, 2009, at 10:39 PM, Morris Gray wrote:

> I'm not sure if there are enough worldly wise people here to see the
> unraveling of a cohesive group taking place. An unraveling that can
> easily slide into a lowering of moral and dampening enthusiasm for
> both users and developers.

Probably shouldn't be speaking up here. I'm literally just a user.
Nevertheless, this concerns me. Some pretty important TiddlyWiki folks
have spoken up. I hope they will be listened to.

> Take the 2.5.x development out of the backstage upgrade path to foster

> certainty for users....

The wisdom of this and everything following it in Morris' post is
transparent -- at least to me, who should not count for much, but
altogether in the end we count for a lot.

I would add one other thing that I think someone -- Wolfgang? -- who
has more right to speak up than me -- the lack of documentation. The
fact that an application like TiddlyWiki should have been around so
long without systematic documentation of features, components,
guidance regarding customization, etc., etc., is a bit on the
ridiculous side. E.g., What exactly does a StyleSheet control? How's
it related to PageTemplate? And on and on and on.

I'm far from being one of the more intensive users, especially when it
comes to customization. My needs are simple and easily met with
existing capabilities. But I've been here a couple years, and the fact
that whenever I want to do almost anything I have ask people to help
me, that there is no reference I can go to to get a sense of how to
start is, again, well, ridiculous.

Regards,
------------------------------------------------------------------------------------------
Eric Weir
Decatur, GA USA
eew...@bellsouth.net

[wolfgang]

> I would add one other thing that I think someone -- Wolfgang? -- who
> has more right to speak up than me -- the lack of documentation. The
> fact that an application like TiddlyWiki should have been around so
> long without systematic documentation of features, components,
> guidance regarding customization, etc., etc., is a bit on the
> ridiculous side. E.g., What exactly does a StyleSheet control? How's
> it related to PageTemplate? And on and on and on.
>

I think this assessment isn't fair Eric. After all, TiddlyWiki is an
OpenSource project with manpower too limited - considering the number
of projects all going at the same time. And one has to wonder, how
beside all these tasks, there was still some time left for actually
advancing the core. Open source projects stands or fall with the
contributions of a community. And this need has been met with help
TiddlyWikis of various individuals, and the unheard of help shoveled
on us here at GG:

TiddlerToddler
http://tiddlertoddler.tiddlyspot.com/
TiddlyWiki Tips
http://tiddlywikitips.com/
TiddlyWiki Tutorial - the basics
http://www.blogjones.com/TiddlyWikiTutorial.html
TiddlyWiki for the rest of us
http://www.giffmex.org/twfortherestofus.html
TiddlyWiki Help - a comprehensive guide
http://twhelp.tiddlyspot.com/
Questions and Answers on TiddlyWiki
http://twfaq.tiddlyspot.com/
Tiddly faqs
http://www.tiddlytools.com/faq.html
TiddlyWiki.org Wiki
http://tiddlywiki.org/wiki/Main_Page


Looking at it from a different angle, maybe other forces might be at
work we are not even be aware of, as the core developers close to
Osmosoft are.

Just made a quick survey of the last systemConfig update of all major
systemServers:

7 July 2009
http://www.tiddlytools.com/

3 June 2009
http://mptw.tiddlyspot.com/

14 April 2009
http://tiddlywiki.abego-software.de/

6 Maio 2009
http://www.math.ist.utl.pt/~psoares/addons.html

12 January 2009
http://ptw.sourceforge.net/ptwe.html

30 September 2008
http://tiddlywiki.bidix.info/

2 July 2008
http://jackparke.googlepages.com/jtw.html

5 April 2008
http://tw.lewcid.org/

18 January 2008
http://visualtw.ouvaton.org/VisualTW.html

26 January 2007
http://bradleymeck.tiddlyspot.com/

23 January 2007
http://tiddlystyles.com/

26 December 2006
http://solo.dc3.com/tw/

down at the moment:
http://www.martinswiki.com/


But these dates still don't reveal the sad truth that the only one
which still came forwards with innovations during the last year is
only TiddlyTools!

>
> The seeds to this potential unraveling were sown when the decision was
> made to drastically change the TiddlyWiki core and subject all users
> to the vagueness of unfinished software on a regular basis for months
> or years.
>

Sure, all working at Osmosoft must be aware of this drainage of
contributing developers. And this blunt inclusion of jQuery library
into the core might only be a desperate attempt to avert a black hole,
without wanting to this communicate for good reasons?

best wishes..

[Jeremy Ruston]

Thanks to everyone for joining the discussion. It's wonderful to hear
people being passionate about TiddlyWiki, and caring about its future.
The frustration is also clear, but, being an optimistic sort of
person, I can't help but think that we can figure out a way forward
that meets the needs of everyone.

It feels as though a common thread is a gap between users and
developers, and perhaps more particularly the developers that work for
Osmosoft. There's been a lack of communication, and I do rather feel
responsible for it.

When TiddlyWiki started I was one of the most frequent posters to the
groups. It didn't take long for Eric and others to overtake me in
posting frequency, but I was still very much present. After joining BT
and building up Osmosoft into a proper team, I inevitably had far less
time to spend in the groups. It wasn't entirely unexpected that that
would happen, and I hoped that it would be a fair exchange for being
able to hire people to work on TiddlyWiki-related things.

There's a lot more to say, but it's late, and possibly best said in
another thread anyway. I wanted to acknowledge that I'm reading all
this, and thinking about it deeply. I'll try to post some more
coherent thoughts in a day or two, and thanks for bearing with the
discussion.

Best wishes

Jeremy

[Eric Weir]

On Jul 9, 2009, at 6:25 AM, wolfgang wrote:

> I think this assessment isn't fair Eric.

I was aware of the respects in which my comment about documentation
was inadequate -- should I say, "inaccurate"? -- Wolfgang. Of course,
I'm aware, too, that it is an open source project.

There is a lot of documentation, a great deal of it actually. Another
manifestation of the generosity of the TiddlyWiki community. But when
you're at work and run into a problem, it's not always easy to know
where to go looking -- to what site, or in what location at that site.
It would be handy to have a manual, a compilation of components,
commands, tweaks, applications, FAQs, solutions to common problems.
Something with a table of contents and index. Not not necessarily
polished and edited for publication. Almost certainly everything
anyone would want to know has already been written up somewhere. If it
were organized and made more accessible, it would probably more than
suffice.

Another example. And again, I've been around at least a couple years.
I know vaguely that TiddlyWiki has standard "fields." Maybe some -- or
all? -- are associated with tiddlers. Looking at a TiddlyWiki, using a
TiddlyWiki, you'd never know it. I still don't know what they are or
what they're for. Maybe as a naive user who'll never gravitate to
developer, I don't need to know. Or, maybe it would be really helpful.
It would be nice to have a book I could pore over and learn about
things like that. Develop some sense of what kind of animal this
TiddlyWiki is. What it's made of. How it works.

As for being open source, TiddlyWiki is not exactly a struggling open
source project. In spite of the concerns that have been expressed on
this thread, it seems to be on relatively solid ground. It's a proven,
highly adaptable application in relatively wide use. It's got a solid
community of developers and users.

Other open source projects that make it this far develop a literature
directed at novices. Perhaps, as in some of those case, it will have
to come from outside the TiddlyWiki community.

[Ken Girard]

I think part of the problem with documentation is that the people who
really understand it all are the folks who are busy creating new and
fun stuff. And since that is the fun part, documentation gets pushed
to the bottom of the pile. Plus half the time people are asking these
really amazing questions that no one really had thought about before.

Actually the bigest problem I always hit is that I don't know what
something is called, or it is called something so generic that I can't
look it up. Like doing a search for... well you know that area that
you type all the text into.... ummm... I know it has a name, but what
is it?

Oh, and the info on standard fields: http://tiddlywiki.org/wiki/Tiddler_Fields
Which tells me that the thing I couldn't remember the name of is
"Tiddler Body"

Maybe a good way to document it all would be having a picture of a TW,
and then as you click on each piece it zooms in (opening different
page/tiddler), showing you more detail, but also explaining more of
what you are looking at does, and how it interacts with the rest of
the system.
Example: A full TW > Tiddler > Title > standard field, must be unique,
can be transcluded by using <<tiddler {tiddler title}>>, see
ViewTemplate & EditTemplate, etc,etc, etc.

Ken Girard

> ---------------------------------------------------------------------------­---------------

[Måns]

Hi

I'm just a user enjoying the fact that TiddlyWiki exists and I'm using
it for all kinds of tasks personally (for work and for personal
recreation :-))- lately I have become a little discouraged by the fact
that most(almost all) of the people I communicate with, use IE - They
don't see TiddlyWikis potential as many of the great plugins and
styletweaks I use, don't work in IE..

I thought of the JQuery implementation as an open invitation to get
started with developing jQueryPlugins also for TiddlyWiki.
Plugins, which would "benefit from the much higher quality browser
compatibility layer in jQuery ".
The vision, I thought, was to overcome most of the browser
incompability issues, which are really annoying - and the thing that
prevent a lot of people (all those who have to use IE), worldwide, to
see how usefull TiddlyWiki really is - for all kinds of tasks...
When you have used many, many hours to collect plugins and setup a TW
for specific tasks - and you can't expect people, who use IE - to be
able to use it - and (of all names) call it promising but really just
"Beta-software" - showing perspectictive - but too buggy to use.. -
You get pretty dispirited...

I'm not in a situation where I can be uncompromising - and crave that
the people I work with should use Firefox or Google Chrome. Pcs at my
work suffer under the strict policy that firefox is to insecure and IE
is the stable and secure browser. All banking and economical tasks at
my work, need IE to work :-(

I expected that TWs corecode would get smaller with jQuery and that
bigger TWs with more data would get faster in the process...

I saw these things as an inevitable and neccesary process for a
successfull OpenSourceProject working inside out....

From Wolfgangs perspective I get the impression that the jQuery
implementation is a parallel development, that doesn't provide any
progress or refinement of the core itself...
It provides new possibilities, just as any plugin adds new
functionalties to the core. If this is true, I will second Wolfgang in
the opinion, that jQuery should be separated from TiddlyWikis core and
be an optional plugin to accompany jQuery dependent plugins to work...
- and his point about 2.5.2 to be a fork - in it's own right - but
still a fork.... considering the contributors of plugins, not using
jQuery at all..

On the other hand I don't see any reason why Wolfgang, Saq, BidiX,
Eric Shulmann, Elnoi or ..... should make new forks based on earlier
TW-core without the inclusion of jQuery, if it should result in
maintaining individual parallel upgrading repositories (as in the case
with Mptw?!)

I think it's great that different people with different skills can
contribute with specialized plugins without having to maintain the
core themselves - and that a single TW can be a repository of plugins
and css by itself.... It's pretty awesome when you think about it....
Still it takes a lot of time to discover where to find them - and I
think that the TiddlyHub idea (http://groups.google.com/group/
TiddlyWiki/browse_thread/thread/9c5d6acb27ee957b/5d26bdeab5aead1d?
lnk=gst&q=repository#5d26bdeab5aead1d) would speed things up as well
as paying respect to developers outside of Osmosoft.

I like that you can make your own TiddlyWiki adaption - but I don't
believe for a second that my feeling of ownership in the process of
combining and tweaking - was possible without some degree of work,
involvement and exposure (isn't that what communication and internet
is all about?)- I think that all people: developers, csswizards and
people who can do magic with code, needs exposure (and some fame) for
their original work - to feel responsible and wanting to continue
their work with TiddlyWiki ... - I know I'm on the edge of suggesting
setting up a FaceBookGroup for TiddlyWiki - I don't - TiddlyHub is a
step towards better exposure of contributors and will make it easier
for less involved or new users, - who need quick solutions and an
overview of possibilities...

I'm not sure if some of the things I say are selfcontradictionary - or
even remotely related - Hope it makes some sense anyway..

YS Måns Mårtensson

On Jul 8, 6:34 am, wolfgang <wolfgangl...@gmail.com> wrote:
> Sorry to everyone with a short attention span for this long post. One
> could also proceed to the last paragraph, to get the gist.
>
> > To be clear, there have been three changes associated with jQuery:
>
> > - the inclusion of the jQuery library by default; this is the decision
> > that you go on to critique. There was a fair amount of discussion
> > before we did this; the goal was to enable TiddlyWiki to benefit from
> > the much higher quality browser compatibility layer in jQuery
>
> I read parts of them and I'm very well aware that everyone has put
> serious consideration before implementing such a big change to the end
> of bettering TiddlyWiki. You shouldn't misunderstand my posts, that I
> wouldn't want this to happen. On the contrary, I'm still of the
> opinion you should go forward with this, and I appreciate you do.
>
> Also my arguments for a fork without jQuerry aren't anything you
> haven't heard already and therefore haven't considered before, nor
> could I give better ones as those already given by technically more
> versed contributors before. I just digested all these different

> perspectives (for example:http://groups.google.co.uk/group/TiddlyWikiDev/browse_thread/thread/c...

[wolfgang]

> There's a lot more to say, but it's late, and possibly best said in
> another thread anyway. I wanted to acknowledge that I'm reading all
> this, and thinking about it deeply. I'll try to post some more
> coherent thoughts in a day or two, and thanks for bearing with the
> discussion.
>
> Best wishes
>
> Jeremy

Hi Jeremy,

what are your feelings now. I for my part would still be interested to
hear your ideas on all of this.

regards..

[Jeremy Ruston]

OK, thanks for the prompt Wolfgang. I had decided to give myself a
pause to think, but hadn't intended it to be so long.

I want to focus on the jQuery issue, and hope that by addressing it we
can cover some of the other points that were raised.

From my perspective, the key issue seems to be a concern over whether
the addition of jQuery to the TiddlyWiki core code has provided
sufficient benefit to end-users to warrant the additional kilobytes
added to the core. The concern is sufficiently serious to trigger
talks of a fork. Digging deeper, I can see concerns that the
integration of jQuery is a deep and drastic change, and that the work
is being released in an unfinished, unpolished way that is leading to
instabilities.

There's a few basic beliefs that underpin my reaction to this:

- the key benefit of adding the plugin system to TiddlyWiki back in
2005 was to bring back the various variants that had forked from the
original code, and allow them to share a common platform, making it
easy to upgrade and mix and match
- that the power of tiddlywiki lies as much in the universe of plugins
available for it as in the core code itself
- that the core development should continue to serve the needs of end
users directly, but must also listen to plugin writers in order to
look after that ecosystem
- generally, an open source platform like tiddlywiki should be
extended in a fairly conservative manner, to take care not to cause
incompatibilities across the base of existing users
- the discussion here is dotted with some deep misunderstandings about
the goals and implementation of the jQuery integration, which has
perhaps led to more fear and uncertainty than i'd expected

Having got that out of the way, there's a couple of important mea
culpas, particularly in relation to the last point:

- Bugs, particularly regression bugs, have crept into recent releases.
This is a clear failure on my part, and we're addressing it by
enhancing the TiddlyWiki test suites and by pulling back some changes
that have turned out to be flakey

- Communication has been poor, again Osmosoft needs to do more to
discuss proposed changes. We kicked off a discussion in the dev group
back in January, but it's clear now that the discussion wasn't broad
enough to involve enough people in the community, becoming a rather
dense technical thread

Sadly, part of the cost of my move to BT has clearly been that I have
far less time to spend myself on the TiddlyWiki discussion groups.
(One of the upsides of course is that I've been able to keep an entire
team of developers working on stuff built on TiddlyWiki and TiddlyWeb;
some of the other offers I considered would have entailed me having to
pretty much drop TiddlyWiki in favour of the favoured technology of my
new employer).

My most impassioned observation is that I think we need to do
everything we can do avoid forking. Ever since the dawn of the
systemConfig mechanism, I've felt that one of the wondrous things
about all those varied TiddlyWiki's you see out on the web is that
they are all fundamentally compatible, that one can do this mixing and
matching plugins to create unique variants. Having a single platform
that works on all browsers is a huge win in terms of keeping the
environment simple and approachable.

There's been a lot of discussion about the extent to which the core
code can or should take advantage of jQuery. I've personally been a
bit disappointed: I wasn't expecting it to be a walk in the park, but
it's proved to be fairly tricky and intricate to switch existing core
code to use jQuery. Having said that, I'd like to argue that jQuery
still brings benefits in the area of people writing TiddlyWiki plugins
(and perhaps in future extensions to the core code).

The proposition of jQuery for plugin writers is that it makes it
easier to do a lot of the DOM manipulation that is often needed in
plugins, and particularly makes it easier to do these manipulations in
a way that works across all browsers. (TiddlyWiki incorporates it's
own mechanisms to simplify browser compatibility, but they are
non-standard and brittle compared to jQuery). Although plugins could
make their own arrangements for using jQuery without any core support,
it made it hard to coordinate and share the use of jQuery between
plugins. From the plugin writers perspective, if you're going to use
jQuery it's convenient if it's part of the furniture, something that
you can rely on always being there.

I've made these points before, and perhaps the mood of this thread
suggests that I have failed to bring forward convincing arguments. In
retrospect, perhaps we should have kept the jQuery integration in beta
for a lot longer. We are where we are, though, and we can only undo
the addition of jQuery to the core by creating another incompatibility
crease, or a fork.

We're thinking in terms of a 2.5.3 release next week to bring together
the recent bug fixes, but not to make any major changes. That clears
the decks for our next step. I can understand the call for officially
forking the core, but I fear that it will bring confusion to end
users, over what is in practice a fairly arcane issue for most of
them. One core with many plugins is a much simpler model to grok that
multiple cores with multiple mutually incompatible plugins.

A slightly lighter weight mechanism might be to somehow pull the 2.5.x
releases back into beta.

All of these thoughts jumble around but perhaps it's also worth
pointing out some things that might not be so obvious to outsiders: I
use TiddlyWiki every day, I work on it's code, or plugin code, almost
every day, often over the shoulder of an Osmosoftonian (it still feels
like I'm Chief Debugger in the team). I care as much as anyone about
the thing, perhaps more so. I don't want to destablise it, but neither
do I want it to atrophy, and become a web 2.0 curiosity that never
made it through to the next wave. I think TiddlyWiki embodies some
deep and important ideas about user interfaces, about collaboration,
and how to build software. I want it to be useful for as long as I'm
around to care about it. Furthermore, my career at BT is intimately
tied up with TiddlyWiki. Things always take longer than I expect, but
we have managed to bring TiddlyWiki right into the heart of a crusty
old institution. There's individual TiddlyWiki users scattered across
BT, and some bigger things like TiddlyDocs that are powered by
TiddlyWiki. BT must seem like a weird bedfellow sometimes to other
people in the community, and there are undoubtedly some bumps and
knocks as we settle into place, but I can't help thinking that the
long term picture for TiddlyWiki is brighter with BT's interest. I
hope that the way that I worked tirelessly on TiddlyWiki for three
years before the acquisition shows that my interest and love for
TiddlyWiki transcends my corporate ownership, too.

Cheers

Jeremy

[wolfgang]

Thanks for detailing your thoughts after a thorough digestion. And
good to to let your passion for TiddlyWiki be seen.

I can understand your aversion to different non-compatible versions of
TiddlyWiki in the past, and do see the great advantage of the plugin
system. No question about that.

> Although plugins could
> make their own arrangements for using jQuery without any core support,
> it made it hard to coordinate and share the use of jQuery between
> plugins. From the plugin writers perspective, if you're going to use
> jQuery it's convenient if it's part of the furniture, something that
> you can rely on always being there.
>

> ...forking the core, but I fear that it will bring confusion to end

> users, over what is in practice a fairly arcane issue for most of
> them. One core with many plugins is a much simpler model to grok that
> multiple cores with multiple mutually incompatible plugins.

That's exactly the reason why I don't understand jQuery hasn't been
made available as a plugin. There are already plugins dependent on
other plugins.

Why the core has to be dependent on something which isn't essential to
the well functioning TiddlyWiki core itself, already - with but
limited use cases, as animation?

I simply don't understand. My pledge for a non-jQuery fork wasn't
meant as incompatible to jQuery - but making it meanwhile optional
only.

And if jQuery really would bring more general advantages, like:

* better compatibility between browsers
* allowing to view a TiddlyWiki without javascript enabled browsers
* increasing the saving speed for large TWs
* ...

I would be the first who would use such a jQuerry plugin in all my
TiddlyWikis. But this to materialize will take many months, if not
years..

I hate being a Job's prophet, but my prediction that we will meet at
linear GoogleGroups in a year's time again for support, more than a
year ago - after my not so well received suggestion of using any
simple forum software instead - has sadly also come true.

Kind regards..

[Jeremy Ruston]

> That's exactly the reason why I don't understand jQuery hasn't been
> made available as a plugin. There are already plugins dependent on
> other plugins.

The logic for incorporating jQuery in the core code rather than as a plugin is:

1) To allow the core code itself to use jQuery
2) To simplify writing plugins requiring jQuery so that they only need
a version check, and not the dependent plugin logic

It was the first reason that was more compelling: simplifying the
development of the TiddlyWiki core code itself.

There's a chicken/egg thing, though: TiddlyWiki, like most mature
projects, aims for a fairly slow and steady development schedule, to
try to keep the ecosystem stable for plugin authors and users. This
means that, as you observe, it will inevitably take time for the use
of jQuery to make a noticeable difference to end users.

But the chicken/egg thing is invidious. If we don't make the
pre-investment to add jQuery in advance, it's impossible for the core
code to *ever* take advantage of it.

I guess a lot of this depends on your conception of how important or
useful is jQuery. If you're not a developer it seems like a fairly
abstract thing, I guess. But you don't need to take my word for it, or
Eric's word for it: it's really a very mainstream tool, that's been
found to be useful by a great many people:

http://docs.jquery.com/Sites_Using_jQuery

The advantages of working with jQuery are very real.

> And if jQuery really would bring more general advantages, like:
>
> * better compatibility between browsers

As I've mentioned, this is one of the key advantages of jQuery: it
does an excellent job of encapsulating browser differences. This means
that new plugins or core code that's based on jQuery is much more
likely to run correctly across all browsers.

> * allowing to view a TiddlyWiki without javascript enabled browsers
> * increasing the saving speed for large TWs

For what it's worth, after the recent comments about saving speed I've
personally been spending a lot of time profiling and examining the
savechanges code. It'd be nice to give everyone a summer performance
improvement...

Many thanks

Jeremy