Why do Startup Actions not work?

[TonyM]

Folks,

I have a tiddler tagged $:/tags/StartupAction containing 

<$action-sendmessage $message="tm-modal" param="Username Modal"/>

Can anyone tell me why I am not presented with the popup modal when I reload the wiki?

I would have thought this would work, but it clearly does not.

Thanks in advance

Tony

[Mark S.]

This won't fix your problem, but based on the examples it should be $param (with a dollar sign).

I'm thinking that the action widget doesn't work with tm-modal, possibly because the remaining part of the start-up closes out the modal before it even displays. I guess you need a "action-at-end-of-startup" tag. But that's just a guess.

-- Mark

[TonyM]

Mark,

Thanks, Going from button message to action send message, you do need to use the $, However I use the below form and it works in a button but not in a tiddler tagged startup actions.

<$button>
<$action-sendmessage $message="tm-modal" $param="Username Modal"/>
Action send</$button>

Almost all the $:/tags/StartupAction examples use a reveal widget, but even putting it within this makes no difference.

I am looking for any method, in the startup actions that can stop the user proceeding without taking an action.

Are their any alternatives to modals?

Regards

Tony

[Jeremy Ruston]

Hi Tony, Mark,

The reason that startup actions can’t trigger a modal is because the actions are run before the modal mechanism is initialised. We run the actions early so that they can be used to set parameters that are used further down the initialisation process (for example, the startup actions have to be very early to allow them to set the language or theme before they are initialised).

We could fix it by adding further variants of $:/tags/StartupActions that run at different points in the startup process. Perhaps we could use a field “when” to contain strings like “before-commands” or “after-load-modules” (referring the names of the existing startup modules). I think it would require us to move the $:/tags/StartupActions processing into the boot kernel, which is not ideal as it’s already getting pretty large.

Best wishes

Jeremy.

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/d8ae8f2c-311c-4201-a3cd-1b8c03e528c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TonyM]

Jeremy,

Thanks for that overview. If would be helpful if we had a list of what is valid in the existing start action tags.

I am keen to test and respond to content or the uri passed to tiddlywiki before the final loading of default tiddlers as I imagine a lot of users would, as opposed to the lower level screen size settings which are undoubtedly needed.

Perhaps we need another set of start actions at the very end of the startup process for higher level responses. I would expect these would be triggered just before default tiddlers are loaded, perhaps even allowing the default tiddlers to be changed. The key is acting before the user gets to act, a one time trigger, for automation.

I was hoping to be able to change tiddlers, trigger a wiki save, even a reload in cirtian circumstances or force a modal that must be responded to before completing startup. Of course a designer may cause an infinite loop but it is a risk that is needed.

Given tiddlywiki is a Quine some patterns will allow it to write to itself then call itself. With local storage, savers and the uri from full wikis or static tiddlers I think I can build a serial multi user system, a checkout system even on top of the single file wiki.

Regards
Tony

[TonyM]

Bump

Folks I am keen to be able to build a User login system and need some startup actions to produce a modal etc.. please help if possible.

Regards

Tony

[Jeremy Ruston]

Hi Tony

> Thanks for that overview. If would be helpful if we had a list of what is valid in the existing start action tags.

Currently, startup actions are run early in the startup process, before any of TiddlyWiki’s subsystems are initialised apart from the $:/info mechanism. The idea is to be able to use environmental factors detected by the $:/info mechanism to control the rest of the startup process (e.g. switching language).

As I said earlier, we could add finer grained startup actions that are executed later in the process.

> I am keen to test and respond to content or the uri passed to tiddlywiki before the final loading of default tiddlers as I imagine a lot of users would, as opposed to the lower level screen size settings which are undoubtedly needed.

I’d like to make it possible to customise how the location hash is handled. The present behaviour is hard coded, but I’ve thought for a while it would be useful to refactor it as a startup action that can be customised.

> Perhaps we need another set of start actions at the very end of the startup process for higher level responses. I would expect these would be triggered just before default tiddlers are loaded, perhaps even allowing the default tiddlers to be changed. The key is acting before the user gets to act, a one time trigger, for automation.

Exactly that.

> I was hoping to be able to change tiddlers, trigger a wiki save, even a reload in cirtian circumstances or force a modal that must be responded to before completing startup. Of course a designer may cause an infinite loop but it is a risk that is needed.

Most of that goes beyond what we have at the moment, and some is quite challenging: for example, TW5 needs to be up and working in order to display modals, and so it’s hard to imagine a way in general in which we can defer completing startup until afterwards.

> Given tiddlywiki is a Quine some patterns will allow it to write to itself then call itself. With local storage, savers and the uri from full wikis or static tiddlers I think I can build a serial multi user system, a checkout system even on top of the single file wiki.

It’s an interesting area to experiment.

Best wishes

Jeremy.

>
> Regards

> Tony
>
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
> To post to this group, send email to tiddl...@googlegroups.com.
> Visit this group at https://groups.google.com/group/tiddlywiki.

> To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/23a835d0-c21c-4173-8f8c-d7fb1d20e1da%40googlegroups.com.

[TonyM]

Jeremy,

I belive what I am looking for is actually very simple, but I stand to be corrected. I want a trigger at the end of the load process so I can build a tiddler with a set of actions triggered without user intervention. Idealy other plugins and global macros will be valid at that time. Within this modals should operate.

By location hash do you mean the tiddler reference and search value on the uri ?

The info mechanisium already seems to provide all we need to respond to how the wiki is linked to.

My manual work around for now would be a single tiddler in default tiddlers that has a big "click me" button that triggers a set of "interactive startup" actions. But of course I can't guarantee this is what the user will do. I would like this trigger automated, and to free default tiddlers to operate as normal.

If automated, it would be good if safe mode bypassed the startup trigger.

By design reveal could be used to alter which actions are triggered according to values found in the info tiddlers.

Regards
Tony

[TonyM]

Folks,

I have found via TiddlyWiki Toolmap this following plugin https://ooktech.com/jed/ExampleWikis/StartupActions/

Which achives what I want.

I missed this because I thought it was incorporated into the new startup actions mechanism. With Startup actions being so importiant to a wikis opperations I would loike to see it extended to opperate as this solution works.

Thanks Jed,

Tony

[@TiddlyTweeter]

TonyM

Nice catch!

I'd assumed that work of Jed's had been superseded! 

Obviously it isn't. You walked the mile to find out.

The problem of naming things? How did you know to do the distance? Serendipity?

J.

[TonyM]

Josiah et al

Using Jeds startup actions I have what I need to force users to give, select or use their existing username before proceeding to the wiki.

I will publish when finished.

I will then design a version with passwords and private encrypted tiddlers

And later tw-reciever passcode for php save and some local storage tricks and check-in / user comitt tricks.

Help would be appreciated, as anyone with my vision could help.

Regards
Tony

[ChristianB]

Hi Tony 

Did you every complete this work ? I found your post when searching on the same problem and was looking to build the same type of plugin ( ie passwords and encrypted tiddlers etc )... Perhaps we can exchange notes

I found that the following code worked - as it hooks into the core frameworks existing hook for  th-opening-default-tiddlers-list  ( a point at which the story list components seems loaded already ).. and its a bit more self-contained than setting a dependency on another plugin

$tw.hooks.addHook("th-opening-default-tiddlers-list",function(list) { 

   $tw.modal.display("Logon",{event:"tm-modal"});

    return list; 

});

 

The first parameter to $tw.modal.display  is the tiddler you want launched

Cheers

CB

[TW Tones]

Christian,

Are you referring only to the startup actions part, or the larger picture of controlled login?.

Your solution sounds handy but unfortunately, I do not know how to implement it. Do I understand correctly this your snipit launches the tiddler "Logon" in a modal?

That would be elegant, 

• Can you show me how to put this in a wiki
• Can you show me how to package it with tiddlers or a plugin?
• Must it be a modified edition with a core change?

If you are interested in collaboration on serial edit, I am ready and willing with a lot of prior research in my head.

Regards

Tony

[ChristianB]

Hey Tony,

Are you referring only to the startup actions part, or the larger picture of controlled login?.

Interested in what you have done or designed from a controlled login potentially. Lets take a look at collaborating.

 

• Can you show me how to put this in a wiki

Yes - I've attached a .tid file for the example i was playing with to see if it worked - just change the name of the tiddler you want launched ( in this attached example it is the tiddler called "Welcome" ). 

• Can you show me how to package it with tiddlers or a plugin?

When you import it into your wiki you can change the name and add to a plugin same as you would normally build one ( eg I've used the  tinka plugin  in the past)

• Must it be a modified edition with a core change?

No the hook logic is already part of the core. All you need is the tiddler attached here and the tiddler you want to launch as a modal.

Cheers

CB 

[ChristianB]

Having errors with posting the file - so trying json format instead

[TW Tones]

Christian

Great I need a collaborator on this one. It 1030pm here in Sydney Australia so tomorrow I will try it and put some notes together.

Perhaps we start a new thread so this does not stay active now we have a couple of answers for startup actions.

I will private message you to discuss the best way forward on the separate login process.

Regards
Tw tones/tony