Hide ViewTemplate buttons conditionally

1

I have a similar need to: Hide Tiddler Body except that I need to conditionally hide/unhide the:

toolbar buttons on the ViewTemplate

I could remove ALL of them by .tc-tiddler-controls {display:none] but I need to ADD two of my own buttons. Essentially I’m trying to have a fake edit-mode where a normal toolbar button hides the body (using the hide-body field) but then I want to hide all the regular view buttons and only show 2 of my own to mimic the edit-mode toolbar.

This is for a plugin I’m working on, so I’m similarly trying to avoid changing core template tiddlers. The “obvious” answer is to change the filter in $:/core/ui/ViewTemplate/title for example.

It seems like the official documentation (https://tiddlywiki.com/#Q%3A%20How%20can%20I%20use%20a%20custom%20field%20to%20style%20a%20tiddler%3F) says I should use this as a foundation (copy-pasted right from docs)

<$list filter="[rank[species]]"> 
[data-tiddler-title^="<$view field=title/>"] .tc-tiddler-body {
    column-count: 2;
}
</$list>

but I think this is what @pmario says we should NOT do for performance reasons. There are multiple ways of getting to it, but for example one way I’d want to do this is to make it conditionally dependent on the existing .

Interested in anyone’s thoughts in this area - thanks.

2

If you don’t mind adding a tag to the tiddler while you want the buttons hidden:

[data-tags="$:/tags/stobot/hidebody"].tc-tiddler-view-frame .tc-tiddler-controls button:not(.stobot-btn) {
    display: none;
}

So hide all tiddler controls in the view template for tiddlers with the tag $:/tags/stobot/hideboy, unless those buttons have the class stobot-btn

You can also hide this custom tag from the view template display:

.tc-tiddler-view-frame [data-tag-title="$:/tags/stobot/hidebody"] {
    display: none;
}
3

Nice! that not: bit I haven’t heard of before, so that’ll come in really handy. I think that’ll work - thanks @saqimtiaz

4

As you’ve seen, the :not pseudoclass can be very useful. You can read up on it here:

I’m honour bound to mention the warnings and gotchas listed under Description.

5

Yea, when I wrote the docs, I was convinced it is a good idea. .. I still like the mechanism and the possibilities we have with the tw wiki syntax. … But if we have many tiddlers that have the rank field it starts to create a messy CSS structure in the “background”.

So the “data-tiddler-title” construction should be a “last resort” if nothing else is possible.

The problem is, that it isn’t obvious for the user, since the code which creates the CSS is basically 5 lines.

The resulting CSS will have 3 lines times number of tiddlers with the field. …

I did some debugging about 2 years ago and found out, at startup an event-listener is activated TiddlyWiki5/core/modules/startup/render.js at master · TiddlyWiki/TiddlyWiki5 · GitHub, that will trigger a “style-refresh” with basically every click you make in the UI.

If the core performance instrumentation is active we can see the impact in the styleRefresh value. … And you can see it is recalculated often. That’s where my “warning” comes from. …

So the more tiddlers tagged: $:/tags/Stylesheet are active the more impact is has for UI response time. So delays can be felt by users.

6

I write plenty of conditional buttons, If I want one from the existing set, eg edit button, I clone the core tiddler, and modify that, wrap its code in a conditional list, perhaps also cloning the image and giving a different color. I then hide the core edit button behind the more (untick in toolbar settings) but ensure the modified and conditional tiddler is not behind the more button (has a tick in the toolbar).

This works well and if I had a different user mode I would hide the more button so the current user can’t access the buttons hidden behind more.

As we used to do in TiddlyWiki Classic you could define a whole new toolbar with a different tag and use that “instead” of the default tool bar when in a particular mode.

This approach only configures what you need to configure and does not depend on a global CSS or view template to apply to every button or every render of the toolbar. Its is much more efficient in my view.

7

That’s helpful to know @TW_Tones - I considered that the “proper” way originally, but in my mind looping through all the other buttons (I assume via the tag) and “storing” all of their values for later restoration seemed to be a more “severe” action than just hiding them with css, but maybe I’ll try both and compare.

8

I just realized that this code works great UNTIL the tiddler has another tag on it… I thought changing the data-tags= to data-tags*= but that didn’t seem to resolve it…

toolbar css

9

That is odd. Seems to work:

image
image847×454 15.8 KB

10

Check with the web developer tools to make sure the tiddler has the correct data-tags attribute.

11

@saqimtiaz - it was the tag - css was all fine but because I was using css to hide the tag, I couldn’t tell it wasn’t being added properly! Apparently the ...enlist-input[]append[hidebody]part didn’t add a space between them which seems strange. Stupid error on my part, thanks for the assist.

12

Sounds like a good use case for the toggle operator:

<$action-listops  $tiddler="target" $tags="+[toggle[hidebody]]" />
13

Oooh, hadn’t read that one yet, you’re right - perfect fit. Thanks!

14

A customisation to permit the quick creation of additional and conditional toolbars would be nice. I have done this before and think it may be possible to generalise.