[TW5] Is there a "slider" in TW5?

[Branimir Braykov]

I want to have a slider wich would open a list based on filters with tags.

Is there anything in TW5 like the slider in TW2?

[Jeremy Ruston]

Hi Branimir

In TW5 one builds sliders with the <$button> widget and the <$reveal> widget. For example:

<$button popup="$:/state/mySlider">Click me!</$button>

<$reveal type="nomatch" text="" default="" state="$:/state/mySlider" animate="yes">

This text is revealing!

</$reveal>

Best wishes

Jeremy

On Mon, Sep 16, 2013 at 1:19 PM, Branimir Braykov <bra...@gmail.com> wrote:

I want to have a slider wich would open a list based on filters with tags.

Is there anything in TW5 like the slider in TW2?

--
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 http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Branimir Braykov]

Great, I'll try it out.

The TW5 documentation is a bit difficult for me to grasp. 

And I just saw that you there undefinde tiddlers named PopupMechanism and RevealWidget :-)

[cmari]

This is really nifty!  I have a follow-up question: when using sliders in a filtered list, is there a way to make each slider open independently?  
Here's my current experiment, which obviously works, but all the sliders open any time any button is clicked:

<$list filter="[tag[myTag]]" >
<$button popup="$:/state/mySlider"><$view field="title"/></$button>

<$reveal type="nomatch" text="" default="" state="$:/state/mySlider" animate="yes">

<$view field="title" format="link"/>
<$view field="text" format="wikified"/>
</$reveal>
</$list>

cmari

[Tobias Beer]

I find this syntax incredibly cumbersome compared to tw2 and I am quite reluctant to use it.

In fact, I don't even want to (be forced to use) a state unless explicitly specified. All I'd want is for the slider to be independent and to thus not open a number of them by virtue of putting this in the same tiddler...

<$button popup=".">Click me!</$button>

<$reveal type="nomatch" text="" default="" state="." animate="yes">

This text is revealing!

</$reveal>

<$button popup=".">Click me!</$button>

<$reveal type="nomatch" text="" default="" state="." animate="yes">

This text is revealing!

</$reveal>

When do I need slider states persisted within tiddlers? Mostly never.

<$slide text="Click me...">

You clicked!

</$slide>

- tobias

[Tobias Beer]

Perhaps even better since reusing existing components...

<$button type="slider" text="Click me...">
You clicked!
</$button>

- tobias

[Tobias Beer]

Mhhh...

Well, this might not be such a good idea, after all, as I don't want the slider contents to look anything like a button.

[Jeremy Ruston]

I find this syntax incredibly cumbersome compared to tw2 and I am quite reluctant to use it.

Yes it is cumbersome in that form. In TW5 there's a layered concept for wikitext functionality:

* Widgets provide the base functionality, and we break the widgets down into the smallest, simplest possible things, designed to be used in combination with one another

* Macros are used to define more expressive, easy to type, blocks of functionality. Macros are application-specific, and are encouraged to pack a lot of functionality into one black box.

* Wikitext syntax provides an even briefer, shortcut way of invoking certain widgets

So, what you're seeing here is how sliders are implemented at the deepest level, that of the underlying widgets.

For example, one could define a slider macro like so:

\define slider(label,text)

<$button popup="$:/state/$label$">$label$</$button>

<$reveal type="nomatch" text="" default="" state="$:/state/$label$" animate="yes">

$text$

</$reveal>

\end

And then invoke it with:

<<slider "Click me!" "This is a revealing sentence">>

The plan is for TW5 to include a bunch of built in macros, similar to TW classic.

 

In fact, I don't even want to (be forced to use) a state unless explicitly specified. All I'd want is for the slider to be independent and to thus not open a number of them by virtue of putting this in the same tiddler...

Storing state isn't something that's optional that we can choose not to do. It's a cornerstone of the TW5 architecture; the UI elements like tabs require state in order to provide the functionality that users expect.

Anyhow, we can hide the state mechanism behind macros; people only need to understand the state mechanism if they're trying to build complex functionality up out of widgets.

 

When do I need slider states persisted within tiddlers? Mostly never.

The reason that state is stored in tiddlers isn't to enable it to be persisted, it's a more fundamental aspect of the design. During refresh processing arbitrary DOM nodes may need to be destroyed and recreated, so we can't store state in the DOM.

Best wishes

Jeremy

 

<$slide text="Click me...">

You clicked!

</$slide>

- tobias

[Tobias Beer]

Hi Jeremy,

For example, one could define a slider macro like so:

\define slider(label,text)

<$button popup="$:/state/$label$">$label$</$button>

<$reveal type="nomatch" text="" default="" state="$:/state/$label$" animate="yes">

$text$

</$reveal>

\end

And then invoke it with:

<<slider "Click me!" "This is a revealing sentence">>

It would be nice to be able to tag a tiddler $:/macro or the likes and thus have those macros defined on startup in order to be used throughout the wiki. Once that is possible, I would welcome a Macros tiddler on @five.

The plan is for TW5 to include a bunch of built in macros, similar to TW classic.

Sure, that will come. For now, I think the above mechanism would speed things up in terms of developing reusable snippets some of which may eventually become core macros.

In fact, I don't even want to (be forced to use) a state unless explicitly specified. All I'd want is for the slider to be independent and to thus not open a number of them by virtue of putting this in the same tiddler...

Storing state isn't something that's optional that we can choose not to do. It's a cornerstone of the TW5 architecture; the UI elements like tabs require state in order to provide the functionality that users expect.

Anyhow, we can hide the state mechanism behind macros; people only need to understand the state mechanism if they're trying to build complex functionality up out of widgets.

The reason that state is stored in tiddlers isn't to enable it to be persisted, it's a more fundamental aspect of the design. During refresh processing arbitrary DOM nodes may need to be destroyed and recreated, so we can't store state in the DOM.

I understand all that. All I'm saying is that I would very welcome some internal state handling that generates / handles generic or random state identifiers (perhaps stored at one or more "state" fields) that don't require me to specify any of that. I hardly ever have an interest in chkSomeSlider or state="$:/state/foo/bar". In other words, if a widget requires a state, yet none is specified, it would be nice if those were created on the fly and persisted where appropriate, i.e. a tiddler field.

- tobias