BR's Sidebar Tabs Ledger

[Brian_Radspinner]

I threw together a beginning idea for a Tabs Organizer to easily show/hide the Main or More tabs in the Sidebar. Here’s a demo I can’t remember seeing such a thing elsewhere so I made it myself.

• I need a good way to keep non-default tabs from disappearing when completely un-checked. Ideas are welcome.
• I plan on getting draggable lists enabled to re-arrange the position of tabs
• When (if) it feels right, I’ll tag this to show up in the Control Panel

Thoughts, Ideas, etc… are welcome. Beneath the image is the code, just one tiddler is needed for now.

\define checkMain() <$action-listops $field="tags" $subfilter="$:/tags/SideBar"/>
\define uncheckMain() <$action-listops $field="tags" $subfilter="-$:/tags/SideBar"/>
\define checkMore() <$action-listops $field="tags" $subfilter="$:/tags/MoreSideBar"/>
\define uncheckMore() <$action-listops $field="tags" $subfilter="-$:/tags/MoreSideBar"/>

\define defaults() 
[[$:/core/ui/MoreSideBar/All]]   [[$:/core/ui/MoreSideBar/Drafts]]   [[$:/core/ui/MoreSideBar/Explorer]]   [[$:/core/ui/MoreSideBar/Missing]]   [[$:/core/ui/MoreSideBar/Orphans]]   [[$:/core/ui/MoreSideBar/Plugins]] 
[[$:/core/ui/MoreSideBar/Recent]]   [[$:/core/ui/MoreSideBar/Shadows]]   [[$:/core/ui/MoreSideBar/System]]   [[$:/core/ui/MoreSideBar/Tags]]   [[$:/core/ui/MoreSideBar/Types]]   [[$:/core/ui/SideBar/Open]]   [[$:/core/ui/SideBar/Recent]]   [[$:/core/ui/SideBar/Tools]]   [tag[$:/tags/MoreSideBar]]  [tag[$:/tags/SideBar]]
\end

<p>Check/Uncheck the boxes for each tab to view in the Main list (horizontal), in the More list (vertical), or not at all.</p>
<table class="no-borders tabsWork">
<tr>
<th>Sidebar Tabs</th>
<th>Main</th>
<th>More</th>
</tr>
<$list filter="[subfilter<defaults>] :sort[get[title]]">
   <tr>
      <td><$link/></td>
      <td><$checkbox filter="[list[!!tags]]" checked="$:/tags/SideBar" unchecked="" default="" checkactions=<<checkMain>> uncheckactions=<<uncheckMain>> ></$checkbox></td>
      <td><$checkbox filter="[list[!!tags]]" checked="$:/tags/MoreSideBar" unchecked="" default="" checkactions=<<checkMore>> uncheckactions=<<uncheckMore>> ></$checkbox></td>
   </tr>
</$list>
</table>
<style>
table.no-borders,
table.no-borders tr,
table.no-borders tr th,
table.no-borders tr td { border:0 ; }
table.tabsWork tr :nth-child(1) { text-align: left; }
table.tabsWork tr :nth-child(2),
table.tabsWork tr :nth-child(3) { text-align: center; }
</style>

[markkerrigan]

I like how this illustrates how simple it can be to control various TiddlyWiki UI elements.

I’m not sure how much this is an issue anymore, but accidently clicking the More tab on really large TiddlyWikis could cause the browser to freeze.

[Mohammad]

I support the idea of having some settings in control panel allow user show/hide tabs.

[fastfreddy]

That is pretty nifty and useful; will be using your tiddler/plugin unless it makes it into the control panel…
Cheers

[amreus]

@Brian_Radspinner it’s a good idea and good implementation.

@markkerrigan

I like how this illustrates how simple it can be to control various TiddlyWiki UI elements.

Yes and although it’s been discussed at length, a simplified user interface or control panel would benefit most users.

Here is a tiddler I add to help working with tiddlywiki. It resides in the Info panel, and acts as a quick way to specify tiddler roles. Keeps me from having to remember common system tags.

[pmario]

That’s an interesting concept.
Thx for sharing

[amreus]

@Brian_Radspinner

I need a good way to keep non-default tabs from disappearing when completely un-checked. Ideas are welcome.

The prefix filter operator may come in handy here. If you create a hierarchy of titles such as:

$:/br/tabs/some-tab1
$:/br/tabs/some-tab2
...

You can list them using a filter such as [prefix[$:/br/tabs/]]

[Brian_Radspinner]

A few updates:

1. I decided on a method of storing a list of user-added tabs: a $:/config/ tiddler that is also used for…

2. Adding user-specified tiddlers to the available tabs list;

3. A separate list of user-specified tiddlers to make it easy to remove them from the main list;

4. Tags pills for re-ordering the tabs. Not a great look, but it works until I can figure out a drag ‘n’ drop for the tiddlers list itself;

5. Tagged the tiddler to put it in the Control Panel, now that it has enough options to be (IMO) actually useful.

6. Added a link to be able to drag the system tid onto your own wiki.

Click right here to go to the demo.

[Eskha]

Hello Brian,

I have followed some similar path and propose a generic configuration tool that takes the following assumption and may complete your solution:

*all sidebars tab sets (like more) are generated using a tag of the form $:/tags/...SideBar: a tab with the $:/tags/XXXSideBar tag is therefore shown in the XXX sidebar tab set.
*a sidebar tab tagged with $:/tags/XXXSideBarDisabled is displayed in the configuration tool under the list of tabs that can be shown under the XXX tabs set but is not currently rendered.

You can have a look at it in the more \ config \ sidebar tab.
Here

BR,

Eskha

[dongrentianyu]

This method is really good. But in plugin development, we want to not change the content tiddlers and use configs tiddlers instead. But the problem is that configs tiddlers don’t eliminate the headings on the tabs. It’s just that the content disappears, but the headings are still there. This is a troublesome problem.

[TW_Tones]

OK, I am late to this thread, but having looked at solving this issue in the past, I realised the act of adding or removing a tag, which on a shadow tiddler edits the tiddler anyway. So I thought why not use the tab tiddler, itself to store a tag that has being removed?

My design idea here is to enable for a nominated tag eg $:/tags/SideBar or any other or all tags, we could provide a checkbox to remove it and with its actions add the removed tag/title to a different tags field eg: offline-tags (a list field).

• Now to list all tiddlers that were or could be tagged $:/tags/SideBar you search for this in the offline-tags field.
• Unless you edit the offline-tags field, tags added this way remain there, in a sense keeping a history of tags that have being used on that tiddler.
• If offline-tag(s) exist on a tiddler present them as a list of tags you can apply to this tiddler.
• You could also distribute tiddlers with some offline-tags preset to present the user with config options.

With message catcher,

To get really sophisticated we could use the message catcher widget to capture tm-remove-tag and also copy the tag to offline tags, so removing a tag will always add it to offline-tags.

• We could also add a tab behind the info button that lists online/offline-tags tags so you can do it “on demand” in each tiddler.

[Springer]

@TW_Tones

enable for a nominated tag eg $:/tags/SideBar or any other or all tags, we could provide a checkbox to remove it and with its actions add the removed tag/title to a different [tags] field

This is absolutely one of those nagging issues that I’d love to see us collectively solve.

I’m not sure of the best method, but just brainstorming, a different angle would be to leave the tags as they are (not modifying the shadows), while enabling the “containing” tiddler (such as $:/tags/SideBar to have a “hide-list” field (or something like that), and to modify its display conditions so that it displays whatever has the tag and is NOT listed in its hide-list field.

I always feel weird about un-shadowing something just in order to change whether it displays in this or that place; I like to think my non-shadow tiddlers are different from the shadow in more substantive ways. In particular, I appreciate TW’s built-in warning about editing a shadow tiddler, and I’d like that warning to reflect whether I’ve actually changed the tiddler’s content in meaningful ways.

Here’s an example, and more consideration in favor…:

Suppose I remove the orphans tab from the More sidebar tab…

What I’m modifying should not really be the $:/core/ui/MoreSideBar/Orphans tiddler itself — It’s cleaner to think that I’m making a change to $:/core/ui/SideBar/More by having it not currently display that orphans tab (or whatever).

This approach would let the tags stay as they are (so they’re always available for re-finding things we may want to re-activate, and they also remain unchanged shadows)… This approach would make hiding the Orphans tab happen by modifying whatever tiddler is transcluding the Orphans tab based on its own list condition (which used to be as simple as: show whatever has a certain tag and isn’t a draft).

So, I’d modify the relevant filter-line in $:/core/ui/SideBar/More to be something like:

tabsList="[all[shadows+tiddlers]tag[$:/tags/MoreSideBar]!has[draft.of]] - [enlist{!!hide-list}]"

What do you all think?

[Brian_Radspinner]

In my on-going (and slow) tweaking, I’ve stopped using the default Tabs macro in the Sidebar of my mail wiki. I made a custom setup that uses a List field instead of tags.

I have not bothered, yet, to create a smooth UI to add/remove/re-order tabs; I’m just manually editing the list field for now. But, it avoids editing Shadow tiddlers just to change tags. The list can be stored however I want.

If I can get real life nonsense to settle down, I want to get my current tabs alternative distributable. A decent UI for editing seems needed since there is now a single list that can be held nowhere near any of the tabs it holds, and not be as obvious to deal with than going to a tiddler and adding a tag.

[TW_Tones]

@Springer

I always feel weird about un-shadowing something just in order to change whether it displays in this or that place;

I do too, but if you hide a core or plugin provided sidebar tag by removing a tag you are doing this anyway.

• but I would not be too worried about modifying sidebar tabs tiddlers.

They key problem is the tabs macro works this way as @Brian_Radspinner discusses.

For sometime I have wanted to change the tabs macro and more such as toc, buttons, view and edit template items to query a display-filter field before displaying that tiddler, if and only if the field exists. Functionality we do not currently have.

If we want to ensure we do not ever have to overwrite a core tiddler for a configuration setting we, need an out of tiddler version of the display-filter.

• this is traditionally handled with a seperate system tiddler like the visibility tiddlers that includes the current tiddler title.
• this approach while effective proliferates small tiddlers but with long names.

Stratigic whitepaper follows

A you may of noticed I have a stratigic commitment to tiddlywiki and whilst it may seem I am complicating things to address this proliferation issue I have another solution I have thought long and hard about with other far reaching consequences.

• it took me a while to make this discovery, in part because we already have shadow tiddlers.
• my idea is to have one extra tiddler, if needed to store information about any tiddler and use the fields in that to store out of tiddler settings, be they shadows or tiddlers.
• My favorite name for such tiddlers is a ghost tiddler of the form $:/ghost/ tiddler name.
• in the above example of the display-filter field. If a tiddler has a ghost tiddler also containing a display-filter field that will be used instead.
  • once this mechanisium is available it could be used for many things. An exercise for your imagination for now.

I hope I did not bore anyone with my tiddlywiki obsession.

[markkerrigan]

I know my reply here is rather late too, but in my opinion this feature of the code is very powerful, but hard to understand.

The fact whether or not a tag is present, and what order the tagged tiddlers are listed in is a key concept / philosophy in TW.

It is true that you should not modify shadow tiddlers, you should clone them and tag them accordingly, that way you can safely assume it’s OK to delete the shadow tiddlers to refresh them to their default contents.