Preview Plugin Using New Features in TW 5.3.6

Is it possible to implement the preview plugin from Tobias Beer using the custom widget and redefining the Link widget in TW 5.3.6, without overwriting the core tiddlers?

1 Like

@Mohammad I am confident that would be possible. On reviewing plugins — docs for plugins by tobibeer I note it mentions a supporting plugin “appear” however it may be possible to now use native tiddlywiki instead.

I have previously worked with redefining the $link widget since custom widgets and and the $Genesis widget became available. Done correctly the preview functionality can be done on top of the link widget and still pass all parameters through to the core $link widget, thus not modifying the core.

I think it demands a rewrite and new implementation of a preview “wrapper” however there may be other implementations in the community.

  • I wonder if this is another opportunity to provision a more general solution “Information on Popup”, which includes preview (of tiddler text, fieldname, database entry etc…), which we can introduce to a $link widget override (the subject of this topic) but is available for other implementations and retriving the information.
    • In this case the list widget override would simply invoke the “Information on Popup” solution, and within that set the defaults for link preview.
    • However it can also be implemented elsewhere with different settings rather than on all links. Consider the idea of a wrapper that sets the parameters for “Information on Popup” on the content within including on links, and thus possibly override that set on all links. The wrapper may be as simple as a set of $let variables.

Some thoughts

This was my first thought as well, but overriding the link widget would only be required if something special needs to be done for rendering the link widget. However, the important functionality for the link preview is related to events and a delay timer. Those are not affected by rendering.

The plugin’s mouseover and mouseout event handlers cause a timer to be set and cleared. If the timer expires before being cleared, then the popup will be shown.

This means the eventcatcher widget is more likely to be helpful. This widget could be used to trigger an action widget whenever mouseover and mouseout events occur on any link widget.

One big question is how to implement the delay. I know @EricShulman has some timer tools that might help.

However, I wonder if the eventcatcher widget could be used with the transitionend event instead of with mouseover+moueout+timer tools. Define a :hover CSS class along with a transition duration. After the transition completes, the transitionend event will be fired and the action popup widget can be used to display the popup preview.

2 Likes

Yes, the event catcher is an option

I think it best however to avoid timer tools and use CSS to achive it.

One issue with the event catcher is where do you place it and how to you activate deactivate it, at present you will need a new page template or layout.

The timer etc… is arguably desirable but not essential.

1 Like

I don’t think it’s currently possible (though I’d love to be proven wrong), but I’ve thought before that it would be very convenient if you could set a global $eventcatcher that would wrap the page template, as you can do with a $set widget in a tiddler with the $:/tags/Global tag.

1 Like

I have tried that and similar code patterns to allow hackability using widgets wrapped around the page and other templates but not found one after many hours of hacking.

  • Perhaps it can be done with an alternat page template containing the wrapper, and a transclusion of the page template.
  • How could more than one hack wrap the page template?

Right, I think this is the current “best” solution. (I know @Yaisog, for instance, has done some work with alternate page templates that change the storyriver behavior.) But as you say…

This is the problem that often keeps me from adopting clever workarounds like this: each relies on its own customized page template, so if I want to use two or three at the same time I have to figure out how to splice them together anyway. I think that prospect is going to be a non-starter for most people. It’d be really nice to have the core support for adding global $eventcatchers… then you could ship them as part of a plugin without worrying too much about introducing conflicts.

1 Like

An alternative to the timer is an alt-mouse pointer event. Use alt to preview. Although both options are ideal. Without alt tyou can display the provided tooltip or “alt key to preview”.

The Link widget has a tooltip parameter, what if it also had a preview parameter, on we can supply a macro to? including a default config entry, then all link widget invocations (the default tiddler link) would use the preview which can contain conditions)

Using the genisis widget would allow us to demonstrate it and have the change implemented in the core. The preview may be the caption or description fields as well.

Link widget

data-*

New in v5.3.2 Optional data attributes to be assigned to the HTML element
style.*

New in v5.3.2 Optional CSS properties to be assigned to the HTML element

I think I never described how I’ve implemented this here on the forum. So here is a short summary:

In the PageTemplate, I added a $transclude widget around the innermost $list, to initiate a recursive transclusion of another tiddler, $:/mwi/DynamicContent.

<$transclude $tiddler="$:/mwi/DynamicContent" filter="[tag[$:/tags/DynamicPageTemplate]!has[draft.of]]">
	<$list filter="[all[shadows+tiddlers]tag[$:/tags/PageTemplate]!has[draft.of]]" variable="listItem">
		<$transclude tiddler=<<listItem>>/>
	</$list>
</$transclude> <!-- see https://github.com/Jermolene/TiddlyWiki5/pull/7340 -->

In the referenced PR, there is a lengthy discussion about how this should or should not be included in the core, which fizzled out about a year and half ago.
Anyway, the transcluded tiddler, $:/mwi/DynamicContent looks like this:

\parameters(filter,depth:1)
<$list filter="[subfilter<filter>nth<depth>]" emptyMessage="""<$slot $name="ts-raw" $depth={{{ [<depth>multiply[2]subtract[1]] }}} />""">
	<$transclude $tiddler=<<currentTiddler>>>
		<$transclude $tiddler="$:/mwi/DynamicContent" filter=<<filter>> depth={{{ [<depth>add[1]] }}} />
	</$transclude>
</$list>

This tiddler recursively transcludes itself, as well as another tiddler, for each item that matches the filter in the PageTemplate parameter – in this case it is any tiddler with the tag $:/tags/DynamicPageTemplate.
Here is one such tiddler that includes a $messagecatcher to intercept any tm-close-tiddler messages:

\whitespace trim
\procedure tm-close-tiddler-actions()
<$let targetTiddler={{{ [<event-param>!is[blank]else<event-tiddlerTitle>] }}}
	  visibleTiddler={{{ [<tv-history-list>get[current-tiddler]] }}}
	  history={{{ [<tv-history-list>get[text]] }}}>
	<!-- any actions go here -->
</$let>
\end

<$messagecatcher $tm-close-tiddler="<<tm-close-tiddler-actions>>" >
	<$slot $name=ts-raw />
</$messagecatcher>

Here is another one that adds two $eventcatchers for a context menu (one on the tiddler and any html tag that has a data-contextmenu attribute, and one on TiddlyLinks):

\whitespace trim
\import [[$:/mwi/ui/PageTemplate/ContextMenu/Macros]]

<$list filter="[{$:/mwi/config/ContextMenuEnable}match[yes]] :boolean:and[{$:/HistoryList!!current-tiddler}!is[draft]]" variable="void" emptyMessage="<$slot $name=ts-raw />">
    <$eventcatcher $contextmenu="<<contextmenu>>" selector=".tc-tiddler-frame, [data-contextmenu]" matchSelector=":not(a)" tag="div">
    <$eventcatcher $contextmenu="<<contextmenu>>" selector=".tc-tiddler-frame a.tc-tiddlylink-resolves" tag="div">
        <$slot $name=ts-raw />
    </$eventcatcher>
    </$eventcatcher>
</$list>

The contextmenu macro is imported at the top. I think I have described the context menu mechanism in more details somewhere else on this forum.

Hope this helps,
Yaisog

4 Likes

I have repacked the Tobias Beer plugins (Preview and Appear) in one single plugin Quick View and distributed with KPL (kookma plugin library). I am still eagerly following the works here, using wikitext solutions.

1 Like

Reference to other works:

Hey Mohammad,

Do you have a link to the Quick View distributed with KPL? I searched here for kookma plugin, and the link took me to a site that has the most recent tiddler as being from 2022.

Hi Dave,
Install the KPL from Kookma Library — Plugins for Tiddlywiki5 and then add it to your Wiki.

image

Here is some WIP code at the share site which doesn’t work yet, but shows the use of the css transitions and the event-catcher widget I mentioned before.

I don’t know when I’ll be able to get back to this so I thought I’d share what i have so far.

1 Like

Much appreciated. Thank you!

Hello @Mohammad,
this is a very nice plugin, I like it.

I’d like to see the preview tiddler only as long the mouse is on the preview tiddler.
How can that be achieved?

Thanks, Stefan

The current behavior is intentional.
It assumes you may hover over another link on the previewed tiddler.

You may hack the code!

As you can see the preview overlaps the rest of the list.
You have to click anywhere to close the preview window to be able to hover the next entry.

Yes, that is correct! You have to click outside the opened local window for preview.

I think the point here is that you can further hover the links within the hovered window and get secondary preview (and tertiary, and… .) This will only work if it stays up when you move off the current link.