Add disable parameter to keyboard widget

[pmario]

This PR is related to PR: use a textarea in advanced-search-filter tab #8194 which should be implemented differently in wikitext.

To be able to implement #8194 functionality as a plugin the core needs to support a "disabled" parameter for the keyboard-widget, which this PR implements.

• "disabled" defaults to "no"
• If set to "yes" the keyboard widget event-handler will not be created in the DOM.
• If disabled a tc-disabled class is assigned to the HTML element, so it can be used for styling if needed.

[vercel]

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

Name	Status	Preview	Updated (UTC)
tiddlywiki5	✅ Ready (Inspect)	Visit Preview	May 29, 2024 0:13am

[saqimtiaz]

To be able to implement #8194 functionality as a plugin the core needs to support a "disable" parameter for the keyboard-widget, which this PR implements

Can you explain why this is necessary, as opposed to just not using the keyboard-driven-input macro in the UI that the plugin implements?

[pmario]

The "keyboard-driven-input" macro also implements the CTRL-ALT-left and CTRL-ALT-right shortcuts to navigate between the tabs. This functionality should still work.

If the filter-input is a text area, the up and down keys are needed to navigate inside the text area, so they need to be disabled within the keyboard-driven-input macro.

[Jermolene]

The "keyboard-driven-input" macro also implements the CTRL-ALT-left and CTRL-ALT-right shortcuts to navigate between the tabs. This functionality should still work.

If the filter-input is a text area, the up and down keys are needed to navigate inside the text area, so they need to be disabled within the keyboard-driven-input macro.

Thanks @pmario I am tempted to suggest that we remove the CTRL-ALT-left and CTRL-ALT-right shortcuts from advanced search, and instead try to implement keyboard shortcuts in a general purpose way within the tabs macro. It certainly complicates the advanced search code a lot.

[saqimtiaz]

@pmario please note that the previous and next tab behaviour is independent of the keyboard-driven-input(kdi) macro, so you can maintain that behaviour and not use the kdi macro.

See:

TiddlyWiki5/core/ui/AdvancedSearch/Filter.tid

Lines 6 to 13 in 3af2a0a

	\define set-next-input-tab(beforeafter:"after")
	<$macrocall $name="change-input-tab"
	stateTitle="$:/state/tab--1498284803"
	tag="$:/tags/AdvancedSearch"
	beforeafter="$beforeafter$"
	defaultState="$:/core/ui/AdvancedSearch/System"
	actions="<$action-setfield $tiddler='$:/state/advancedsearch/currentTab' text=<<nextTab>>/>"/>
	\end

[pmario]

I think the disabled parameter for the keyboard widget is useful independent of the keyboard-driven-input macro. It can help to make macros more flexible, in the same way as it does work for the button-widget

[saqimtiaz]

@pmario The genesis widget already offers a great deal of flexibility in terms of conditionally creating a keyboard widget. Can you think of a scenario where that is not sufficient or flexible enough?

[pmario]

The genesis-widget is OK for advanced users to extend the functionality of core widgets, but users should not be forced to use it, to fix deficits of core widgets.

[saqimtiaz]

I don't see any deficit here with the keyboard widget, and the genesis widget is precisely the tool that should be used when desiring flexibility as to which widget/element to create. This was one of the driving factors behind its creation. It is not meant just for overriding or tweaking core widgets.

Furthermore disabling the keyboard widget in this manner is extremely awkward for a widget that usually has no visible user affordance and this has no precedence, neither in the core nor in HTML.