Implementing a contextmenu with wikitext

@saqimtiaz: I noticed that one cannot call the context menu on another item when a context menu is already open – instead the second right-click just closes the existing popup and one has to click again (same was true for the Streams context menu when I checked).

So I put an $action-popup without the $coords attribute, to close all open popups, before the actual $action-popup call. This sort of worked, except that the second popup appears at the same location where the first was, but not where the second right-click occured. The text in the $state tiddler does update to the new coordinates, just the popup doesn’t move. Is this the intended behavior?

I also tried manually deleting the state tiddler before calling $action-popup, but that didn’t help.

I solved the problem – a bit too hacky for my taste, though – by using a different state tiddler for each right-click (adding the current now value to its title). The associated $reveal will look for all matching state tiddlers and use the one with the newest time code in the title. Seems to work reliably.

Have a nice day
Yaisog

@Yaisog You are on the right track. This is a problem that I resolved in the refactor of Streams that I have been working on and is close to release.

The key is to have the actions in this order:

  • close popup
  • set state tiddlers
  • open popup

That almost worked.

For some reason, the popup position does not update when you right-click on the same event target, but at a different location (e.g. end or beginning of the same link or, more common, different points in a tiddler for a tiddler context menu). This may not be relevant for Streams, where you attach the context menu only to the tiny list item markers, but would definitely drive me crazy at some point in my wiki…

So I’ll stay with the unique state tiddlers for now.

Have a nice day
Yaisog

No reason to change what works for you if you are happy with it. However, you might find the updatePopupPosition attribute of the $reveal widget relevant here.

You really do know all

Alrighty, after spending a few days fiddling with context menus (and definitely too much time playing around with CSS transition effects that were ultimately scrapped), I’m in a spot where I’m quite happy with how they turned out. After some refactoring there is not much code to it, and I even got submenus to work.

The $eventcatcher and macro are pretty much as above.

The template for the popup also is not very complicated and mostly sets all the passed variables:

\whitespace trim

<$let stateTiddlerBase="$:/state/popup/contextmenu"
			contextmenu={{{ [<stateTiddlerBase>addsuffix[/dom-data-contextmenu]get[text]else[Tiddler]] }}}
			contextmenutiddler={{{ [<stateTiddlerBase>addsuffix[/dom-data-contextmenutiddler]get[text]] }}}
			menuItemsTag={{{ [[$:/mwi/tags/ContextMenu]addsuffix<contextmenu>] }}}
			auxData={{{ [<stateTiddlerBase>addsuffix[/dom-data-contextmenuaux]get[text]] }}}
			parentTiddler={{{ [<stateTiddlerBase>addsuffix[/dom-data-contextmenuparent]get[text]] }}}
			tv-config-toolbar-text="yes" >
	<$reveal type="popup" state=<<stateTiddlerBase>> updatePopupPosition="yes">
		<div class="tc-drop-down mwi-contextmenu">
			<$tiddler tiddler=<<contextmenutiddler>> >
				<$reveal tag="button" class="tc-btn-invisible mwi-contextmenu-heading" type="nomatch" text="TOCItem" default=<<contextmenu>> >
					<span class="tc-btn-text">
						<$text text=<<currentTiddler>> />
					</span>
				</$reveal>
				<$list filter="[all[shadows+tiddlers]tag<menuItemsTag>!has[draft.of]]" variable="listItem">
					<$transclude tiddler=<<listItem>>/>
				</$list>
			</$tiddler>
		</div>
	</$reveal>
</$let>

The identifier passed from the DOM attribute data-contextmenu via a state tiddler into the variable contextmenu is used to build the tag name menuItemsTag which controls which buttons appear in the context menu for that identifier.
The buttons don’t have to be very complicated, e.g. an edit-button:

\define button-actions()
<!-- wenn Tiddler nur transcluded ist, muss er erst geöffnet werden -->
<$list filter="[<parentTiddler>!is[blank]]" variable="void">
	<$list filter="[<tv-story-list>!contains<currentTiddler>]" variable="void">
		<$action-listops $tiddler=<<tv-story-list>> $subfilter="+[insertbefore:parentTiddler<currentTiddler>move<currentTiddler>]"/>
	</$list>
	<$action-navigate />
</$list>
<$action-sendmessage $message="tm-edit-tiddler" />
\end

<$button class="tc-btn-invisible mwi-btn-meta-toolbar" actions=<<button-actions>> >
	{{$:/core/images/edit-button}}
	<$list filter="[<tv-config-toolbar-text>match[yes]]">
		<span class="tc-btn-text">
			Tiddler bearbeiten
		</span>
	</$list>
</$button>

Most of the buttons do somewhat more complicated actions unique to this wiki. But, they were already implemented and their buttons were littered around the UI. All it took (mostly) was to assign them the respective tag(s).

If there are relevant tiddlers higher up in the hierarchy, a submenu for those is also shown, implemented as just another context menu button with the respective tag:

<!-- wenn es einen parentTiddler gibt, zeigen wir das Menü für den Haupt-Tiddler an (wenn wir nicht schon in einem Untermenüpunkt sind) -->
<$reveal type="nomatch" text="2" default=<<menuLevel>> tag="button" class="tc-btn-invisible">
	<$tiddler tiddler={{$:/HistoryList!!current-tiddler}} >
		<$let parentTiddler=""
					contextmenu="Tiddler"
					menuItemsTag={{{ [[$:/mwi/tags/ContextMenu]addsuffix<contextmenu>] }}}
					menuLevel="2" >
			{{$:/mwi/images/escalator-warning}}
			<span class="tc-btn-text">
				<$text text=<<currentTiddler>> />
			</span>
			<span class="mwi-hotkey">
				{{$:/core/images/right-arrow}}
			</span>
			<div class="mwi-contextsubmenu">
				<$list filter="[all[shadows+tiddlers]tag<menuItemsTag>!has[draft.of]]" variable="listItem">
					<$transclude tiddler=<<listItem>>/>
				</$list>
			</div>
		</$let>
	</$tiddler>
</$reveal>

To complete the UI cleanup, I will consider if it makes sense to move the whole View Toolbar into the context menu (except for the Close button). Some of it is already there, and the rest is rarely used.

Maybe this will inspire someone to try their own hand at crafting a bespoke context menu (except maybe for @saqimtiaz who probably does stuff like this before breakfast).

Have a nice day
Yaisog

PS: Sorry for all the German text. I don’t have the time right now for a translation. Pretty much all of it should not be relevant to understand the principle of the thing.
PPS: The submenus maybe only make sense when considering the general tiddler structure in the wiki: A major topic can have a tabbed table of contents, and each of those TOC entries may have a list of journal tiddlers which are collected together in a nested tabbed TOC. So, a journal tiddler may have a parent that is a contents pane of a toc-tabbed, which again then has a parent tiddler that is the root tiddler of the zoomin view. Nothing for small screens, but very efficient for finding information quickly.

9 Likes

@Yaisog it is extremely pleasing to see your explorations with wikitext and thank you for sharing back with the wider community. A bit of a crunch week for me at the moment but I’ll reply in more detail when the opportunity allows.

2 Likes

Turns out, adding the View Toolbar to the context menu is very simple. It is just another “button” with a submenu, just a few lines of code changed from what I posted above:

\import [[$:/core/ui/ViewTemplate]]
<!-- import is needed for the macros defined there -->
<$reveal type="nomatch" text="2" default=<<menuLevel>> tag="button" class="tc-btn-invisible">
	<$tiddler tiddler={{$:/HistoryList!!current-tiddler}} >
		<$let menuLevel="2" >
			{{$:/core/images/options-button}}
			<span class="tc-btn-text">
				Toolbar Buttons
			</span>
			<span class="mwi-hotkey">
				{{$:/core/images/right-arrow}}
			</span>
			<div class="mwi-contextsubmenu">
				<$list filter="[all[shadows+tiddlers]tag[$:/tags/ViewToolbar]!has[draft.of]] -[[$:/core/ui/Buttons/more-tiddler-actions]]" variable="listItem">
					<$transclude tiddler=<<listItem>>/>
				</$list>
			</div>
		</$let>
	</$tiddler>
</$reveal>

Mostly, it’s only a change of the $list filter expression that was simply copied from $:/core/ui/Buttons/more-tiddler-actions.


Have a nice day
Yaisog

PS: Not all of it works fully. Because the context menu is defined in the page template and not in the view template, e.g. Info that relies on the variable tiddlerInfoState that is computed via qualify in the view template does not work. If it really has to go into the context menu, I think it would have to be passed via the DOM into the context menu. The rest of the items work as far as I can tell.

2 Likes

Hi @Yaisog

It would be great if you bundle this amazing code as a JSON, let one test on tiddlywiki.com

I’ll try to get around to do that, but it’s a few tiddlers to collect, including a custom PageTemplate, and I’d have to translate some text first to make it useful.
Currently I’m way to busy adding context menus everywhere. Just finished one for tasks:

This one is special as I can directly enter an assignee (“Zuweisung ändern”) and a due date without opening extra menus. Before, this was a collection of buttons that appeared next to a task when hovering over it.

I have to say, these context menus are awesome, better than sliced bread. Going back to a regular TW now feels more like it’s a TW4½ instead of a TW5. :wink:

Have a nice day
Yaisog
PS: For the curious: There is a “Meta” tab in my sidebar which lists the tasks (among other things) related to the main tiddler in a zoomin story view. Many of the buttons that are now in the context menu used to be bunched there, also. Not no more!

5 Likes

WOW!
Great job! This worth packing as a plugin!

If you like to pack it as plugin, you may have a look at Gatha Studio which allow you to create plugins on the fly! No learning curve! :sweat_smile:

1 Like

I agree with @Mohammad. This would be a great plugin! I can see some possibilities with my railroad wiki.

2 Likes

Hi @Yaisog

This is very interesting! Is there any demo online to give a try!

Thank you!

I noticed that I still owe you a demo implementation (sorry, have been playing Hard West 2 too much).
Import these tiddlers on tiddlywiki.com:

mwi-context-menu.json (12.6 KB)

Since it’s all wikitext, there is no save/reload needed.
To enable the context menu, select the PageTemplate MWi in $:/ControlPanel → Appearance → Layout.
There should also appear a toggle in the PageControls to switch between custom and browser context menu.

For tiddlywiki.com, I implemented only the ViewToolbar buttons on the whole tiddler frame, but the structure is there for more complex stuff, i.e. by adding the HTML attribute dom-data-contextmenu to any element will give that element its own context menu. The value of that attribute determines the tag that is used to determine which buttons will appear in the menu, e.g. dom-data-contextmenu="Link" will include any button defined in a tiddler tagged with $:/mwi/tags/ContextMenuLink.
The ViewToolbar buttons are defined in $:/mwi/ui/Buttons/view-toolbar-contextmenu-buttons which is tagged $:/mwi/tags/ContextMenuTiddler (standard tag used for the tiddler frame context menu).

While it is purely WikiText, it does require selecting the modified PageTemplate.

Have a nice day
Yaisog

8 Likes

Sounds great. I am looking forward to play with it.

Very nice!
This also has a lot of potentilal for creating other tools.

Thank you for sharing!

@Yaisog Thanks for this!

It doesn’t work if you have Tobi Beer’s appear plugin installed - RSOD. I wasn’t using it and disabling it allowed your context menu to work.

But…

What’s that input-looking box? Tooltip says “Show links”…

Will it only work via the ViewTemplate? I have many tiddlers displayed outside of the ViewTemplate – I truly want it to work there.

This context menu addin by @fastfreddy will work on all pagetemplates and is also very good

Thanks @arunnbabu81 but I think what I’m looking for (a configurable context menu devoid of preconceived ideas about both its location and purpose) is not available. I need it to trigger by HTML node (irrespective of where that node appears) and be populated by actionable items of my choosing. Something like…

<$eventcatcher selector="li" ...>
<ul data-id="my-menu">
  <li>item 1</li>
  ...
  <li>item N</li>
</ul>
</$eventcatcher>

I imagine the trigger that shows the menu would come from another $eventcatcher wrapped over arbitrary tiddler text (blocks of HTML).