It would be cool if we had some kind of library system for scripts: These script libraries should be run once when…
It would be cool if we had some kind of library system for scripts: These script libraries should be run once when the scripting context is initialized and could be used to add helper functions.
This would simplify a lot of scripts, as a lot of code needs to be duplicated in separate scripts atm.
On top of that it would be great if scripts had a way to specify which libraries it uses, so it doesn’t crash if they are missing.
]]>« Pierre Hébert you said the new draw implementation might enable easy animating. Any progress / insights on that? (Previous Post)
(Next Post) Rather cool »
D5 Creation
< ![CDATA[
I tried to do something like that some time ago, but I stopped because all JS wasn’t supported (I don’t remember the exact reason)
]]>
< ![CDATA[
Benoît de Chezelles
well I had a script that did that too. The thing is, if a script requires another script (the library) which requires a third script (the library loader) then it produces more overhead than putting all in one script. If this is an official built-in feature though, it could be a lot simpler to use.
]]>
< ![CDATA[
The easiest way to do that would be to select a script to be run at startup (or more precisely at context init). This script would then execute things or put objects in the root object.
There are two possible issues currently.
At the moment there is more than one scripting context: one for the home screen, one for the app drawer, one for the lockscreen and a fourth one for the floating desktop. Care has to be taken that the library can be loaded more than one time. This could change in the future.
The second issue is… well, it isn’t an issue yet. This is rather a question for which I don’t get an answer. I would like to allow some kind of module, an item or group of items that you can export and import somewhere else. Libraries are not friendly with modules as they introduces dependencies and/or code duplication. But since modules are not there yet, that’s not something to care too much about.
]]>
< ![CDATA[
Modules… sounds interesting!
But what I wanted to express is: if a library system is built into LL, a missing library is no problem: a script that would require the library is simply not run (and there should probably be a warning for the user).
]]>
< ![CDATA[
A problem could be if a library requires another library. They either have to specify a priority or the ordering has to be resolved by LL.
Another problem might be that unique names have to be ensured.
]]>
< ![CDATA[
Pierre Hébert you implemented the global context with this in mind, right?
]]>
< ![CDATA[
Yes, and now there could be a single load/unload event that would match the app life cycle
]]>