Thanks for the detailed reply, Eric. 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.
Nor did I expected the partial revoking of your permission to use and share variants of your scripts - as long as they would comply with your rules - when I inquired if they would. Please point it out where I still don't follow your explanations, and how this really is. > * Using a single plugin to load the supporting functions as startup is > MUCH more efficient than constantly re-defining all those functions > every time each QuickEdit button is rendered, which can result in > increased memory usage and a general slowdown in performance due to > increased 'garbage collection' processing and well as the potential > for 'memory leaks' in some older browsers. > 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. > * Individual QuickEdit buttons are stored in separate tiddlers so that > specific buttons can be optionally transcluded simply by adding/ > removing the appropriate <<tiddler>> macro in QuickEditToolbar (or > just delete the referenced QuickEdit_* tiddler and leave the macro in > place). Separate tiddlers also makes it easier to change the order of > the buttons or add your own buttons without having to edit a massive, > monolithic tiddler full of code. > This is indeed the best reason for separating QuickEditPackage into so many tiddlers: for a beginner its much easier to choose which functions he needs to import on setup without having to modify the tiddler containing code. For anyone else editing 2 rather large tiddlers isn't that much of a difficulty, if the sections have been clearly marked. And as it is available with the variant [[EditBar]] now. > * Using sections to define the fontList and customFormat lists will > break the "[edit list...]" command that is included in the droplists. > The list definitions really should be kept in separate tiddlers so a > standard tiddler editor can be used to view/modify their content > without having to wade through all the QuickEdit code. > On the opposite: Now the "[edit..]" under the 'custom' button opens the second, and the "[edit..]" under the "font" buttons opens the first of only two EditBar tiddlers. The custom definitions are placed in the first section visible at the top, right on clicking this commands. And I think it's much easier this way, also to add custom formats to the other predefined definitions. > * Most of the size savings you report were achieved merely by removing > the separate documentation (slice table and usage) from each tiddler > when you combined the QuickEdit_* tiddlers. > This is the best reason for limiting QuickEditPackage to 2 tiddlers only, and making the many times multiplied tables and documentation about basic tiddler transclusion obsolete. > The *only* dependency is to install a single 'systemConfig' tiddler: > QuickEditPlugin. > But the dependency to StickyPopupPlugin hasn't been removed at all, since this plugin's whole code section has merely be appended to QuickEditPlugin. I think this isn't advantageous at all: Many will have StickyPopupPlugin's javascript invoked even twice on startup now. Therefore, I still think my experiment is better than how QuickEditPackage is implemented now: By not invoking all javascript functions on startup while they may often not even be used later on - but instead only that little piece of javascript by one button click, run and processed only when that little piece is really needed. Not to talk about the reduction in size, which could be much more if the code would be compressed - as it has been done with an other plugin of such a big size: http://tiddlywiki.abego-software.de/#YourSearchPlugin > > Or, for example, MiniBrowserPlugin, by using its last inline script > > before it was converted, from 16683 bytes down to 8450 bytes: > > http://menuflex.tiddlyspot.com/#Browser > > While you are free to use whatever obsolete scripts you want, I'd > strongly prefer that you *don't* re-distribute this inline script, > which I retired and removed from distribution a very long time ago. > I could understand your reasoning if anything would have been broken with this very compact and versatile html script. But this isn't the case at all. Nor do I understand why you deviate in this case from what you wrote in the faq: > http://www.tiddlytools.com/faq.html: > > 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. > The main use I find for the now variant [[Browser]] script, is to have a compact iframe to show a few other websites with ease, but still not navigate away from the main. It makes it really complicated if you consider this old, but perfect html script fitting the bill, not as a very useful tool for websites worthy of sharing. Of course, I can do the same much less than perfect with individual iframes, but that would defeat the OpenSource spirit and 'Attribution- Share Alike', in my eyes. With MiniBrowserPlugin you made it obligatory to have it loaded on startup (while this is one of the least used during many sessions) and to have all the added more advanced functions, in my case unnecessarily, on top. And to the question of a script being 'obsolete' - depending really on the individual objective alone - this is the one obsolete for me. However, there is no way I can argue what you personally prefer to be shared, even when I really can't follow your reasoning here, and why you would revoke your stated policy in this case. Though sad, not only about being unable to share, but about not being able to put it to good use as explained above - and having to use hard coded iframes or simple links, which take away from the site instead - I will comply :-( I only beg you to reconsider, and if there wouldn't be a way - how it would at least be a little tiny bid OK for you? ...still being enabled to use such a perfect variant of an older version of a script for its main purpose as a tool, while simultaneously sharing its goodness with others? > ... which can result in > increased memory usage and a general slowdown in performance due to > increased 'garbage collection' processing and well as the potential > for 'memory leaks' in some older browsers. > That's just the point for my case! Not everyone's TiddlyWiki has so many precious jewels as TiddlyTools - so that no one would ever complain about how slow every click is processed there (on my not really old machine). I believe everyone is the best expert oneself, and knows which version is fitting one's objective the best. Also with the implication, that I would have to take it down - if I couldn't help with a bug and my limited abilities - while with your plugins instant support is almost guaranteed. I hope you''ll give this some second thoughts, and leave some of your really amazing show case inventions open to modifications, by continuing to allow trimmed variant versions for practicality. You could even feel glad about others doing it for everybody else :-) kind regards... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWiki?hl=en -~----------~----~----~----~------~----~------~--~---
