Feature Request: Sidebar tab hiding as a built-in option

[Evan Balster]

I often use TiddlyWiki to create documentation which is used by other people.  It's useful to create a helper tab or two for browsing those wikis or calling up commonly-used information -- but adding those to the four default tabs makes for a rather complicated-looking sidebar.

For the sake of those readers, I like to simplify my wiki slightly by relocating those sidebar tabs which are mainly useful for editing (that is, "Recent", "Tools" and "More") to a "wiki" tab.  Attached is a screenshot of this scheme.

I don't mind making this customization, but it does complicate upgrading my wiki and it feels like something that could be a core feature.  Given that adding sidebar tabs is a beginner-level customization which does not interfere with upgrading, it seems appropriate that hiding or "collapsing" some of the built-in ones as I have might be similarly facilitated.

[PMario]

Hi Evan,
 
As you found out, if a tiddler is tagged: $:/tags/SideBar, it is shown in the right sidebar.

So if you open the tiddler $:/tags/SideBar and open the tiddler info (i) and the "tagging" tab you can see:

$:/core/ui/SideBar/Open

TableOfContents

$:/core/ui/SideBar/Recent

$:/core/ui/SideBar/Tools

$:/core/ui/SideBar/More

So if you open eg: $:/core/ui/SideBar/More and remove the tag, it is removed from the list.

hope that helps
-mario

[Danielo Rodríguez]

But Mario,

Then you are editing a shadow tiddler, which is exactly what he wants to avoid in order to properly upgrade to newer versions easily.

I think it makes sense because as he says, customizing such part of the UI should be newbie friendly

[PMario]

On Thursday, September 10, 2015 at 11:20:23 PM UTC+2, Danielo Rodríguez wrote:

But Mario,

Then you are editing a shadow tiddler, which is exactly what he wants to avoid in order to properly upgrade to newer versions easily.

Yea, we can make everything configurable. So every shadow tiddler can get its "visibility tiddler" and then we add a new configuration tiddler that can activate and deactivate those visibility tiddlers. ... and so on ...

IMO at some point we need to start, to overwrite shadow tiddlers and be responsible for our personalised version. Not everything will and can be made configurable. I personally remove lists from templates to make them fast and mobile friendly again. At the moment TW is configured to death already.

Just my opinion.

mario

[Mat]

@Evan - I'm not sure if you're asking for help or merely pointing out that it ought to be a core feature to modify this easily.

In case of the former, I made "the PublicSidebar" shortly ago that might be of help.

Regarding the latter, I agree.

<:-)

[Evan Balster]

For the record, I'm quite comfortable making the customization -- I just feel as if this functionality is useful frequently enough that it shouldn't require surgery on TiddlyWiki's core.

[PMario]

On Friday, September 11, 2015 at 2:16:43 AM UTC+2, Evan Balster wrote:

For the record, I'm quite comfortable making the customization -- I just feel as if this functionality is useful frequently enough that it shouldn't require surgery on TiddlyWiki's core.

 

You are right but I think this could be done with themes too. It would only need to switch a button to change to a different theme. Just someone would need to create one.

-m

[Mat]

On Friday, September 11, 2015 at 2:50:21 AM UTC+2, PMario wrote:

 Just someone would need to create one.

And the theme would have to be found when people need it, be it via tw.com or somehow elsewhere. IMO this is the trickier bottleneck than making the theme.

<:-)

[Evan Balster]

I'm not sure if requiring a theme installed is sensible...

I feel as if the closest UX analog is the "toolbars" setting.  You don't need a special-purpose theme to enable or disable the "clone" button on all tiddlers, or to conceal the "new tiddler" button in the sidebar.

[PMario]

On Friday, September 11, 2015 at 4:17:05 AM UTC+2, Evan Balster wrote:

I'm not sure if requiring a theme installed is sensible...

I feel as if the closest UX analog is the "toolbars" setting.  You don't need a special-purpose theme to enable or disable the "clone" button on all tiddlers, or to conceal the "new tiddler" button in the sidebar.

I know but if you have a look at empty.html. It has already 1218 shadow tiddlers. Many of them come for UI configuration. We should try to remove them and not make them more. The whole confi stuff makes TW terribly slow.

just my 2 cents.
-m

[Mat]

PMario wrote:

I know but if you have a look at empty.html. It has already 1218 shadow tiddlers. Many of them come for UI configuration. We should try to remove them and not make them more. The whole confi stuff makes TW terribly slow. 

@anyone who knows or has thoughts about it;

If (if) one wanted to make a pull request to split out - just as a concrete example - the "New journal" and "New journal here" features, and provide them as a plugin instead, how would one go about this? Are the interfaces defined (not UI, I mean code-to-code)? Do all e.g "tools" (buttons) have the same interface parameters? 

I used toolbuttons as an example, is there much difference for other features? Can the various components be categorized/segregated based on characteristics and how easily they'd be externalized? Are there any established such categories?

Would pluggifying e.g tools mean that if they were then plugged in so that the resulting TW appears just like the current unmodified version, then we'd get an even bigger file than the current unmodified because plugins presumably also carry some extra stuff, or is this very marginal?

Thanks!

<:-)

[Danielo Rodríguez]

Interesting ideas Mat. I have no idea what to answer, but a totally modular tiddlywiky is something I dream about

[PMario]

On Friday, September 11, 2015 at 3:09:56 PM UTC+2, Mat wrote:

PMario wrote:

I know but if you have a look at empty.html. It has already 1218 shadow tiddlers. Many of them come for UI configuration. We should try to remove them and not make them more. The whole confi stuff makes TW terribly slow. 

@anyone who knows or has thoughts about it;

If (if) one wanted to make a pull request to split out - just as a concrete example - the "New journal" and "New journal here" features, and provide them as a plugin instead, how would one go about this? Are the interfaces defined (not UI, I mean code-to-code)? Do all e.g "tools" (buttons) have the same interface parameters? 

There are quite a lot of dependencies atm. All the existing buttons are also translated. So moving those tiddlers to plugins imo would drive the translators crazy.

btw: The extensive use of the <$list > plugin in TW templates, is what makes it slow. Those lists where implemented to make TW more configurable. IMO with a nasty blowback.

-m

[Jeremy Ruston]

Great thread. There's a bunch of points I'd like to respond to:

Firstly, to respond to Evan's original request, I also think that the sidebar tabs should be selectable just like the toolbar icons.

Mario expresses several concerns:

> At the moment TW is configured to death already. 

My goal is to make TiddlyWiki flexible and useful for people who aren't yet ready to delve into wikitext and deep customisation. I try to make a call about which customisations should have a user interface based both on the norms of other applications (themes, palettes, language etc) and the discussions in the community. (A good example is the recent addition of a UI for disabling camelcase in response to persistent feedback that it was wanted).

> if you have a look at empty.html. It has already 1218 shadow tiddlers

In my experience, the number of shadow tiddlers alone doesn't have as much impact on performance as one might think. As Mario notes elsewhere, the issue is really around optimising the performance of the various list traversals used in the UI.

Then there are these points from Mat:

> If (if) one wanted to make a pull request to split out - just as a concrete example - the "New journal" and "New journal here" features, and provide them as a plugin instead, how would one go about this?

Rather than replacing the current buttons I'd be inclined to create new buttons, and have the plugin provide shadow tiddlers that hides the original ones by default (the user could always override their visibility if they wanted them back).

> Are the interfaces defined (not UI, I mean code-to-code)? Do all e.g "tools" (buttons) have the same interface parameters? 

A button is just a transcluded tiddler. Here's the "home" button:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/ui/PageControls/home.tid

It basically boils down to <$button message="tm-home">, with additional complexity to handle tooltips, and optionally showing icon vs. text.

In the case of tiddler toolbar buttons, the current tiddler is set to the tiddler that is being operated on.

> I used toolbuttons as an example, is there much difference for other features? Can the various components be categorized/segregated based on characteristics and how easily they'd be externalized? Are there any established such categories?

I'm not sure how you'd measure how easily they'd be externalised. Are you really asking whether chunks of the TiddlyWiki UI can be made into plugins so that people can choose a faster but less configurable UI?

Rather than chunking the existing UI, I'd be more inclined to replace it: to replace the page template itself, and build up a new UI, grafting in bits of the core where they're needed. Switchable page templates is something I'd be interested in adding to support the people who want to build custom UIs for their users while using the TW coreUI for themselves.

Unused shadow tiddlers would be left in the core, but they wouldn't have much impact on performance.

> Would pluggifying e.g tools mean that if they were then plugged in so that the resulting TW appears just like the current unmodified version, then we'd get an even bigger file than the current unmodified because plugins presumably also carry some extra stuff, or is this very marginal?

There may well be bits of the core that might/should be split off into separate plugins, but I think that should be done based on their bulk/size rather than performance impact.

Finally, Danielo says:

> a totally modular tiddlywiky is something I dream about

You've said something similar before, and I'm interested to make sure that I understand what you mean precisely. TiddlyWiki is already ridiculously modular in the sense of everything being a separate tiddler, but I think you mean that you want to be able to be selective about what parts of the core are included in a particular wiki, is that right?

Best wishes

Jeremy.

On Fri, Sep 11, 2015 at 2:51 PM, Danielo Rodríguez <rdan...@gmail.com> wrote:

Interesting ideas Mat. I have no idea what to answer, but a totally modular tiddlywiky is something I dream about

--
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 tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2e86146e-671b-44c4-ac8a-77ebcbb975c0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[Evan Balster]

Thanks Jeremy!

[PMario]

On Friday, September 11, 2015 at 5:28:32 PM UTC+2, Jeremy Ruston wrote:

Mario expresses several concerns:

> At the moment TW is configured to death already. 

My goal is to make TiddlyWiki flexible and useful for people who aren't yet ready to delve into wikitext and deep customisation.

Agreed!
 

I try to make a call about which customisations should have a user interface based both on the norms of other applications (themes, palettes, language etc) and the discussions in the community. (A good example is the recent addition of a UI for disabling camelcase in response to persistent feedback that it was wanted).

I'm fine, if we add new configurations to the core... if - and only if good arguments speak for them and if it adds real value for new users. ... From my point of view, the sidebar is an essential part of the page layout, which should be handled by a new theme. So may be we don't need to "disable" existing tabs. May be it's enough to enable "customized" tabs. So no need to overwrite shadow tiddlers -> no problem for updating.

----------

If someone requests new functionality, please think about, that there may be a lot of translation work needed too. If we have new variables, that enable and disable sidebar tabs, we need a new configuration page and all the translations need to be updated. This isn't rocket science, but somebody needs to do it. ... That's why I like to discuss these types of changes first. :)

have fun!
mario

[Graeme Henson]

Jumping off of this recent post since it's semi-related, How would you go about hiding the entire Sidebar itself by default? I've been googling around trying to find some method for it using plug-ins and such, but I can't tell if it's older code that doesn't apply or if I'm entering in the information wrong. Is there a ShadowTiddler somewhere where I can toggle this on-off?

[Eric Shulman]

On Friday, September 11, 2015 at 1:45:12 PM UTC-7, Graeme Henson wrote:

Jumping off of this recent post since it's semi-related, How would you go about hiding the entire Sidebar itself by default? I've been googling around trying to find some method for it using plug-ins and such, but I can't tell if it's older code that doesn't apply or if I'm entering in the information wrong. Is there a ShadowTiddler somewhere where I can toggle this on-off?

The current state of the sidebar is stored in a tiddler [[$:/state/sidebar]].  This tiddler is saved with the document, so if you close the sidebar, and then save the document with the sidebar closed, it will still be closed when you reload the document later.  However, closing the sidebar hides the "save changes" button, so saving with the sidebar closed is problematic.  To work around this, you can add the save button directly to the "TopRightBar" in the page layout, so that it will still be available after closing the sidebar.

1) create a new tiddler (e.g., [[ShowSaveWikiButton]])

2) Enter the following content:

   {{$:/core/ui/Buttons/save-wiki}}

3) tag it with "$:/tags/TopRightBar"

This will cause the "save changes" button to be displayed in the upper right corner of the page (right next to the sidebar toggle button).  You can then proceed to close the sidebar and click the save button.  Q.E.D. 

enjoy,

-e

Eric Shulman

ELS Design Studios

TiddlyTools - "Small Tools for Big Ideas!"

InsideTiddlyWiki: The Missing Manuals

YOUR DONATIONS ARE VERY IMPORTANT!

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[Graeme Henson]

That's an amazingly simple solution after how much I've been googling to find the something using all sorts of plug-ins and workarounds and such. I think I was expecting something more like a start-up script that just ran whenever the file opened up or changed a default setting somewhere, but whatever works. Thanks!

[Tobias Beer]

Hi Mario,

 

Yea, we can make everything configurable. So every shadow tiddler can get its "visibility tiddler" and then we add a new configuration tiddler that can activate and deactivate those visibility tiddlers. ... and so on ...

It does not require that, if (something like) this got implemented:

#1940 global config override

— tb

[Matabele]

Hi

Place this code into a tiddler:

\define getSideTabs()
<$button tooltip="List SideBar Tabs">
<$action-setfield $tiddler="$:/core/ui/SideBar/More" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/core/ui/SideBar/Tools" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/core/ui/SideBar/Recent" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/core/ui/SideBar/Open" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="TableOfContents" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/AdvancedSearch" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/AdvancedSearch" $field="caption" $value="Search"/>
{{$:/core/images/new-button}}
</$button>


\end


<table>
<tr><th>Toggle Sidebar Tabs</th><th><<getSideTabs>></th></tr>
<$list filter="[field:side-bar[tabs]!has[draft.of]]">
<tr><td><$view tiddler={{!!title}} field="title"/></td><td><span title="Toggle Tab"><$checkbox tiddler={{!!title}} tag="$:/tags/SideBar"/></span></td></tr>
</$list>
</table>

Click the + button -- the sidebar tabs can then be toggled.

If you wish to move these tabs elsewhere (rather than hiding them) -- you will need to append the necessary extra code.

regards

[Tobias Beer]

Hi Metabele,

For what purpose would you be setting a side-bar field?

Best wishes,

— tb

[Evan Balster]

Chiming in to say that this does not avert the "trivial upgrading" problem.

Regards,
Evan

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/dQbt-JFdRR8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/d8c643de-3baa-449f-ad1f-3fb0cf18b466%40googlegroups.com.

[Matabele]

Hi Tobias

The purpose of the 'side-bar' field is to list the tabs -- using the '$:/tag/SideBar' only works for active tabs -- once hidden (by deleting this tag), the tab can't be listed using this tag.

regards

[Matabele]

Hi

Here is a complete solution:

1. Paste this code into a New Tiddler, rename it to whatever you wish, and save (or download the attached .tid file.)

\define getSideTabs()
<$button tooltip="List SideBar Tabs">
<$action-setfield $tiddler="$:/core/ui/SideBar/More" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/core/ui/SideBar/Tools" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/core/ui/SideBar/Recent" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/core/ui/SideBar/Open" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="TableOfContents" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/AdvancedSearch" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/AdvancedSearch" $field="caption" $value="Search"/>

<$action-setfield $tiddler="$:/_SideBar/Wiki" $field="side-bar" $value="tabs"/>
<$action-setfield $tiddler="$:/_SideBar/Wiki" $field="caption" $value="Wiki"/>
<$action-setfield $tiddler="$:/_SideBar/Wiki" $field="text" $value="""
<div class="tc-more-sidebar">
<<tabs "[all[shadows+tiddlers]tag[$:/tags/WikiSideBar]!has[draft.of]]" "$:/core/ui/SideBar/More" "$:/state/tab/wikisidebar" "tc-vertical">>
</div>
"""/>

{{$:/core/images/new-button}}
</$button>
\end




<table>
<tr><th>Toggle Sidebar Tabs</th><th><<getSideTabs>></th></tr>
<$list filter="[field:side-bar[tabs]!has[draft.of]]">
<tr><td><$view tiddler={{!!title}} field="title"/></td><td><span title="Toggle Tab"><$checkbox tiddler={{!!title}} tag="$:/tags/SideBar"/></span></td></tr>
<

/$list>
<tr><th>Toggle ~WikiSidebar Tabs</th><th></th></tr>
<$list filter="[field:side-bar[tabs]!has[draft.of]![$:/_SideBar/Wiki]]">
<tr><td><$view tiddler={{!!title}} field="title"/></td><td><span title="Toggle Tab"><$checkbox tiddler={{!!title}} tag="$:/tags/WikiSideBar"/></span></td></tr>
</$list>
</table>

2. Click the large '+' button to prepare your tabs

3. Check/Uncheck the various tabs to have them appear according to your preferences

regards

On Thursday, 10 September 2015 20:48:31 UTC+2, Evan Balster wrote:

[Matabele]

Hi Evan

The solution in the previous post makes upgrading fairly trivial, provided that the names of the sidebar tabs or system tags involved are not changed in the new version (the code can change.)

Simply add this tiddler to your new wiki, and prepare the tabs by clicking the large '+' button. If you have are upgrading an old wiki -- deselect the modified system tiddlers during the upgrade, then click the large '+' button to prepare the upgraded system tiddlers.

regards

On Thursday, 10 September 2015 20:48:31 UTC+2, Evan Balster wrote:

[Tobias Beer]

Hi Metabele,

 

The purpose of the 'side-bar' field is to list the tabs -- using the '$:/tag/SideBar' only works for active tabs -- once hidden (by deleting this tag), the tab can't be listed using this tag.

I see. Starting from your table, I went about it slightly differently and also included the More sidebar...

Toggling And Moving Sidebar-Tabs @ tb5

I think that's a useful thing, because the first thing I often do is put the Tools into More.

Best wishes,

— tb 

[Matabele]

Hi Tobias

That looks to be useful. The reason I opted for a custom field for the filter (as I recall) -- was to include custom tabs in the toggle listings. For standard tabs, your filter method appears neater (avoiding the necessity of overwriting system tiddlers unnecessarily.) With the addition of the 'prefix{!!custom}' filter, looks to cover all bases.

regards

[Matabele]

Hi

I have attached my latest version of a Sidebar/config tool. Drag and drop the downloaded .tid file to your TW5 -- click the large + sign to prepare your tabs -- toggle the tabs to arrange your sidebar (take care not to include a tab within itself!)

[Tobias Beer]

Hi Metabele,

 

I have attached my latest version of a Sidebar/config tool. Drag and drop the downloaded .tid file to your TW5 -- click the large + sign to prepare your tabs -- toggle the tabs to arrange your sidebar (take care not to include a tab within itself!)

What's that "wiki" column and also what needs preparing via the "+" button? (Perhaps add a little info in the tiddler what it all means).

Best wishes,

— tb

[Matabele]

Hi Tobias

Have a look at the screenshot attached to the post at the top of this thread -- the original request referred to moving some of the sidebar tabs into a 'Wiki' tab. I found the idea useful, as this allows separation of tabs into: often used(sidebar tabs)/commonly used(wiki tabs)/sometimes used(more tabs.)

The button creates the Wiki tab, the Advanced search tab, and prepares the custom tabs for listing (I have used a field again instead of a prefix -- a preference acquired some time ago, using the beta editions of TW5.)

I might expand on this idea sometime (to ease the process of creating and editing sidebar tabs) -- something like the functionality of the left tabs here (written some time ago when TW5 was less capable) : http://gtab.tiddlyspot.com

regards

[Tobias Beer]

Ah, of course, now I see... good point.

I have also updated the tab-manager-thingy at tb5

and separated code from customization...

Toggling And Moving Sidebar-Tabs @ tb5

Now there is...

• $:/.tb/config/sidebar-tabs
  
• the tab manager thingy (and its code)
• $:/.tb/config/sidebar-tabs/custom
• an optional tiddler for customizations
• its text specifies a custom namespace under which to look for user-created tabs
  
• the fields more and more-tag now allow to specify a column head and the corresponding tag for the colum
  
• so you can model a Wiki column
  

Best wishes,

— tb

[Steven Schneider]

Hi Eric et al,

Thanks for this suggestion, works really well.  For what it is worth, I modified it a bit by *not* tagging [[ShowSaveWikiButton]] with TopRightBar. My workflow then becomes: (1) open the ShowSaveWikiButton tiddler (2) close the sideba (3) save the wiki and (4) reload to test. Doing this, I don't have a save button in my TopRightMenu, which I don't want, and my TW opens with the sidebar closed, which I do want.

However - this is annoying! I don't want to think about how I want my TW to look when I close/save it (as if I ever actually close it on purpose). How can the default view of TW be set to that sidebar is closed? Can't be difficult or impossible.

Along these lines: How can I have the TW behave differently, depending if it is called using http:// (thus, by a reader) or using file:/// (thus, by an editor or writer)? I'd like to provide entirely different interfaces (i.e. Themes) to satisfy these two very different audiences.

Thanks!

//steve.

On Friday, September 11, 2015 at 4:53:56 PM UTC-4, Eric Shulman wrote:

[Tobias Beer]

Hi steve,

After having replied to Frd and then reading this, I just added...

Hiding The Sidebar On Startup @ tb5

Perhaps that helps.

Best wishes,

— tb

[StevenM Schneider]

Yes, Tobias, that works great! Thanks so much. //steve.