[IDEA] Add actions to $browse widget or new widget to add actions to any "trigger".

[AnthonyMuscio]

Is your feature request related to a problem? Please describe.

With tiddlywiki hosted inside a browser there are limitations on the level of interaction with the local file system.

There are a range of workarounds and smart workflow techniques.

A key tool in importing files/tiddler/json etc... is the <$browse> widget. Being a button it is also a trigger. But currently it does not have an "additional" actions parameter. This makes it hard to integrate additional features, such as copying a URL or File Path to the clipboard for use in the open dialogue.

Describe the solution you'd like

The addition of an actions parameter to the browse widget, I would like it to allow additional actions before the open dialogue, but others may want to trigger actions before or after the file is retrieved.

• The Checkbox widget demonstrates the use of differentiated actions with its actions, checkactions and uncheckactions

Describe alternatives you've considered

I cant see a way to wrap the browse widget with a button that triggers a copy to clipboard, then the browse button. In "Additional context" below I illustrate an alternative.

Additional context

Whilst this is a specific request to modify a widget (the browse widget) to include actions, I wonder if using a message catcher, event catcher type of solution could be used to make a generic actions tool, such that wrap any button code in custom widget to add actions on, before or after the on-click within the inner button.

• This would stop the need to add actions individually to widgets already containing a trigger, rather a custom widget allows it to be done to any trigger?
• perhaps even generic HTML triggers eg wrap <button>name</button>
  • this could help convert HTML to TiddlyWiki
  • One example

    <$on-trigger actions=<<once-actions>> before-actions=<<before-actions>> after-actions=<<after-actions>> >
    <$browse muitiple accept={{!!extensions}}/>
    </$on-trigger>

• There was a tool in TiddlyWiki classic that did something similar to this, one feature was to overwrite the buttons label as well.

[pmario]

We do have several "catcher" widgets that should be used to do what you request. ... but ... The $browse-widget is a very special type of the HTML INPUT element. The INPUT element can have 22 different functions which are all slightly different.

At the moment none of the existing catchers is able to provide the "file" or "filesList" info to connected actions. So we would need to extend the $message- and/or $eventcatcher widgets to give us this info. But even then it would be close to impossible for ordinary users to use it properly.

--> I would vote for some more dedicated widgets that can deal with the different INPUT element types.

We already have the $button, $checkbox, $radio, $range and $text widgets, where most of them already have an "actions" parameter.

It is possible to use eg: $button type=color BUT it is not really suited for the usecase we need to manage our TW color palette. It is OK to be used as a button

I did create an EditColourWidget for the new palette-manager edition. .. It will work with the TW palettes and can resolve nested <<colour macros using dedicated actions. .. But it is still a bit brittle.

[pmario]

The browser file-dialogue will always show up with the latest directory setting, that the user used with the last dialogue. It's not possible to manipulate that dialogue from the core.

A key tool in importing files/tiddler/json etc... is the <$browse> widget. Being a button it is also a trigger. But currently it does not have an "additional" actions parameter. This makes it hard to integrate additional features, such as copying a URL or File Path to the clipboard for use in the open dialogue.

What you request here IMO is a pre-action, that will be activated prior to the actual browser file-dialogue. So it would be easier to manually set the path, since the URL is already in the clipboard. ...

If the OK-button is pressed in the dialogue, the element will only give us back the relative filename and some info about that file. .. The files and the content of the files are stored in the DOM VALUE and FILES attributes .. That's why the existing catchers don't get this info. ..

That's the main reason, why there is a dedicated $browse-widget.

[AnthonyMuscio]

The browser file-dialogue will always show up with the latest directory setting, that the user used with the last dialogue. It's not possible to manipulate that dialogue from the core.

I am not asking to manipulate the dialogue just, as you say, allow a pre-action, in this case to use tm-copy-to-clipboard, if the full path is available (in a tiddler field) and then I use ctrl-v (actually F1 key) in the open dialogue. At the moment it is a two step process, one button copies the full path to the clipboard, the second is the browser widget click.

• These must be two buttons with the current functionality I just hope to use the same button to also trigger the tm-copy-to-clipboard.
• I already have a robust workflow with the path copied to the clipboard being files or URL's to files, which are also easy to capture via the open and save as dialogues using Windows copy to clipboard features. Unless the file is moved I need only do this once.

If the OK-button is pressed in the dialogue, the element will only give us back the relative filename and some info about that file.

• Open dialogue - Actually it does all I need, it imports the file(s)
• Save as Dialogue - Or saves as the file "at the end of the full path", with out needing to find the folder.

[saqimtiaz]

Invoking actions when opening the browse widget dialogue is already possible:

\define pre-actions()
<$action-sendmessage $message=tm-copy-to-clipboard $param="hello"/>
\end

<$button tag="span" actions=<<pre-actions>> >
   <$browse muitiple accept=".jpg"/>
</$button>

[AnthonyMuscio]

Invoking actions when opening the browse widget dialogue is already possible:

Thanks @saqimtiaz I now recall something like this working in the past. If this is the best, even just good enought we should document its a such. There are other cases where this pattern would be useful. I am not sure it always works but will endevore to work it out and document it.

[AnthonyMuscio]

Unless someone else has more information, I plan to take this solution, thanks @saqimtiaz, and some research, that I now understand it better and can document this to address the OT, thus being in a position to close it soon.

• If you have any additional information please share.
• Where on tiddlywiki.com is a good place to document this?
  • I think a new tiddler, named "button - on click" or "on-click trigger" tagged "TriggeringWidgets" and referenced as a see also in ButtonWidget
• shall we call this "on-click actions wrapper", "on-click trigger" ?

Is the critical fact here that the "outer button" is using the tag field "tag=span" to stop it being a button and become a mere span?

• Thus permitting other code containing an on click reaction to ALSO trigger the outers actions?
• Arguably any html inline or block tag will work, whilst not necessarily interfering with other trigger/actions/buttons/tags within.
• This can be used to apply/override all tooltips inside the button

\define pre-actions()
<$action-sendmessage $message=tm-copy-to-clipboard $param="hello"/>
\end
<$button tag="span" actions=<<pre-actions>> >
   <a title="tooltip" href="https://tiddlywiki.com" target="_blank">tgo</a>
</$button>

With $button tag="span" When I look at the resulting RAW HTML we can't see the outer actions at all.

Conclusion;

<$button tag="span" actions=<<pre-actions>> >

</$button>

Is effectively an onclick actions wrapper for anything that does not have an actions param!, or to add an additional action.

• This is the same action for anything within, such as all items in a list, see below.
  • However the items in that list will have there own actions like navigate
• the modifier keys could also be used but both this outer actions and the inner actions will receive the same modifier keys.
  • one could thus differentially code the inner and outer actions.

Button on click wrapper for a list

<$button tag="span" actions=<<pre-actions>> >
   <$list filter="[tag[Blog Home]]">

   </$list>
</$button>

Some interesting uses can make use of this;

• With a list on the inner, the outer actions could be alt-click to copy the filter used, ctrl-click to copy the resulting list of tiddlers.
• This can simply be used to override the tooltip(s) for any and all content.
  • The tooltip could indicate the number of items in the list.
• The outer could possibly use popup/toggle/or cycle to change a state tiddler that alters the way we see the list
• This may be a way to introduce other things to a list/the content as a whole, just as any html tag can do.
• I am sure with this documented publicly we will see more innovations around this.

[btheado]

I think a new tiddler, named "button - on click" or "on-click trigger" tagged "TriggeringWidgets"

All the tiddlers currently with that tag have and "is-a" relationship. IOW they only have that tag if it is a tiddler which describes a widget. Since this new tiddler would not have that relationship, I don't think it should have that tag.

and referenced as a see also in ButtonWidget

A link in the attribute table in the "tag" row would be good

[AnthonyMuscio]

A link in the attribute table in the "tag" row would be good

Agreed, but I can see more information about this usage would be helpful, and it is a "meta trigger" of sorts.

Perhaps some additional information in the tiddler TriggeringWidgets if not tagged as such?