The immediate motivation is the work I’m doing to integrate with Amazon
Web Services.
We should be able to use JSZip to export multiple tiddlers in a single
operation from the browser.
Instead of showing a sequence of all documents in the preview column,
we just show a single document, with a dropdown to choose which one is
shown.
The change makes it easier to deal with large numbers of documents.
The metadata for each field is in a tiddler tagged
`$:/tags/DocumentMetaData` with the field `caption` being the displayed
caption for the field and `field` being the name of the field.
`field-type` is the type of the field, and can be “string” or “list”.
Previously, newly created image files would end up being saved as a
base64-encoded .tid file. Now they are saved as an ordinary binary file
with an accompanying .meta file for the metadata.
By making the docs available as a plugin we make it easier for people
to fork their own copy of the docs without losing the ability to get
updates in the future (which can be done just be updating the docs
plugin)
Many reasons:
* to allow subtrees to be grafted more easily
* to keep the tags for an entry clean by removing structural tags and
leaving the semantic tags
* to avoid the duplication of expressing the same relationship through
both the tags and list fields
1. Switch from using the text field of lists for storing the associated
filter to using the field `toc-list-filter` (to make it harder to
accidentally parse the text of an ordinary tiddler as a filter)
2. Fix several bugs
The exclude filter `+[tag[intro]]` will produce a document that only
includes the paragraphs with the tag “intro”. These are derived from
the paragraphs in the original document with the CSS class “intro”.
* Add warning in document tiddler toolbar if tiddler already exists
* Live preview document in new window
* Fix slicer.js bug that was preventing the list field of headings from
being filled in correctly
* Rationalise some class names
Now includes a special document view column on the left. Headings can
be expanded/collapsed, and tiddler titles can be inspected and renamed
via the toolbar. Clicking on an entry opens the associated tiddler. The
default tiddler view template includes a special section for tiddlers
that are part of a document
Now we process the rendered HTML of tiddlers, which allows us to
process HTML generated by MS Word. In fact, the HTML that MS Word
generates is so awful, I’ve instead been using Mammoth to do the
conversion: https://github.com/mwilliamson/mammoth.js
Also some necessary improvements to the fake dom implementation.
1. Introduce template tiddlers for the document, each tiddler, and the
tiddler toolbar
2. Move the text slicer toolbar button to the left of the edit button
3. Add a selectable toolbar, currently just containing the tiddler title
We’d rather present this information as a panel within the tiddler
editor so that we can (for example), allow clicks on a snippet to
insert it automatically into the editor at the current cursor position.
For the moment, we’ll just remove the cheatsheet. Post-5.1.8 we’ll add
it back to the editor
* Moved “add new plugin” into a modal wizard
* Adopt big friendly buttons
* Add plugin icons and readmes to “add new plugin” modal
* Use tabs for splitting plugins/themes/languages
* Consistent styling between the “add new plugin” modal and the
“installed plugins” control panel tab
* Behind the scenes, moved from addressing the library as
`recipes/defaults/tiddlers/<etc>` to `recipes/library/tiddlers<etc>`
There was a rendering mess in the CodeMirror readme file. This was cause
by attempting to bold the `$:/tags/Stylesheet` text. Also the context of
the sentence implies this should be backticked not bold (it refers to a
tag not a tiddler).
This is just an idea really.
The help plugin is only included in the tw5.com wiki; the idea is to
also include it in the empty.html wiki, either as a plugin or as part
of the core.
If it stays as a plugin, the idea would be to have different help
plugins for different languages.
