That’s right. The only problem we have, is that TW5 does not really have an indicator of a read-only mode.
May be there should be a tv-read-only definition somewhere.
I think that would be a good idea. But regardless of that, I would simply like a way to turn it off. I can manage it for myself when I’m toggling my own read-only mode.
I made something based on my other ViewTemplate checklist that is more functionally similar to the markup usage in TW5-Checklist, but they’re draggable. It doesn’t use the $checkbox widget so no field/tag/external tiddler needs to be created, they’re $button-widgets that look like checkboxes that rewrite the text field directly.
It’s also fairly expandable/customizable in terms of applying a template to an individual line with some sort of markup prefix so you can add functionality besides checkboxes.
6 Likes
I’ve dragged the six listed tids, as well as ReadMe: VT-markup as example of a working checklist, to an empty.html to test, and it’s not working. I’ve checked that the content and tags are definitely there, saved and loaded from scratch. Still no dice.
Any idea what the missing magic sauce is?
Check the order of the cascade filter $:/config/ViewTemplateBodyFilters/VT-markup
ah perfect. VT-markup before the built-ins instead of after and it’s working a charm!
I’d be curious what the performance difference is between this and the tgrosinger/TW5-checklist solution is. Both are very close to what I’ve concluded I want (human-readable wikitext), with the draggable items and more minimal UI of VT-markup winning me over. Plus for my clumsy/naive awareness of what’s happening under the hood, it seems more extensible too (something I simultaneously appreciate, and probably wont use!)
@arunnbabu81 Thanks for answering that for me
I too wonder about the performant-ness of my solution… The drag and drop basically duplicates the entire tiddler into a data tiddler before writing it back over the original so depending on the length of the content it could be a lot. It also has issues with how it splits up every single newline and will screw up widgets spanning multiple lines
I have extended the extensibility even more, it now covers some of the other topics that have come up in recent discussions, @JuanPalomo you may be interested in checking it out. I have split up the code a bit so it should be easier to customize for your own needs, and now you can add/remove additional checklist stages that you can write template tiddlers for. You can also now indent for subtasks.
https://hoopy-wiki.tiddlyhost.com/#ReadMe%3A%20VT-markup%20drag%26drop%20checklist%2Fcycles
1 Like
Thanks so much, hoopyfrood.
I’ll take a look and try it out to see if I can adapt it to what I want.
Best regards.
1 Like
Right. Difficult.
But it is a good solution? Because D&D is voluntary. It adds value but does not assert control?
Let me give you an example where I could use it for arbitrary order.
This is a shopping list in one Tiddler made with 21 Grossinger Checklists.
I order within them manually in WikiText. Add to them via Grossinger.
Could your way add dragability within each of the 21?
Due to a zero padding issue the drag and drop can handle up to 99 lines whether they be checklist items or lines of plain text, though it would be an easy fix to change the zero padding to allow for up to 999 lines. It is also of note that a list with 99 lines (not all checklist/drag and drop items) does lag like half a second on Firefox though it seems snappier on Chrome, see this example to assess the lag yourself:
https://hoopy-wiki.tiddlyhost.com/#99%20line%20shopping%20list
(seeing the 99 line long list made me add columns as a feature, simply type the number of columns into a field called “VT-markup-columns” and that tiddler will render with columns)
1 Like
It’s working well for D&D! Very good.
I did stumble on one issue. The checklist parsing seems to interfere with WikiText that starts at the left margin … Example …
Best, TT
1 Like