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

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:

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.

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.

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:

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

ALex

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

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

ToolbarCommands definitions now support the following special symbols:

< = 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

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/63c4c9...

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

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!!

On Jun 25, 6:50 am, Måns <humam...@gmail.com> wrote:

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 <humam...@gmail.com>:

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

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

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..

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

http://change.tiddlyspot.com/download

kind regards..

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

Alex

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:

<<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..

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

Indeed it is - but that's just natural.

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.

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.

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.

Cheers

Jeremy

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

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.

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

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..

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.

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.

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

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.

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

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.

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.

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

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

Thanks for your detailed perspective.

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.

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 :-)

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..

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.)

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.

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.

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

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.

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

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

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?

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.

:-)

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.

I'm not sure what you mean here.

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.

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?

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

Best wishes

Jeremy

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

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

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...
), 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:

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 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.

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.

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.

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 :-)

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.

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.

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.

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.

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...