Proposal: Default state for Button+Reveal

[Mat]

Before I post this on gh, I'd like to hear what you think of the following idea:

"I want a button that does...."

...is a common need but requires a more involved process than should be needed. For one thing, it often also requires the RevealWidget which is a bit complex. In particular, if you want the "normal" look for a button, namely one button that does both "on" and "off" (the "Accordion" example) then you need to create two buttons and two RevealWidgets. Way too complex.

So to serve this common use case, could both of ButtonWidget + RevealWidget use a default state tiddler like so "$:/state/<current>"? Default values are perhaps true and false. And if this default state is used, the RevealWidget further defaults to type=match and text=true

This would allow for really simple syntax:

<$button>Toggle</$button>

<$reveal>

Content

</$reveal>

So, this idea is really two individual proposals because of the typical coexistence between the widgets:

1) Make the ButtonWidgets set and setTo have default values $:/state/<current> and true. For this to be meaningful, the widget must first check to see if this state tid is already set, in which case it sets it to false or, perhaps better, deletes the state tid.

The resulting state tiddler can of course be used for anything...

2) ...but, particularly for the RevealWidget; if no RevealWidget state parameter is defined then default to state=$:/state/<current>  and type=match and text=true

<:-)

[TonyM]

Mat,

This sounds like a good idea. I would only add the following.

Often such toggle Buttons actually consist of two buttons or images. One to toggle on and one to toggle off. And example may be a green and red button indicating the toggle state.

So perhaps what you ask for could be developed into a macro, that one allows you to define such toggle buttons that manipulate the same state reference as you use in the the reveal. Ideally we could pass the state tiddler and the on and off text or buttons, or even just a parameter or class to change colour of the button. By doing this we can reuse the same macro rather than needing to copy and modify it, however this could be useful if you want to add more action widgets to the toggles. By the way the toggle off can have an action widget to delete the state tiddler.

Regards

Tony

[Jeremy Ruston]

Hi Mat

Good stuff. I support the idea of making hide/show buttons easier to use.

However, there are some issues with this proposal as it stands:

* It’s not backwards compatible. Right now there are lots of `<$button>` widgets without any attributes that use action widgets to do their stuff

* The proposed algorithm for autogenerating the state tiddler title isn’t robust enough to permit, say, two hide/show constructions within a single tiddler

An alternative approach might be to devise a macro <<accordian>> that takes the text of the button and the title of a tiddler containing the content. Then one could use the target tiddler title as part of the state tiddler title, making it possible to have multiple accordions within a single tiddler as long as they each target a different tiddler.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/350ca438-2a71-46fb-80f9-08d271a125c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

Tony, Jeremy, thanks for replying.

Jeremy Ruston wrote:

* It’s not backwards compatible. Right now there are lots of `<$button>` widgets without any attributes that use action widgets to do their stuff

How does the addition of temporarily creating the state tid make it not backwards compatible?

I can see one problem; if the user already uses specifically $:/state/<title>  ...but this has the same solution as my next reply:

* The proposed algorithm for autogenerating the state tiddler title isn’t robust enough to permit, say, two hide/show constructions within a single tiddler

The qualify macro? (I was actually considering this aspect but reasoned that we do accept this problem with e.g the tag macro.)

 

An alternative approach might be to devise a macro <<accordian>> that takes the text of the button and the title of a tiddler containing the content. Then one could use the target tiddler title as part of the state tiddler title, making it possible to have multiple accordions within a single tiddler as long as they each target a different tiddler.

Hm... I've used these constructs and they're not particularly good. It solves the state tiddler title issue elegantly for but it is iffy to split out text into separate tiddlers and you loose the content view when you're editing. OK, the excision tool would simplify, and if you use preview edit (which I don't)... but still. AND you can't put the button and the content in different places. 

<:-)

[PMario]

Hi Mat,

I think this is absolute plugin and macro territory. ... In my video series [1] about the Script Todo Manager [2], I use 4 different "toggle buttons" in 1 edit area.

None of them would work with your proposal, since real workflows are a little bit more complicated.

1: Is similar to your proposal, but also needs stuff that Tony describes. .. Dynamic texts .. Open action .. Close actions and so on.

2: Is a toggle button, that uses an image instead of text

3: Open if you click 2. ... It's a "Delete Cancel OK" toggle button.

4: is "Cancel OK" ...

Link [1] points to 3 little videos, that discuss how to create Toggle-Buttons in a step by step tutorial, from scratch.

Link [3] points to the macro code.

Link [4] points to a video (15min), that contains several other "multi state buttons", based on the toggle-me mechanism. It's also a step-by-step intro.

That's the reason why I think this is macro and plugin territory.

have fun!

mario

[1] https://www.youtube.com/watch?v=OTZweSsf0uE&list=PLuiC_HFhI4OzcqS8wBPSgT3nEK8WAXswk&index=15

[2] https://wikilabs.github.io/editions/script-manager/

[3] https://wikilabs.github.io/editions/script-manager/#%24%3A%2F_bundle%2Fwikilabs%2Fscript-manager%2FtoggleMe-macro

[4] https://www.youtube.com/watch?v=6a7KTP9e3fg&list=PLuiC_HFhI4OzcqS8wBPSgT3nEK8WAXswk&index=9

[Mat]

@everyone - my proposal for the qualify macro is misguided as this also only creates the same repeated unique string when used in the same tiddler.

[Mat]

PMario, thanks for your thorough reply.

However, I don't understand the premise of your post, i.e when you say

I think this is absolute plugin and macro territory.

Why??? I agree it currently IS plugin territory, but premise of the OP is that it should not have to be. The mere fact that you've made a macro implies that you agree that the current steps to create a simple accordion are too complicated, given how frequently it is done ...so then, why don't you think native TW should serve this directly?

Again, thanks for your kind reply and the ambitious plugin you made.

<:-)

[TonyM]

Mat,

I think this issue warrants a good solution. I am working on it and think I have found a nice way to implement it. I will share later but here is a hint.

<<reveal-button buttonmame>>

Reusable macro that creates a pair of named toggle buttons. Displaying one according to the state, including a default state. A choice of local or global button. The reveal code is hidden inside the macro and reveals some css in one state and other css in the other state, no one can see this css. The css toggles display: none on the id in question.

In the tiddler body you use html sections or other html tags like a p div or span, with the id=buttonname-show or id=buttonname-hide rather than a reveal widget.

Eg
<section id=buttonname-show>
this wiki text will show if the toggle is in the show state
</section>

Testing shows you can have multiple sections or tags with the same id.

<section id=buttonname-hide>
this wiki text will show if the toggle is in the hide state
</section>

does this sound good?

Tony

[Mat]

TonyM wrote:

does this sound good?

Thanks for input Tony!

I'd for sure be interested to see it if you make it but my point is that this all should be easier in native TW (albeit possibly with a core macro) because it is such a common user need. 

Side note: This keeps happening; I point out a "weakness" in TW, not a problem I have myself, and (very) good hearted fellow tiddlywikians come with proposals to help me personally. I appreciate this very much but 

1. I must learn to make it much clearer that/when I'm not asking for personal help 
2. solving native TW weaknesses with "community plugins" would be okay IF(!!!!) we had a good infrastructure that made all plugins accessible in one place. In contrast to us reading this, non-geeks should not have to spend a lot of time and frustration on the boards looking for solutions to common problems that a "note taking tool" / "knowledge base" / "wine data-base" etc should solve.  (...and, no, the individual initiatives to collect all plugins is not sufficient as they outdate and rot. Time has proven again and again that this is not a one man job, which is why I don't take initiative to report my creations to them.) Until then, unofficial plugins are IMO just not a good answer to "weaknesses" in TW.

<:-)

[TonyM]

Mat,

Believe it or not I totally understand. Perhaps I did not emphasis this. 

I think I have a solution to make a simpler way to use and  "commoditize buttons" to toggle content, This can be implemented in a macro and leveraging css to do so, and a simpler method that using reveal.

Whilst I think this is initially a solution, or a work around and perhaps it could be a plugin, once the community accepts it, perhaps it becomes part of the core,  just as the tag and TOC macros are part of the core, or as you say "Native TW". This then becomes the simple documented method to handle content toggling.

You have pointed out a weakness in TW, and I believe I have found a solution, lets get it tested and embedded in TiddlyWiki and it will no longer be a weakness.

Regards

Tony

[Mat]

Tony

I'm intrigued to see what you've come up with :-D

[...] the core,  [...] or as you say "Native TW".

By "native TW" I mean whatever comes in the "standard distro". Note that "the core" only refers to the specific plugin named such. For my purposes, I've found it best to avoid saying "core" all together.

<:-)

[PMario]

On Monday, June 24, 2019 at 5:31:06 PM UTC+2, Mat wrote:

2. solving native TW weaknesses with "community plugins" would be okay IF(!!!!) we had a good infrastructure that made all plugins accessible in one place.

Absolutely right. We should focus our energy, to create a more accessible infrastructure, instead of trying to put everything into the already bloated core. ....

see new math functions, that already cause more problems than they solve. ... TiddlyWiki will never be "spreadsheet program" and it shouldn't try to be one. Especially when really good pluins already exist.

With 5.1.20 everyone will need to carry weight, even if I want to use much better utilities. Like mathcell. ...

have fun!

mario

[PMario]

Hi,

---------- May be OT --------

The other math project, that should be part of the core is http://evanbalster.com/tiddlywiki/formulas.html

-m

[TonyM]

Mario

I agree with you in principal but I do belive the new mathematics operators are in some ways a minimum requirement. Until now a number of simple things you would expect were not possible without plugins.

Some of Evans formula features should be in the core but a lot of it also makes sense as a plugin.

In the button solution I have developed it is very light weight, and would I believe make a lot of things easier that could justify being in native tiddlywiki but that discussion is for another time.

Regards
Tony

[Mat]

I'm OK with this (particular) thread going off topic.

PMario wrote:

Absolutely right. We should focus our energy, to create a more accessible infrastructure, instead of trying to put everything into the already bloated core. ....

I currently have a lot of time to tiddle fiddle and hope to pick up on a TWederation project that I had to cut just on the goal line last year. It is based on @Jeds Bob stuff so I just now contacted him to hear if he is available for discussions. One key component is a central server; not for the actual content (i.e plugins etc) but for a public list of the sources holding that content - and a "script" that roams the sources to fetch upated info (compare to Erwans solution). Jed generously offered his personal company server to host this and I hope this is still possible.

Would you guys be willing to support this with your knowledge? All the pieces are basically there already. I'm building an end user UI for subscribing to sources.

<:-)

[TonyM]

Folks,

I have a macro that provides easy, tidy and on demand buttons to toggle content. I will share it shortly after a little self documentation. I also need to find a smart way to permit applying a style or class to the button in either state. Too many parameters in a macro would make it unfriendly.

Regards

Tony

[TonyM]

Ok Here is my button reveals plugin, attached, with documentation, stored in a bundle

Please provide feedback, then I will publish in the user forum.

Provides two macros to create buttons to toggle content displayed in tiddlers or anywhere in your wiki.

• toggle-global buttonname sets a state tiddler - of the name "$:/config/button-buttonname-state"
• toggle-here buttonname sets field in the current tiddler - of the name "button-buttonname-state"

both buttons also toggle visibility of html elements with an ID=buttonname-true or ID=buttonname-false

 

But of course Use list and reveal as you wish by referencing the local field or state tiddler

<$list filter="[is[current]button-buttonname-state[true]]" variable=nul>
Show when true
</$list>

<$list filter="[{$:/config/button-buttonname-state}] -[[false]]" variable=nul>
Show when true
</$list>

<$reveal type="match" state="$:/config/button-buttonname-state" text="true">

! This is the revealed content
And this is some text

</$reveal>

This seems to me so useful it may deserve an approved version in the native wiki.

Regards

Tony

[Mat]

Tony, great start. Here is some feedback.

1) [Edit: Disregard this point: Maybe it is just part of the demo but the button literally has the label "buttonname is false".]

2) I get a false positive in

<$list filter="[{$:/config/button-buttonname-state}] -[[false]]" variable=nul>
Show when true
</$list>

i.e "Show when true" shows without having clicked the button. I suspect the filter leaves "remaints" when the state tiddler doesn't exist, like empty brackets, so it becomes "[] -[[false]]" which is not empty. Try this for example: <$list filter="[{doesntexist}]">xxx</$list> [Edit: reported issue]

3) For the reveal, are you saying the user should manually type in one (or even several?) of those listwidgets/revealwidgets? That kinda defeats the point with the simplified button. To name one thing, how is the user supposed to remember the string "$:/config/button-buttonname-state"? I'd suggest packing this into a macro as well. (And what's with the unused nul variable?)

4) Before it is released, may I humbly propose that you make the code more dry, i.e that you move the identical parts of the macros to a single macro and have the call to it define if it is "here" or "global". Currently, it is a pretty big code for a small thing. By doing this you could also use, say, the "here" version as a default so that the user can use "<<toggle Foo>>" or "<<toggle-global Foo>>".

This could really be something useful!

<:-)

[Mat]

Mat wrote:

I currently have a lot of time to tiddle fiddle and hope to pick up on a TWederation project that I had to cut just on the goal line last year. It is based on @Jeds Bob stuff so I just now contacted him to hear if he is available for discussions.

Happy to get a reply from him saying he is available for this!

<:-)

[TonyM]

Mat,

Thanks for the feedback

I assume you read the content of 

$:/PSaT/button-reveals?

 

Note: Using variable=nul in a list widget is a reliable way of using a list widget to selectively display content. If you do not need or want the current tiddler to change or be lost inside a widget defining "variable=variablename" changes <<variablename>> not <<currentTiddler>> according to the filter, this leaves you free to reference the original current tiddler and use shortcuts like {{!!fielname}} or {{!!title}}

If however the list filters only purpose is to display something when the filter is true, then I name the variable nul so it is clear to me I will not be accessing the actual result of the filter, only the fact it is true.

2) I get a false positive in

<$list filter="[{$:/config/button-buttonname-state}] -[[false]]" variable=nul>
Show when true
</$list>

i.e "Show when true" shows without having clicked the button. I suspect the filter leaves "remaints" when the state tiddler doesn't exist, like empty brackets, so it becomes "[] -[[false]]" which is not empty. Try this for example: <$list filter="[{doesntexist}]">xxx</$list> [Edit: reported issue]

Opps, these are not dealing well with a empty state field/tiddler. I will check and update. They need to be rewritten to account for the non existent state field or tiddler. Another reason to use the ID= method. This is unlikely to happen with a global state because it will not happen after the first use.

 

3) For the reveal, are you saying the user should manually type in one (or even several?) of those listwidgets/revealwidgets? 

Actually this was designed to be used any way you choose. Personally I think this method is the best AND THE ONLY NECESSARY, such is the way we can define the area which we wish to toggle into view

<<toggle-here local-show>>

<section id=local-show-true>
I am on true 
</section>

<div id=local-show-true>
I am on true 
</div>
But you could use it on div span etc...

This has the advantage that the default will be honored even if the state tiddler and field do not exist.

By the way when testing did you not have a button with a more original name than buttonname ?

When I say one (or even several?) of those listwidgets/revealwidgets?

Use one Only if you want, or as many as you want. If you only want to display one thing in one condition go ahead. But you could;

Have multiple places in a tiddler respond to this state

Buttons on the view template, page template, above store, sidebar etc... can all respond to the toggle state.

To name one thing, how is the user supposed to remember the string "$:/config/button-buttonname-state"? I'd suggest packing this into a macro as well. (And what's with the unused nul variable?)

You need only remember "buttonname" the name you used, if you use the HTML id. and then add either -true or -false at the end. if you wish to use a state tiddler for a global state it will always be $:/config/button-buttonname-state (replace buttonname with your chosen toggle button name(s).

 

4) Before it is released, may I humbly propose that you make the code more dry, i.e that you move the identical parts of the macros to a single macro and have the call to it define if it is "here" or "global". Currently, it is a pretty big code for a small thing. By doing this you could also use, say, the "here" version as a default so that the user can use "<<toggle Foo>>" or "<<toggle-global Foo>>".

Your humble suggestions will be taken into account. But I wanted to test the resulting functionality first. Not that it is very big anyway, yes I could almost halve it, but it will be less easy to understand.

 

This could really be something useful!

Thanks, I hope so for others, because I think it will be important to me. 

<:-)

On reflection I can see that something similar could be done for a range of items beyond a toggle/reveal combination, I am thinking of check boxes, Detail reveals, multiple values select dropdowns etc... What interests me is finding a simple way to have interactive documents in which you make choices and different information reveals itself.

Regards

Tony

[Mat]

@Tony, the more I let your creation sink in, the more I like it.

Of course, it expects the user to do some (very basic) html coding in the wikitext - which is fine by me and anyone who masters html, but...

...or, actually, can wikitext elements have css IDs?

One thing to note - at least I think this is how it works - is that if using it for a reveal widget; content isn´t evaluated in revealwidget closed state whereas I belive merely hiding it with display:none does evaluate it. (...right?)

 

 Note: Using variable=nul in a list widget

That's an interesting use of the variable. Still, I'm not sure why it would be needed in the macro. (Makes me wonder if I also have such "personal touches" that slip along with my public stuff? Hard for one self to tell. )

 

  

On reflection I can see that something similar could be done for a range of items beyond a toggle/reveal combination, I am thinking of check boxes, Detail reveals, multiple values select dropdowns etc... What interests me is finding a simple way to have interactive documents in which you make choices and different information reveals itself.

In deed interesting.

 

Some more notes to consider before you publish:

• Inform that buttonname must obey field name rules. (slugify need keeps popping up)
• Must enclose $buttonname$ in triple quotes in some places or <__$$__>
• Nit pick

<:-) 

[TonyM]

Mat,

Thanks for more input, that is what I call collaboration

Of course, it expects the user to do some (very basic) html coding in the wikitext - which is fine by me and anyone who masters html, but...

No expectations here. If you want to use reveal widgets or list widgets as long as you know the name of the field or state tiddler that is generated by your button you can use standard methods and ignore the css approach. To me it is simpler to learn than the two button and multiple reveal methods that are documented today.

 

...or, actually, can wikitext elements have css IDs?

Yes they often do already, but they are not named buttonname-true buttonname-false Perhaps we should alter a class name instead or as well. There is however a lack of good documentation telling you what classes apply to what tiddlywiki objects, even although the information is contained in tiddlywiki. Perhaps invent some of my own.

One thing to note - at least I think this is how it works - is that if using it for a reveal widget; content isn´t evaluated in revealwidget closed state whereas I believe merely hiding it with display:none does evaluate it. (...right?)

I think you are right, lets check, however as suggested, use the reveal widget with the toggle, if this is what you are after.  

 

 

 Note: Using variable=nul in a list widget

That's an interesting use of the variable. Still, I'm not sure why it would be needed in the macro. (Makes me wonder if I also have such "personal touches" that slip along with my public stuff? Hard for one self to tell. )

To be sure it is called nul because it is not needed in the macro, but we want original <<currentTiddler>> to be available so we use the variable.

I would love to see more sharing of code practices that make sense, I think this one does.

 

 

  

On reflection I can see that something similar could be done for a range of items beyond a toggle/reveal combination, I am thinking of check boxes, Detail reveals, multiple values select dropdowns etc... What interests me is finding a simple way to have interactive documents in which you make choices and different information reveals itself.

In deed interesting.

 

Some more notes to consider before you publish:

• Inform that buttonname must obey field name rules. (slugify need keeps popping up)

Agreed field naming and HTML ID naming rules.

 

• Must enclose $buttonname$ in triple quotes in some places or <__$$__>

Of course you are correct but not doing so will allow button names that are not slugifield from being used and thus breaking.

I will look through to see the consequences.

  

• Nit pick

Not a nit

 

<:-) 

[TonyM]

Mat,

As I continue working on this as usual with tiddlywiki, I see another valuable path to go down, with long term benefits. Perhaps we should publish some macro design guidelines and share the code patterns.

Each macro design guideline published could have a name so we can quote these in the macro documentation eg; Using design standards "Helpful Macros" "macros registered in fields"

• Use of variable=nul to ensure `<<crrentTiddler>>` remains that of the calling tiddler if you have no need to use the result in your macro. If you do then use variable="meaningful-name"
• For every macro defined create a field in the tiddler where it is defined macro-macroname and place in that field the syntax `<<macroname parms>> more details`
• Thus every macro in the wiki can be found, where its defined and its syntax
• For every macro defined create an additional one called ``<<macroname-help>>` that will display A detailed syntax of the macroname.
  In a section with `style="outline-style: dotted; padding: 3px; background-color: lightblue; "`
• For every macro test if any named parameter has the value "?" and display `<<macroname-help>>` if so.
  EG; `<$list filter="[[$buttonname$]] [[$true$]] [[$false$]] [[$default$]] -[[?]] +[limit[1]]" emptyMessage=<<toggle-here-help>> variable=nul>`
• etc...

Do you have some ideas of your own on this?

Tony