Introducing a Global Variable for Author/Reader Mode

#1

From https://github.com/Jermolene/TiddlyWiki5/discussions/6074

There was time to time discussion on forum to be able to hide some tools from UI when a TW is put on the server to public access or when distributed to end users.

I have used a mechanism in Utility plugin and have seen in other plugin/tools like the Eric Shulman Inside Tiddlywiki book!

Suggestion:

  • add a global variable like $:/config/admin variable with value yes, no
  • a UI lets decide which elements are admin tools and shall be hidden in reader mode
  • allow plugin developers to use this variable to hide admin tools in their plugin
  • allow content creators to use the variable to hide some admin tools like (edit button/delete button) etc.

This way you have a global/central button or tiddler to activate the reader mode or author(admin) mode

If you support the idea please give a thump up on GitHub or join the discussion and share your opinion!

2 Likes
Hiding the sidebar when viewed in the permalink mode
#2

Definitely a must-have.

#3

Mohammad I have implemented something very similar but not designed for making gross UI changes, but to alter the behaviour on tiddlers. My own de facto standards are config tiddlers eg;

  • $:/config/designer-mode yes/no
  • $:/config/author-mode
  • $:/config/debug-mode
  • $:/config/wiki-mode read-only / update / edit

To name a few;

Then in my wiki text I use filters of the form;
[{$:/config/debug-mode}match[yes]]

I have actually played with other methods quite extensively, in fact wasted a lot of time. I finally rested on this because the transclusion is more reliable, if you make a variable and try any automation you find you sometimes need to wikify it before use and this makes it fragile and messy code.

I have also considered the case in your original post and the best method I have so far is changing the mode with a single click from a bookmarklet containing the required changes. This also allows the mode change to be defined outside the wiki so only those with the bookmarklet can do it. That is the means to change to a more permissive mode is not in the wiki.

  • For this reason and somewhat in response to you, I am simplifying and automating the creation of bookmarklets, mostly to handle settings or mode changes.

Other possible methods include;

  • To use conditional startup actions that detect the mode and implements it (I have done this)
  • To use a plugin that detects a state change eg in $:/config/wiki-mode then apply the actions for the new mode.

You may also see here if you have a multi-value mode the complexity increases when changing mode if there are things you have to undo, for example in the wiki-mode example these conditions need to be addressed;

  • Read-only > Update
  • Update > Edit
  • Edit > Read-only
  • Update > Read-only
  • Read-only > Update
  • Edit > Update

This is why I have come to think of separate modes almost like layers. With each mode having a set of conditions that apply “yes or no”, and avoid overlap.

I know my answer is long and involved but there has being a lot of water under the bridge for me on this subject. I hope the lessons from my journey can help others and the community.

1 Like
#4

I do almost exactly this with “feature flags” in my Zettelkasten – you can turn individual features on and off separately for the private and public editions.

At some point I got the bright idea to write an ff macro that generates the required filter to determine if a feature is off or on. This may seem like a small thing, but I find it makes working with this way more intuitive and readable. You can just say:

<$list filter=<<ff MyFeatureFlag>> variable=_>
   my stuff behind the feature flag...
</$list>

…and you don’t have to care about what version you’re in, what flags are on, what the relevant system tiddlers are called, or anything else except what feature you’re selectively disabling.

The macro looks like this:

\define ff(tid) [[$:/config/zettelkasten/FeatureFlags/$tid$]get{$:/config/sib/CurrentEditionPublicity}] -[[no]]

Each of the $:/config/zettelkasten/FeatureFlags/* tiddlers has a public and a private field, each of which is set to yes or no by checkboxes in the control panel, and the yes or no is retrieved from whichever field matches the current value of $:/config/sib/CurrentEditionPublicity. This means I could have as many different “view modes” as I wanted (though I’ve only found a need for two so far). There are also caption and description fields to show in the control panel.

Here’s a permaview showing the relevant pieces. And all this is fully functional in tzk if you want to play with it more.

I don’t use this to control the display of toolbar buttons, though, because I don’t know of a way to do that without editing a bunch of shadow tiddlers. I change those through my build process external to TiddlyWiki instead. So that’s an opportunity for improvement.

2 Likes
#5

The simplest way is to create the matching visibility tiddler eg;
$:/config/ViewToolbarButtons/Visibility/$:/core/ui/Buttons/fold
and toggle its value

Then it appears behind the more button, if you hid that they can see them.

I like your idea of the macro being the whole filter

#6

I do a lot of stuff like that using my own control panel with a zillion settings.

#7

How would I do that based on the value of a configuration tiddler though, as suggested in the OP with e.g., $:/config/admin?

1 Like