TiddlyTools in-wiki Browser is super-useful

A comment …

Great stuff! The find:"[some_filter[on]]" I have been using today.
It is very useful!

TT

When the bookmarks and search popups are rendered, their content is determined by using [prefix<bookmarks_root>] (where <bookmarks_root> is hard-coded to $:/config/TiddlyTools/Bookmarks). So yes, they are “dynamically read by MiniBrowsers and you can safely move folders in and out”, simply by renaming them.

It even handles the case where you rename a bookmark folder that has children.

For example, on TiddlyTools.com I have the following bookmark tiddlers:

$:/config/TiddlyTools/Bookmarks
$:/config/TiddlyTools/Bookmarks/Music
$:/config/TiddlyTools/Bookmarks/TechTools
$:/config/TiddlyTools/Bookmarks/TiddlyWiki
$:/config/TiddlyTools/Bookmarks/TiddlyWiki/Examples
$:/config/TiddlyTools/Bookmarks/TiddlyWiki/Videos

Note that the “Tiddlywiki” folder contains 3 bookmarks, and has 2 child folders. When I view the bookmarks popup, it reports “TiddlyWiki (5)”. If I then rename $:/config/TiddlyTools/Bookmarks/TiddlyWiki to $:/ignore/TiddlyTools/Bookmarks/TiddlyWiki, the bookmarks popup then correctly shows “TiddlyWiki (2)”, because the child folders are still there. You can even still use the “edit folder” button to rename the missing “TiddlyWiki” folder, and it correctly renames the children without needing to actually have a “TiddlyWiki” parent folder!

-e

Hi @EricShulman

Is there a way that one can zoom in on the content of the iframe using the mouse wheel?

As a general rule, events that occur within the bounds of the rendered iframe are sent directly to the iframe. This includes mouse events like click, dblclick drag, and wheel. This is what allows you to interact with the iframe independent of the containing parent.

There are just a few exceptions:

  • some of the right-click popup menu actions apply to the iframe content (e.g., right-click in an input field to paste text), while others apply to the containing parent (e.g., right-click to print)
  • ctrl-wheel (and keyboard ctrl-plus,ctrl-minus) zooms in/out of the entire parent content

Note: I have experimented with using a separate $range widget to control the iframe’s zoom CSS (which defaults to zoom:0.5) so it IS possible to implement an iframe “zoom in” feature… just not with the mouse wheel.

-e

Thanks for that explanation @EricShulman .

The reason for asking is that I looking at a site whose width is much less than the width of the iframe, hence the text is very small.

I can zoom into the browser window using the mouse wheel in Firefox but that is not ideal.

Anyway thanks for you help.

I’ve just updated TiddlyTools/Panels/Browser to add a $range widget to control the iframe’s zoom CSS. The initial (and minimum) zoom value is 0.5 (as it was before), and the zoom value increments by 0.25, with a maximum value of 5.

Note that, if you are viewing a site that automatically sets the input focus (such as TiddlyWiki.com, which sets the initial input focus to the sidebar search input control), then the minibrower’s zoom control will lose focus each time the zoom value changes (which triggers a redraw of the iframe contents). As a result, changing the zoom setting via keyboard input (i.e., arrow keys, pgup/pgdn, home/end) only works for a single keypress at a time. However, if the viewed site does NOT set the initial input focus, then keyboard input to the minibrowser’s zoom control works just fine.

enjoy,
-e

1 Like

I’ve just made an Important update to TiddlyTools/Panels/Browser that affects embedded browser-in-browser usage:

Instead of using \import and a macro call with parameters:

\import TiddlyTools/Panels/Browser
<<showPanel width:"..." height:"..." find="..." etc>>

you should now use variables with transclusion, like this:

<$let width="..." height="..." find="..." etc>
{{TiddlyTools/Panels/Browser}}

This new syntax provides much greater flexibility for using computed values and also simplifies the internal <<showPanel>> macro code, which no longer needs to “unpack” macro parameters.

See TiddlyTools/Panels/Browser/Help for more info.

@TiddlyTitch … this will undoubtedly impact your current usage, but is relatively easy to apply… sorry for the inconvenience :slight_smile:

-e

1 Like

No problem. Didn’t take long to convert.

There is a lot of new really good functionality!

I’ll comment when I have used it a bit more.

TT

@EricShulman, I have a few comments on the great expansion of functions!
A couple on the new docs.
And one problem.
I’ll start with the problem to get it out of the way.

Q10: Does the tool support Local Addressing?

Background: In past I used iframes fine in TW to load Local files. Here is a snip of address starts I’d hoped to use in the miniBrowser …

Unfortunately they don’t seem to work.

Hope this isn’t a big issue!

TT

Just a comment

Definitely makes bespoke stuff easier to construct. For instance, I created a miniBrowser just for editing v. long URL’s …

… using …

<$let width="100%" height="calc(100dvh - 3em)" name="bmk-edit" folders="$:/config/TiddlyTools/Bookmarks" find="" zoom="1">
 <span class="tt-br-title"><small>//''Bookmarks Edit''// --- </small>`$:/config/TiddlyTools/Bookmarks` &nbsp;</span>
 <span class="tt-bmk-edit">{{TiddlyTools/Panels/Browser}}</span>
</$let>
<style>
/* enable display: empty */
 .tt-bmk-edit .tc-droppable {display:none;} 

etc ...

TT

It was a one-line change.

This line in setURL():

<$let url={{{ [<url>!prefix[http]addprefix[https://]] ~[<url>] }}}>

is now:

<$let url={{{ [<url>!regexp[^(http|\./|\.\./|file:)]addprefix[https://]] ~[<url>] }}}>

-e

Note that, when using variables to customize the TiddlyTools Browser, you only need to specify the non-default values. Thus, the following would have been sufficient:

<$let height="calc(100dvh - 3em)" name="bmk-edit" zoom="1">
...

-e

Great! Now my sidebar has a file browser …

Screenshot 2025-12-28 18.02.25

… and a specialized, framed, TW image editor (live) …

Thanks!
TT

Comments on docs …

Overall: Clear and to the point!
Anyone interested in the full potential of TiddlyTools miniBrowsers should read it.

Small issues.

#1: Doesn’t the example need a closing “</$let>”? Wondering…

#2: In the various options I don’t see extlink="+" variants listed.
Is, for instance, this still valid? …

Best
TT

Comment on Bookmark folders=""

That is great! For instance using code like this …

folders="$:/config/TiddlyTools/bkm/inbox"

… means one can (1) define the bookmarks that a specific miniBrowser uses; (2) makes bookmark management a lot easier.

In my case a thousand bookmarks became much easier to maintain.

TT

Comment #1 on zoom=""

Very useful to able to set starting zoom levels differently in different miniBrowsers!

For instance on my moderate size Chromebook zoom=".5" is okay to see some websites, but too small text for serious reading.

I did some testing and found that tiddlywiki.com renders fine and readable set like this …

<$let name="tw-stuff" zoom=".75">

Here it is in the Sidebar where I consult it …

In short, the custom zoom setting is great for adapting the tool for different working environments.

TT

I had removed the extlink option to reduce code size, but since you’ve asked about it, I’ve now restored support for it (and added it to the documentation).

re: a closing </$let>… technically, this is not required since it will be automatically closed at the end of the tiddler. Nonetheless, I’ve added it into the documentation to avoid any confusion.

-e

Thanks! That is very helpful because I found I needed two types of external link. One that goes to _blank and one that goes to a unique-tab. Having more than one extlink suffix let’s me do that!

TT

Comment #2 on the zoom="<n>" new Slider

I dunno how to successfully describe the good and the not so good on the new Zoom Slider without getting in an explanatory pickle.
I’ll try. But please ask if it is unclear.

Two points to start …

  1. Customizable zoom is great!
  1. All my comments are coming from the “fat-finger situation” of a modest screened Chromebook with no pen or keyboard.

My needs on zooming?
Based on tests so far, for my environment …

  1. For NORMAL use I’m finding that ".5" ".75" & "1" work to cover most all use cases

A button to toggle between those three might work better for me than a range slider?

  1. For SPECIAL use, for instance as an adjunctive to Visual Art analysis already possible at the UK National Gallery

Here a range slider could add to that site’s existing zoom feature. But in a fat-finger environment it would probably need to be long & look like this … ??

What am I saying?

  • For (my) normal use I need no more than 3 zoom levels and a slider in a “smaller screen fat-finger situation” seems over ui’d.
    I’d prefer a toggle. Dunno!

  • For my special interests in visual art a big slider could be useful.

I hope this is clear enough to convey enough UI sense!
TT

I’ve just added handling for setting a zoom="min,max,step" variable to control the $range slider.

The default range is unchanged (i.e., zoom="0.5,5,0.25"), and the “,max,step” portion of the variable’s value can be omitted (e.g., zoom="1" is the same as zoom="1,5,0.25"). For your “NORMAL” usage, specify zoom="0.5,1"

The $range slider has class=tt-browser-zoom, so you can change its size (which defaults to width:5em) using custom CSS. For example:

<style>.my-art-browser .tt-browser-zoom { width:100% !important; }</style>
<$let zoom="1,10,1">
@@.my-art-browser {{TiddlyTools/Panels/Browser}}

and if, for some use-case, you want to a constant zoom value (e.g., zoom="2") you can, of course, hide the $range slider using:

<style>.my-special-browser .tt-browser-zoom { display:none; }</style>
<$let zoom="2">
@@.my-special-browser {{TiddlyTools/Panels/Browser}}

enjoy,
-e