On Monday, April 2, 2018 at 2:44:31 AM UTC+2, TonyM wrote:
>
> Thanks for the feedback. Perhaps another possibility is custom fields. 
>
> I have being thinking what If there were a pre and Post field permitted in 
> tiddlers to allow <$vars > in Pre and </$vars> in post to wrap the Text 
> field. 
> If a multi-line field this would support local macro definition while 
> leaving the text field free for transclusion as content buy other tiddler. 
> This could include CSS definitions and more.
>

I needed to read this post several times, to understand, what you try to 
achieve. ... At least I think, I got it ;)

This is exactly, what the ViewTemplate 
<https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate>does. It looks 
like this. (code is stripped and indented, to make it more understandable)

<$set name="storyTiddler" value=<<currentTiddler>>>
  <$set name="tiddlerInfoState" value=<<qualify 
"$:/state/popup/tiddler-info">>>
    <$tiddler tiddler=<<currentTiddler>>>
      <div class=<<frame-classes>>>
        <$list 
filter="[all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!has[draft.of]]" 
variable="listItem"><$transclude tiddler=<<listItem>>/></$list>
      </div>
    </$tiddler>
  </$set>
</$set>

As you can see, there are 2 "set-widgets". They set tiddlerInfoState and 
storyTiddler variable. ... 

There is also some "invisible" stuff going on. 
The tiddler-widget internally sets several other variables 
<https://github.com/Jermolene/TiddlyWiki5/blob/52319ee88afbbca96d5084d92c2b63eecd4ab4f7/core/modules/widgets/tiddler.js#L40>
 
which are "hardcoded". As you can see in the core code link. 

So What you propose here is to change the core ViewTemplate and add some 
new variables, that contain user actions. ... 
Or the "tiddler-widget" ... 

Changing the ViewTemplate would be easy. ... But filtering the actions, 
that should actually do something will need a new widget, as Jeremy 
proposed it. ..

You wrote: 

In keeping with this idea we could have* pre and post actions fields* in a 
> given tiddler that are triggered on navigate to, or close.
>

See: "triggered in *navigate to*, or *close."* ... OK ... navigate or close 
.. or both .... 
It's easy to write it here in a sentence. .. It's just 2 words, but it will 
produce the same amount of code. .. We have to handle "navigate to" / 
"close" events or both. ... And how can we decide, if we only need to use 
one action, or both. ... There needs to be some information about it. ... 

So in the end we will need a "myMessageCatcher" as Jeremy wrote, because we 
will need to have a lot of extra info, what we exactly need to do. .. 

Just sorting it out for my own understanding ;)

-mario

PS: BUT I think there is a more general "workflow-problem", that you want 
to address, with the wrong tools. ... I'm just not sure yet, how we could 
solve it, without "blowing complexity through the roof". (Not sure, if this 
is proper englis ;)


-- 
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 [email protected].
To post to this group, send email to [email protected].
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/54e48cf5-6378-44cb-907a-268c45e2f6a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to