Saving states in fields?

[Justin_H]

So to preface, I use the tabs macro for a couple of different things, and one of the things that’s been bouncing around in the back of my head is, why isn’t there a way to save the state of which tab is the current tab into the tiddler with the tab macro?

I’ve tried doing something like,

<<tabs 
	tabsList:"[tag[Contents Tab]sort{!!sort-order}]" 
	default:"Topic Tiddler" 
	state:{{$:/wiki/ui/SideBar/Contents!!current-tab}}
	class:"tc-vertical"
>>

And

<<tabs 
	tabsList:"[tag[Contents Tab]sort{!!sort-order}]" 
	default:"Topic Tiddler" 
	state:"{{$:/wiki/ui/SideBar/Contents!!current-tab}}"
	class:"tc-vertical"
>>

But neither work.
Seeing the amount of status tiddlers that are created when using the tabs macro isn’t very appealing to me, so I figured this would be a better alternative.

Am I approaching this incorrectly?

[CodaCoder]

Remarkably, this works:

Also remarkably, it fails to highlight the selected tab properly

[Justin_H]

Huh, I didn’t think to try the explicitState parameter, but its funny that it partially works.

[TW_Tones]

I have observed a gap in a number of places where the text field is assumed, and it would be useful to be able also use another fieldname.

Whilst the text!!reference approach is useful it is harder to use variables with it, perhaps macros that use state could have an optional stateField parameter that defaults to text?

• @pmario perhaps in your rewrite of the tabs macro we could include an optional stateField parameter.
  • This is arguably quite useful where the state can be confined to the tiddler in which it relates to, avoiding the use of external tiddlers.
  • The question arises shall we allow a timestamps=no option as well? This would be helpful to stop state tiddlers/fields appearing as changed tiddlers.

However there are other cases that could use a “little love” to extend the parameters to other fieldnames.

[Justin_H]

@TW_Tones

However there are other cases that could use a “little love” to extend the parameters to other fieldnames.

Hm, if we are on the topic of parameters getting a bit more love, the emptyMessage parameter is a nice feature of the list macros.

I imagine if you can set a emptyMessage parameter to use a specific field of each tab, you could have a unique empty message for each.
My other thought was the buttonTemplate, but I’m not sure how that could be done. Something like:

<<tabs 
	tabsList:"[tag[Contents Tab]sort{!!sort-order}]" 
	default:"Topic Tiddler" 
	state:"{{$:/wiki/ui/SideBar/Contents!!current-tab}}"
	class:"tc-vertical"
	emptyMessage:"{{!!empty-tab-message}}"
>>

Anyways, just sharing my thoughts

[TW_Tones]

Yes, the button template is a method to introduce different behaviours on tabs, which after all are just buttons and a reveal widget when you did into the $:/core/macros/tabs tiddler.

[pmario]

The tabs macro internally uses the reveal-widget’s state-parameter. Which expects a text-reference, which can be used using “title!!fieldName” - but not in this case. The macro expects a tiddler title

The reveal-widget stateField parameter has been added long after the tabs macro was created.

@CodaCoder

Also remarkably, it fails to highlight the selected tab properly

Because the macro is not designed to use “full” text-references. It expects tiddler titles using the text field.

@Justin_H If you want that to be changed, you should create an issue at GitHub. Otherwise it will be forgotten.

[CodaCoder]

@pmario

@CodaCoder

Also remarkably, it fails to highlight the selected tab properly

Because the macro is not designed to use “full” text-references.

Hence, “remarkably”.

[Justin_H]

@pmario

If you want that to be changed, you should create an issue at GitHub. Otherwise it will be forgotten.

Can do!

If you don’t mind me asking, when is it appropriate for a discussion to be opened about something here vs. submitting a ticket to the Github repo for TiddlyWiki5 ?

I’ve been under the assumption that the Github repo was reserved for bug fixes and submitting documentation / code optimizations.

@TW_Tones

Yes, the button template is a method to introduce different behaviours on tabs, which after all are just buttons and a reveal widget when you did into the $:/core/macros/tabs tiddler.

Oh cool, so I wasn’t too far off the mark, I’ll need to start playing around with that then. It was more an after thought that ‘oh maybe it could be done this way as well?’

@CodaCoder

Hence, “remarkably”.

“It’s not a bug, it’s a feature!” --Todd Howard

[TW_Tones]

@Justin_H

@TW_Tones

Yes, the button template is a method to introduce different behaviours on tabs, which after all are just buttons and a reveal widget when you did into the $:/core/macros/tabs tiddler.

Oh cool, so I wasn’t too far off the mark, I’ll need to start playing around with that then. It was more an after thought that ‘oh maybe it could be done this way as well?

Sorry, I just reviewed this to backup what I thought was the case and it may not be, as it only changes what appears as the button title, and does not permit links either.

I am close to a workaround, but not there yet

[TW_Tones]

@Justin_H

I imagine if you can set a emptyMessage parameter to use a specific field of each tab, you could have a unique empty message for each.

You can by the way. Don’t use emptyMessage:"{{!!empty-tab-message}}".

Rather than use <<tabs ...>>
use the <$macrocall $name=tabs ...

• Then you can use emptyMessage={{!!empty-tab-message}}

By the way in your first examples you should be able to use;

	state:"$:/wiki/ui/SideBar/Contents!!current-tab"

[pmario]

@Justin_H

If you don’t mind me asking, when is it appropriate for a discussion to be opened about something here vs. submitting a ticket to the Github repo for TiddlyWiki5 ?

It’s always appropriate to ask for new features at GitHub. The difficulty is to find out, if it is a bug or an “oversight” on TWs side. So discussions like this one help to find out.

At GH there is the “New Issue” button

Which opens the following dialogue, that allows you to create a

• “Bug report” - which opens an other form, which asks for more details
• “Feature request” - create a new feature request - which is free form plain text
• “Discuss feature request” - GitHub Discussion UI. This one mainly is for highly technical discussions where we are sure they have the potential to confuse users at Talk.
• “Talk.Tiddlywiki Forum” - Is preferred for general discussions and sends users back to this forum

The Talk forum has the “most eyes”. So if you want to be seen use the forum here.

The GH-Discussion UI is “OKish”, but does not really work good for general purpose discussions and help-requests like the forum here. It was mainly built “by developers for developers”.

@Justin_H

I’ve been under the assumption that the Github repo was reserved for bug fixes and submitting documentation / code optimizations.

It is for bug fixes and submitting new docs. But it’s not reserved. – So if GitHub issue/discussions are a much better fit for the forum here, we’ll send users to Talk.

---

For discussions like this one, where it’s not clear, if it is a bug or a feature request we’ll most likely send you to GH to raise an issue. GH issues will stay open for a quite some time and we do have a closer look from time to time.

Eg: I did gently “force” Jeremy around in December last year to close about 150 fixed (but open) or obsolete issues, which brought us down below 1k. Where most open issues are feature requests or improvement requests.

---

Sending Talk users over to GH is not without a “hidden agenda”. – Once users have a GH account, they are able to “star the TW project”.

Just a reminder for those who read this thread and did not “star” the project yet -

hope that helps
-mario

[pmario]

@TW_Tones

By the way in your first examples you should be able to use;

state:"$:/wiki/ui/SideBar/Contents!!current-tab"

That’s right, but it does not really work as expected.