Lua Startup

[garry23]

David

A thought...

I believe at the moment, the Lua environment's default is to run/load all the scripts on startup.

The thought I have had is this: if there are two scripts loaded, independently written by different people, ie not designed by the same person to run 'together', there must be a risk that these two scripts may clash. For example, if both ran event.keypress etc.

For this reason, would it not be better to have no scripts running/loaded, ie get the user to explicitly load/run. Ideally, being able to tell ML to run script A or B etc on startup, ie a script has a startup flag.

Or have I missed something?

Cheers

Garry

[Walter Schulz]

Or have I missed something?

See To-do list: https://bitbucket.org/hudson/magic-lantern/commits/4955350cc23c/

[garry23]

Thanks Walter 

[dmilligan]

Well, that's not really what is meant by that comment (it's not still a 'todo'). It was superseded by giving scripts the ability to create their own menus.

I don't really have any plans to implement anything like this. That was the point of giving scripts the ability to  manage themselves so to speak and create their own menu/gui. In this manner, scripts become 1st class citizens, and it's basically impossible for an end user to tell the difference between some feature implemented as a script or as a module or something in the core. That is the goal.

With all this power and flexibility, comes the responsibility to the script itself to play nicely with other scripts. This may mean that a script should have a way to be enabled/disabled, but that's something that a script can easily do itself. Plus there's still the issue of scripts playing nicely with other modules and modules playing nicely with other modules (which is still an unresolved issue, though it has been discussed: http://www.magiclantern.fm/forum/index.php?topic=10537.msg118536#msg118536 ), so any sort of conflict management system for scripts should tie into some sort of general system for any ML feature (script, module, or core).

So I think the only real reason to implement some script enabling gui would be to save resources (save memory by not loading the script, and speed up loading time for other scripts). I haven't really seen this to be an issue though, so I'm not convinced it would be worth the effort.

[garry23]

David

I understand what you are saying. I guess we have to live with the following scenario:

1. Coder A writes a script using event.keypress and publishes it
2. Coder B, independently, writes a script also using event.keypress and publishes it
3. Both scripts are loaded, innocently, by user C

In the above, if both scripts were running and on at start up, then there would be a clash (I assume).

I guess the thing to recognise, as you say, that scripters should always put a 'script on/off' in their menus, ie to allow users, like C, above the ability to choose the script to run at any given time., ie all scripts loaded, but only one running at a given time.

Cheers

Garry

[dmilligan]

In that particular situation, there isn't necessarily a n explicit conflict. Almost all of the example scripts use key press events in some way and they all coexist just fine. There's no technical limitation that prevents multiple scripts from listening to key press events at the same time. There are all sorts of things listening key press events besides just scripts. This is why there's a return value, and why you need to consider the implications of it in relation to how other things listening to key presses will behave.

That's not to say conflicts aren't possible, but the cause of conflicts is likely to actually be more conceptual in nature, for example two different bracketing scripts that fight each other over setting exposure parameters.

[garry23]

David

Once again thanks for the education.

Cheers

Garry