Great you took the effort for giving your perspective too,
> > On the other hand, it doesn't really address the slow down on startup
> > through the invoking of all systemConfig javascript functions, in many
> > sessions without the need at all.
>
> Unlike some plugins, during startup QuickEditPlugin simply defines a
> set of functions. It doesn't perform any 'tiddler lookups' or other
> compute-intensive processing. Thus, the 'slow down on startup' for
> this plugin is virtually *nil*.
>
Tiddler : Startup Time:
MiniBrowserPlugin: 16ms
QuickEditPlugin: 16ms
Though the startup time of 16 milliseconds is practically nil, taken
together with all other TiddlyTools plugins, this sums up to at least
15 second for a reload from my drive. And you certainly gave the
streamlining of this particular startup some consideration - while a
user might combine TiddlyTools plugins with various others, without
being able to tune a specific combination.
I've got a TW with all systemConfig tiddlers found imported,
altogether 1270 plugins, a file amounting to 9380 KB in size (though I
stopped updating it a year ago, because I wrongly assumed TiddlyHub
soon would overtake my efforts). - And this monstrous TW takes exactly
as much time for a reload, as TiddlyTools with 'merely' 114 plugins
and 2400 KB only!
The difference being that through the lack of any systemConfig tag in
my plugin repository, none is loaded on startup. And to edit tiddlers
is still as much fun as with a vanilla TW - while I wouldn't want to
be the editor of TiddlyTools, which is only a quarter of that size.
(Only on saveChanges TiddlyTools beats my plugin repository with 10,
compared to 45 seconds)
It is a undeniable fact that the startup, together with the
responsiveness of a TiddlyWiki, degrades with the number of plugins
much faster than through its size. If I would add a systemConfig tag
to only a few in my repository, it would very fast defeat even the
most patient.
> > The times I push a EditBar button on average is maybe 10 - thereby not
> > constantly, but merely redefining maybe a 10th only, with a 10 times
> > less slowdown - of what QuickEditPlugin does at startup all at once
> > and with full force. While often not even needed later on.
>
> The plugin defines the support functions exactly *once* (at startup).
> In comparison, the EditBar script redeclares those functions every
> time the toolbar is *displayed*, even if you never click on a single
> button... and, given that you always show the toolbar when editing a
> tiddler, the 'scripted' approach will be invoked many more times than
> the plugin code. (note: the issue here is not processing *speed*...
> it is the potential for *memory* usage problems)
>
Thanks for clarifying this point. By your answer in this thread I was
under the impression, popups would only be rendered upon opening:
> http://groups.google.com/group/TiddlyWiki/browse_thread/thread/dd115fffaa4375de/99235dce35053f94?lnk=gst&q=popup%2Bhover#99235dce35053f94
>
> > This brings up the question if popups in general, and onmouseover in
> > particular, are rendered immediately on first display of the menu, as
> > it is with the core slider macro - or if they are only rendered once
> > there is a onclick or onmousover event?
>
> Popupcontents are rendered every time an onclick (or onmouseover)
> event is triggered. When thepopupdisappears, it's contents are
> removed as well, and will be re-rendered the next time thepopupis
> shown.
Since I haven't been able to make your piece of code independent with
the tiddler code transclusion - wouldn't placing the [[EditBar]] in a
popup help?
On the other hand, though I don't disbelieve anything about the
'potential' memory leakage - practically in my experience of using the
QuickEdit inline script for more than 1 year - I can't confirm any
perceivable memory leakage, instead repeatedly that an increasing
number of systemConfig tiddlers slows a TW drastically down. That's
why I used wherever possible inline scripts, or loaded large and
rarely used plugins with wiklets from a sub folder, whenever they are
really needed.
> Again, this is not correct: the code in EditBar is invoked *every*
> time the toolbar is *rendered*... thus, it costs much less to declare
> the functions in a plugin invoked once during startup rather than
> every time any tiddler is edited.
Again - theoretically possible - but practically the maybe 16ms for
opening a tiddler in edit mode isn't even felt. While the lag during
startup with a number of systemConfigs can be very easily perceived.
> However, if you make a simple typing mistake while editing, it could
> break the entire toolbar, rather than merely having a somewhat messed
> up list of fonts or custom formats. I see no advantage to exposing
> the *code* to unintended changes just because you want to modify some
> supporting *data*.
>
Hopefully everyone is as reasonable to make backups before editing any
script tiddler. And for those who don't (like me, sometimes) there is
always the original source, to start all over again.
> I have deliberately choosen to deliver my work in a fully human-
> readable format. That way, it's possible ...
> ...
> maintaining and publishing both an uncompressed *and* a compressed
> version of the same plugin would create more work for me (as well as
> taking up extra space, since I would still need to distribute *both*
> versions on TiddlyTools).
>
Given it is made unmistakingly clear - that you wont give any support
for compressed variants, before a bug hasn't been confirmed by
installing instead the original plugin - we could both save much time!
Because many times I exchanged all my compressed versions of your
plugins before I made a document public, only due to perceiving your
ambivalence here.
> In all honesty, I'm not sure it's entirely a matter of *reasoning* on
> my part... there's a certain amount of 'it just doesn't feel quite
> right' involved as well. In any case, all of the functionality you
> want to use *is* provided by MiniBrowserPlugin, so you should simply
> use the published plugin rather than taking away anything from your
> site's usability.
In feelings often something very specific, but not yet verbalized, is
implied. It will become obvious, if given the space it needs..
Anyway, at my machine I simply use other browser tabs - and in online
TW's I still can use iframes in specially styled tabs for showing a
couple of other sites, while even increasing my sites usability by
leaving out superfluous processing at startup.
There is absolutely no need for embedding other media in my case,
which would justify the installation of such a huge plugin. But not
for the only reason of giving a glimpse of other websites, which is
too marginal a purpose for most websites, But overall for trying my
best not to make a visit to my site an unpleasant experience for the
practical reasons explained further above.
Maybe others feel similar here, because I couldn't name even 3 well
made TW sites which use MiniBrowserPlugin. Most also seem to give
priority to really essentials plugins of a similar size, as for
example: NestedSlidersPlugin, ForEachTiddlersPlugin,
SearchOptionsPlugin...
> Also, to be precise, I haven't "revoked permission to use and share
> variants of my scripts": you *can* share this script if you feel it
> is absolutely necessary... but I'd still really *prefer* that you just
> use the full MiniBrowserPlugin instead
>
Absolutely certain is only that we age, fall ill and die in the end. I
feel there is already enough tasting alike.
Therefore I have taken down the [[Browser]] script.
MenuFlex has become a collecting place with many scripts with stunning
functions possible without any dependency to essential plugins. And
your old, lean and perfect MiniBrowser script was one of the more
advanced. Only uncertainty even in the world of open source is for
sure.
> Please don't generalize the discussion to encompass all of my
> 'inventions'... my reponses in this thread were specifically regarding
> use of the old MiniBrowser script vs the up-to-date
> MiniBrowserPlugin. Although I'll continue to think about this and may
> still change my mind, I just don't feel that you've made a
> *compelling* case for continuing to distribute the older, retired
> script, specifically because a perfectly fine replacement plugin is
> currently available.
>
Eric, I really appreciate your sincerity in all my discussion
encounters with you, beside your amazing work.
But I don't feel I owe you a 'compelling' case, because my practically
experienced pro and cons remain purely my thing. I choose the scripts
I need, that's something you can't also take the responsibility for.
This is what OpenSource is all about. (please correct me, if I got
this wrong)
However, it is my simple wish that - after taking whatever time this
decision may need, and without any expectations from my side - to
either have this unequivocally clear statement in your faq tiddler
adapted:
> Having said all this, I want to also emphasize that you are permitted
> to make whatever code changes you need to TiddlyTools components
> to suit your specific purposes... and you are also allowed to share those
> altered plugins with others, as long as they are clearly differentiated
> from the originals, as described above.
- or those plugins or scripts noted, you to not want older versions or
variants published, and therefore the OpenSource revoked.
Or you stay with the share alike license and give its source freely
and open for anyone wanting to do whatever he/she wants, even if this
would be to break it. You can't at the same time 'prefer' not to.
Either you give freely - or you don't. And it is very clear in the
following, that you don't have the volition to give freely in this
case:
> Perhaps I should have been more clear in what I was trying to
> communicate, which was that I *prefer* that this particular script not
> be redistributed... primarily because I have completely re-written it
> as a plugin, and I *want* people to use that up-to-date, actively
> maintained plugin code, rather than staying with older script code
> that I don't want to support any longer.
As you affirmed, it isn't really that you prefer it not redistributed
for not having to support it any longer. Nobody expects that from you
on top of the selfless service to this community, and the
unprecedented support for your plugins (if I listed all the
improvements which you realized after me asking, this would get very
long).
So.. what could be the deeper reason for this holding back? .. There
seems to be this want to have people use plugins they don't need,..
how does this *want* feels like, for you .. ?
Beside being tired having to update every time I upload a TiddlyWiki
with your scripts and plugins - for not taking and sharing for what
I'n not sure if is freely given - your ambivalence doesn't feels good
on my side. And I would prefer every clarity, also if it goes opposite
to my wishes. At least it would be clear.
Again, take the time it needs. And I strongly hope my honesty hasn't
offended you, but even may help to more clarity also within yourself.
Sharing could give so much more beyond what is given.
I from my side, only will take what you truly give.
regards..
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to TiddlyWiki@googlegroups.com
To unsubscribe from this group, send email to
tiddlywiki+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/TiddlyWiki?hl=en
-~----------~----~----~----~------~----~------~--~---
