TT et al, In relation to different operational modes,
I have being thinking about this a lot and use a few modes in my own wikis, but I would love to see them adopted more widely They follow this format - A config tiddler eg $:/config/author-mode - Which includes a field config-values containing a list of values or a filter - The text contains the selected mode value - A field can be added to any tiddler eg author-mode whose value will override that in $:/config/author-mode if present - A matching macro <<author-mode>> that returns the current mode on any tiddler after testing if the field author-mode overrides it. - Then in tiddlers you can include code that responds to different modes - I have a config tool that detects and displays the values for selection on any tiddler containing config-values Standard modes starts with wiki-mode which has the values of view update edit etc... Then I recommend the following modes at a minimum; - author-mode - designer-mode - debug-mode When I find my exhaustive list I will share. So each will have; - A config tiddler and Config-values - A matching fieldname - A matching macro that returns the value - The ability to select the value from a list or filter in config-values Something I have learned. - Sometimes it is better not to code parts of a tiddler to operate in one mode or the other, but do this within the macros you use last - Imagin a field macro <<field fieldname>> - Within this macro you can determine the wiki-mode or local override and display the field according to the mode eg view update or edit. A new topic for comments posted Tones On Tuesday, 20 October 2020 22:27:50 UTC+11, TiddlyTweeter wrote: > > BurningTreeC wrote: >> >> >> I think in actual practice I'd use Muuri to *arrange a site* for online >>> publishing I do NOT want users to mess with. >> >> >> Ok, yes I didn't think about that so much. There's the option to disable >> dragging and to hide the dragging button from the pagecontrols menu, then >> disabling the dragging-keyboard-shortcut by removing the tag >> $:/tags/KeyboardShortcut and doing the same for the columns button and the >> two columns shortcuts... >> >> What I'm getting at is its a tool for content/organisation by developers >>> as much as for end users. Yes? >> >> >> Which tool do you mean? Muuri itself or the dragging on/off button? >> > > Yeah. The controls. > > Maybe? Maybe some hidden option to HIDE the tool could aid publishers >>> publish their arrangement without worry the end user will mess with it? >> >> >> I would go with the options described above... >> > > Right. FYI I'll likely write a macro do the settings for the contexts I > need on one press. > > My *point* was to highlight some *auteur* issues that are implicit and > make them more explicit. > I wasn't really expecting you to DO anything :-). > Rather, highlight that Muuri can be viewed as an EXCELLENT "author's > arrangement tool" and not just an end-consumer tool. > > I think if you made that clearer it might well increase uptake? In brief, > for site design, it makes an otherwise tiresome task easier. > > Best wishes > TT > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4095c4e4-3e9e-4d05-b851-b58f637f17d7o%40googlegroups.com.
