TW5 Customization

[Mohammad]

As you know the TW vanilla for end user should be customized for example one 

may needs to have

 - Highlights.js plugin

 - KaTex plugin

 - Some CSS tiddlers for fonts and colorbox

 -  Material theme

 - ...

Is there any way to have a script or a way to bundle all of these into a single JSON file to be imported to customize the new empty-5.x.x.html ?

I dont want to do this by adding plugins and tiddlers one by one?

-Mohammad

[@TiddlyTweeter]

M,

Use PMario's BUNDLER. https://wikilabs.github.io/editions/bundler/#%24%3A%2Fplugins%2Fwikilabs%2Fbundler

J.

On Thursday, 30 August 2018 15:49:10 UTC+2, Mohammad wrote:

As you know the TW vanilla for end user should be customized for example one 

may needs to have

 - Highlights.js plugin

 - KaTex plugin

 - Some CSS tiddlers customize for fonts and colorbox

[TonyM]

Mohammad,

The bundler plugin is a great tool as josiah said, and I use it a lot. However in the advanced search filter tab you can name multiple filters and tiddlers including plugin tiddlers themself and export them as a single json file.

I now often drop a multiple tiddler json file without plugins (no save and reload needed) on tiddlywiki.com to apply all my prefered settings on it.

Regards tony

[Eric Shulman]

On Thursday, August 30, 2018 at 6:49:10 AM UTC-7, Mohammad wrote:

Is there any way to have a script or a way to bundle all of these into a single JSON file to be imported to customize the new empty-5.x.x.html ?

I dont want to do this by adding plugins and tiddlers one by one?

You can drag-and-drop an entire TW file to import all the tiddlers it contains.  For your purposes, start with an empty.html and drop any of your existing TW files on it.  Then, review the list of tiddlers to be imported, and de-select any tiddlers that are not desired.  Press the "import" button to import the selected tiddlers.  Save the file.  This will be your new starting document any time you need a new "custom empty" file.

-e

[Mohammad]

Thank you Eric, Josiah, and Tony!

 

In this way does the setting like sidebar layout is also imported? I mean those customized setting you may have?

-Mohammad

 

[@TiddlyTweeter]

yes.

[Mohammad]

Thank you!

-Mohammad

[TonyM]

Mohammad,

I tend to drop json files with some configuration not the whole thing. To do this you need to identify the tiddlers you want to capture. See this tiddler that displays recent temp config and state tiddlers. Or use the other custom side bar tabs to identify the changes you want to capture.

https://tiddlywiki.psat.com.au/#%24%3A%2FPSaT%2FTempTimeline%2FSideBar

If you drop this tiddler on a wiki, lets say tiddlywiki.com you can make configuration changes and see what changes, even include those tiddlers in your config package.

Regards

Tony

[Mohammad]

Thanks Tony!

I understood some TW settings are stored in some state tiddlers, so I need to export them among other plugins and  tiddlers.

Cheers

Mohammad

[PMario]

On Friday, August 31, 2018 at 7:17:59 AM UTC+2, Mohammad wrote:

Thanks Tony!

I understood some TW settings are stored in some state tiddlers, so I need to export them among other plugins and  tiddlers.

The existing import mechanism doesn't import "$:/state.. " tiddlers. ... Which imo is an issue, but was implemented for a reason.

I'll check if the "bundler-plugin" can include an import-mechanism that allows us to import state-tiddlers.

-m

[TonyM]

Mario,

Good idea, However unless bundles is installed I assume they will not be. Something to note when you update the bundles plugin

Fortunately visibility, config and temp tiddlers still work I assume.

Regards

Tony

[@TiddlyTweeter]

PMario ..

I'll check if the "bundler-plugin" can include an import-mechanism that allows us to import state-tiddlers.

I noticed you can bundle "$:/state..." tiddlers in a JSON but TW won't import them.

Enabling import of them could be good in some situations. For example I have a tool that I use a lot to calculate aspect ratios and other conversions. Though the state tiddlers change according to user input, on "first--time--run" I use them for initial values which I'd like to be able to transport rather than have to redo 60.

Best wishes
Josiah

[PMario]

On Thursday, September 6, 2018 at 1:27:48 PM UTC+2, @TiddlyTweeter wrote:

PMario ..

I'll check if the "bundler-plugin" can include an import-mechanism that allows us to import state-tiddlers.

I noticed you can bundle "$:/state..." tiddlers in a JSON but TW won't import them.

The plugin import mechanism basically uses the core functions. So I didn't have to overwrite and especially TEST them ;)

Importing everything, like _outdated_ plugins, it's possible to create bundles, that can completely mess up your TW.

 - In the best case like $:/state/* tiddlers, they can mess up your UI settings.

 - In the worst case ... old and/or broken plugins can totally mess up your TW ... That's why they are completely removed from the import tiddler

Once they are removed you still can "re-enable" the checkbox in the UI ... BUT ... They won't be imported, because the are already gone. ... For plugins, that's a feature.

The same mechanism is used for $:/state tiddlers. ... So re-enabling them doesn't work, with the core-import mechanism.

 

Enabling import of them could be good in some situations. For example I have a tool that I use a lot to calculate aspect ratios and other conversions. Though the state tiddlers change according to user input, on "first--time--run" I use them for initial values which I'd like to be able to transport rather than have to redo 60.

Yea ... That's right. ..

I would like to create bundles, that can be used to open the eg: "$:/ControlPanel: Appearence: Toolbars: Editor" tab. It will make it much easier for me to point new users into the right directions ... here in the group.

This mechanism is called app-deep-linking, which is not possible at the moment, but imo it should be.

 - It would also add the possibility to create "offline interactive trainings" for TW.

 - Or "interactive program reviews"

Since bundles can track, which tiddlers are imported, it would be easy to "uninstall / delete" them after they are not needed anymore!

have fun!

mario

[@TiddlyTweeter]

PMario

Thanks for your detailed note on "state" Tiddlers and the pointers to other possibilities like "interactive training".

I think The Bundler is one of the most useful utilities for TW. It has eased my life a lot. IMO its the first choice general tool for both moving Tiddler sets around, portable configuration and general management of a wiki.

-- Makes transport and archiving of Tiddlers a flexible, clear & clean process. I found it very robust and easy to use. The way it integrates into the UI is good too.

  -- It is increasingly needed as TW is growing add-ons, plugins, macro bits, CSS tweaks etc at a fast rate. Just keeping track of good things can be a major hassle. To gave an example, when I set-up  a new TW, depending on its usage requirements, I drag and drop up to 9 bundles according to what is needed. If I did that item by item for the components the bundles now hold if would take hours to locate them all, even if I could remember them.

  -- Management of what you have. I also use the bundler in both list & filter mode simply to know what I have in the wiki, what needs archiving & what can be deleted.

There are two issues I mentioned before in some of the early threads on the bundler which I still hope you might be able to address?

1 -- Have a way of adding comments in Bundler Lists such that it does not throw the count off. I found comments essential to have in complex bundles so you can see at a glance what they contain. Currently I use a pseudo Tiddler title like  [[--- Comment Here ---]] to do that. But it throws the count off. If I could have only one request dealt with it would be for this :-).

2 -- I still wonder if there is a way that a Bundle List could have a "destroy mode" such that, for instance, a list would appear with checkboxes next to each item allowing deletion when in destroy mode? Even better a "select all" too? Something like that.

Thanks for a really great tool!

Josiah

[PMario]

On Friday, August 31, 2018 at 8:54:14 AM UTC+2, TonyM wrote:

Mario,

Good idea, However unless bundles is installed I assume they will not be. Something to note when you update the bundles plugin

I think, with TW we are in a state now, where every extension to "the core", needs to "prove its value", by being a plugin first.

Once we ironed out the hickups in the plugin, we can think about creating pull requests for the core. ...

In this "special" case I think the existing mechanism protects the user. So imo we need to be careful.

-m

[PMario]

On Thursday, September 6, 2018 at 3:32:35 PM UTC+2, @TiddlyTweeter wrote:

....

-- Makes transport and archiving of Tiddlers a flexible, clear & clean process. I found it very robust and easy to use. The way it integrates into the UI is good too.

Thx.

 

  -- It is increasingly needed as TW is growing add-ons, plugins, macro bits, CSS tweaks etc at a fast rate. Just keeping track of good things can be a major hassle. To gave an example, when I set-up  a new TW, depending on its usage requirements, I drag and drop up to 9 bundles according to what is needed. If I did that item by item for the components the bundles now hold if would take hours to locate them all, even if I could remember them.

That's a usecase, I didn't see at the beginning.

For me the first usecase was, to create "proof of concepts" + some docs, that a user can easily include ... AND .. delete, after the tiddlers are not used anymore.

 

There are two issues I mentioned before in some of the early threads on the bundler which I still hope you might be able to address?

1 -- Have a way of adding comments in Bundler Lists such that it does not throw the count off. I found comments essential to have in complex bundles so you can see at a glance what they contain. Currently I use a pseudo Tiddler title like  [[--- Comment Here ---]] to do that. But it throws the count off. If I could have only one request dealt with it would be for this :-).

I was thinking about that, some time ago. ... The TW .multids-like structure may be an option to store comments. The .multids parser already understands them. So we could re-use existing code, without too many modifications. .multids files are part of eg: languages. ...

If a line starts with a hash sign: # ... it will be treated as a comment.

The problem I saw, was, that we already have 2 formats, that do very similar things: DataTiddlers:

 - JSON tiddlers

 - Dictionary tiddlers 

 

JSON tiddlers don't allow comments, because of the specs.

Dictionary tiddlers are very similar to .multids, but lack comments and the internal API isn't easy to use. ... I didn't want to create a 3rd format.

IMO a bit more thoughts may be needed.

2 -- I still wonder if there is a way that a Bundle List could have a "destroy mode" such that, for instance, a list would appear with checkboxes next to each item allowing deletion when in destroy mode? Even better a "select all" too? Something like that.

Like an "uninstall-button" :) ... Yea, if you have 9 bundles with several tiddlers installed, it can be quite challenge to uninstall them.

-mario

[@TiddlyTweeter]

PMario on the "commenting problem" ...

IMO a bit more thoughts may be needed.

Right.  Just for the sake of completeness two comments ...

--- Some time ago Thomas Elmiger proposed a solution where you have a "wrapper Tiddler" around the Bundle List that could also itself be bundled as a kind of "Read Me". Examples here (without added details but you could add any comments you wanted): http://tinyurl.com/yaclbxj2 Discussion of this here with my comments: https://groups.google.com/d/msg/tiddlywiki/_Uqbg08Pjow/PJ23RiDAAwAJ I think it could be good where you want to describe a simple Bundle List--but if you have a complex Bundle List and you documented in the "wrapper" all its components it would be hard to maintain if you changed anything in the bundle. So I think comments would really be best in the bundle itself.

--- Just a thought. Could the format stay the same BUT the counting be sensitive to non-existent Tiddlers (which = comments)? So math is used to reduce the displayed total? UPDATE: By this I meant reduced by pseudo Tiddler numbers that start with a specific string like "[[---", in addition to the normal method that exists (& shows false numbers when you include pseudo Tiddler titles). Hope this is clear.

Best wishes
Josiah

[@TiddlyTweeter]

Email readers: I updated my last post in this thread online in GG to clarify what I meant. J.

[PMario]

On Thursday, September 6, 2018 at 7:19:48 PM UTC+2, @TiddlyTweeter wrote:

--- Just a thought. Could the format stay the same BUT the counting be sensitive to non-existent Tiddlers (which = comments)?

Good thought!

To test the theory, just open the tiddler:  $:/plugins/wikilabs/bundler/ui/Bundles and change the 2nd line

from:

\define filter-list() [enlist{$(currentTiddler)$}]

to:  

\define filter-list() [enlist{$(currentTiddler)$}!prefix[--- ]] 

So the new convention would be, that the title-prefix for a "comment-tiddler" is 3 dashes + a space: "--- "

Please test, if that would fit your needs.

-m

[PMario]

On Thursday, September 6, 2018 at 11:05:28 PM UTC+2, PMario wrote:

On Thursday, September 6, 2018 at 7:19:48 PM UTC+2, @TiddlyTweeter wrote:

--- Just a thought. Could the format stay the same BUT the counting be sensitive to non-existent Tiddlers (which = comments)?

Good thought!

The funny thing is, that those tiddlers would be included into the bundle, if they actually do exist. ... So they are kind of "shadow bundled" :)

They can contain more documentation if needed.

... I actually like that idea.

-m

[TonyM]

Josiah, and Mario,

I am using bundles for a lot for things, usually reusable code but sometimes for copying or moving tiddlers.

The destroy mode you are looking for is there for whole of bundle deleted by clicking on the number next to the bundle in the side bar. In the advanced search window you can select delete.

This draws attention that bundles are basically filters or lists of tiddlers. As a result there are plenty of solutions that can help use and manipulate them. So it would be easy to create a generic tool for deleting items in a list and provide the bundle list/filter to it. And this tool will be used elsewhere.

On the comment tiddler idea I have a tiddler naming standard that includes a tiddler with this information in my bundles including in its fields the name of the owner wiki.

If there were one feature in bundles I would like, But I do not know how to do it. It would be if I could allow bundles to be imported only if a condition were true, such as do not import the bundle to the wiki that generated it (unless acknowledged) 

egards

Tony

[PMario]

On Friday, September 7, 2018 at 1:24:49 AM UTC+2, TonyM wrote:

The destroy mode you are looking for is there for whole of bundle deleted by clicking on the number next to the bundle in the side bar. In the advanced search window you can select delete.

That's right, but it's only available for filtered bundles. ...

 

If there were one feature in bundles I would like, But I do not know how to do it. It would be if I could allow bundles to be imported only if a condition were true, such as do not import the bundle to the wiki that generated it (unless acknowledged) 

That is hard to find out by the plugin. So the user will need to help :) ...

It may be possible, to define a "config-tiddler" that contains a filter. ...

If the filter returns true all elements of the bundle could be disabled by default. ...

With the option to re-enable them again .

I need to improve the import mechanism, so it's worth to think about that too?

have fun!

mario

[TonyM]

Mario,

Yes, improving the import mechanisium would help a few things. I have raised it previously but also discovered how the tempoary import tiddler is generated. A hook to allow additional logic to be placed inside that tiddler should be trivial and plugins like your bundler could add their own additional logic. Otherwise overriding the shadow tiddler will work.

Regards
Tony

[@TiddlyTweeter]

Ciao PMario

I'm testing now. Please note I think you meant to "change the \define in ..."

$:/plugins/wikilabs/bundler/ui/BundlesList

J, x

PMario wrote:

... open the tiddler:  $:/plugins/wikilabs/bundler/ui/Bundles and change the 2nd line

[@TiddlyTweeter]

PMario asks ...

So the new convention would be, that the title-prefix for a "comment-tiddler" is 3 dashes + a space: "--- "

Please test, if that would fit your needs.

Brilliant! Thank you. It works for my use case perfectly. All my numbers are now correct.

In addition it is worth noting ...

-- IF you make a mistake in how you enter a comment the count X/X won't match. So this immediately helped me fix two bundles where the start (a typo) was "[--- " rather than "[[--- ", and another where I only had 2 dashes not 3. So it gives a kind of proxy error-check that is useful.

-- Regarding a release of this. Not sure if possible be being able to configure the "comment prefix" might suit users who don't want my string. UPDATE: But that would break portability so maybe a standardised prefix is best.

-- The fact that you could actually make a Tiddler starting with the comment prefix that would (1) not be counted but (2) would be transported is an interesting side effect. I can imagine a scenario where it could have utility. For instance a "Read Me First" note that is useful but not part of the actual mechanisms you are transporting.

Best wishes
Josiah


 

[@TiddlyTweeter]

Ciao PMario & TonyM

Regarding DELETION of items in Bundle Lists (not Filtered) ...

Its an interesting issue. And in my specific use case it doesn't look that easy. An example will show why ...

title: bundle.base    tag: $:/tags/Bundle

bundle.base

[[--- PMario's plugin that enables opening tabs as untabbed Tiddlers ---]]
$:/plugins/wikilabs/link-to-tabs

[[--- Felix's flow adjustment ---]]
$:/plugins/felixhayashi/topstoryview

[[--- Base changes in CSS ---]]
$:/css.tweaks.basic

[[--- Hide descriptions in Tools menu ---]]
$:/core/ui/SideBar/Tools

In this use case there are (1) disparate types and names of Tiddlers (filtering too complex); (2) there are multiple components only one or two of which I may want to delete, not all of them.

So the problem arises of HOW to delete one or more items AND leave the rest intact AND update the Bundle to match. Currently I do it all manually.

That is just my typical use-case. Other use cases likely would not have that complexity and could likely be done more easily.

FWIW to make my manual "pruning" easier when I need to find and delete in the TW something listed in a bundle I change content Type to "text/vnd.tiddlywiki" the easier to navigate to them, then delete. Then I switch the bundle back to "text/plain" and edit out lines of items now gone. Its cumbersome but okay.

Best wishes
Josiah

[TonyM]

Gentlemen,

Running with my own idea on this I have modified the import mechanism to allow additional code to be added to the import process

Basically with my modified system tiddler $:/core/ui/ImportListing you create a tiddler (sample Provided) tagged $:/tags/importcolumn

In such a import column tiddler the following fields are transcluded as follows

• above-listing Shows above the import table - perhaps use to indicate instructions
  
• below-listing Shows below the import table - who knows
  
• caption is used as a column heading - and can provide tooltip and/or link to the import column tiddler
  
• text contains the wiki text to use for each import item - for example show tiddlers with a specific field 
  

In my first test I use it to interrogate the wiki-owner field of incoming tiddlers, and I can uncheck those owned by the current wiki. Import this bundle, then import it a second time to see it in operation.

For those already familiar with tiddlywiki the are a lot of ways you can interrogate or manipulate the list with these hooks, and bundles and plugins can include their own additional import support tools. I am yet to investigate removing items from the import list automagicaly, but I expect it is possible at worst with a button.

Since this is perhaps less than 100-200 bytes it makes sense for this or a re-worked version be added to the core  $:/core/ui/ImportListing tiddler such that any plugin or user can extend the import function as needed without modifying the shadow tiddler.

Please give me your feedback before I submit it to the GitHub Issues, as "Extensible import facility"

PS in the above discussion about bundles I would like to add I quickly abandoned using the standard bundle, and now only use the filtered bundles since it is easy to list tiddlers in the filter anyway.

Regards

Tony