Allow register RootTemplate

[linonetwo]

So we can ask all layout authors to add $:/core/ui/PageTemplate/commandpalette to their layouts.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
tiddlywiki5	✅ Ready (Inspect)	Visit Preview	Jun 27, 2024 8:29am

[pmario]

What is "commandpalette"

[Jermolene]

Hi @linonetwo I think the problem you are trying to resolve is the following conflict:

• When plugin authors want to add content to the page layout (eg the command palette), the recommended approach is to tag their template with $:/tags/PageTemplate
• When layout authors want to exclude the standard core page layout elements, the recommended approach is for the template to not pull in the content tagged $:/tags/PageTemplate

The problem for the command palette is thus that it doesn't work in custom templates that do not use $:/tags/PageTemplate.

Perhaps a cleaner solution would be to update $:/core/ui/RootTemplate so that it also pulls in all templates tagged $:/tags/RootTemplate. Then the command palette could be tagged $:/tags/RootTemplate, and it would appear regardless of the selected page template.

[linonetwo]

@Jermolene Updated to only collect tiddlers with tags: $:/tags/RootTemplate. Tested locally that my command palette plugin work with this.

More RootTemplate can be added in the future, like a AssistiveTouch in iOS that help user switch between layouts (apps).

What is "commandpalette"

@pmario do you use VSCode? Press ctrl + shift + P. Obsidian also bring this by default.

[Jermolene]

Thanks @linonetwo I think that looks good

[Jermolene]

Thanks for your patience @linonetwo. On further reflection, I am concerned that this PR might start a slippery slope where authors of custom layouts request a way to suppress root template segments.

I'd like to leave this PR for the moment while we explore alternative ways to achieve the same ends. For example, we could provide a much lower level JS mechanism allowing plugins to add their own entirely independent render context alongside the page container. That would give us even more flexibility, allowing JS plugins to overlay content over layouts that do not themselves transclude the overlays.

[linonetwo]

authors of custom layouts request a way to suppress root template segments

That is true, if someone make a "floating layout switcher button" that shows on every alternative layouts, some layout author may not want the button to show in his layout.

JS mechanism allowing plugins to add their own entirely independent render context

I usually write JS plugin as a widget, and use it in WikiText. Instead of directly register things in a RawMarkup or startup script. Are you suggest adding global UI elements in this way?

Maybe, the root template can works like PageControl buttons (we can hide them in the control panel), and user / developer can control visiblity using a M x N table, where there are M root templates and N page layouts...

[Jermolene]

I usually write JS plugin as a widget, and use it in WikiText. Instead of directly register things in a RawMarkup or startup script. Are you suggest adding global UI elements in this way?

Yes, the approach I proposed would enable JS plugins to add completely independent renderings on top of the root template. It would still suffer from the same potential problem, but it would be more flexible.

Maybe, the root template can works like PageControl buttons (we can hide them in the control panel), and user / developer can control visiblity using a M x N table, where there are M root templates and N page layouts...

I wondered about that, but it's a lot of engineering to put into the core when the need is somewhat marginal.

[linonetwo]

Yes, this should be a simple one meant for future proof. It is not urgent, hope there can be a better solution. Update the title for SEO.

a lot of engineering to put

I also want to put my efforts to WYSIWYG editor related PRs instead.