[texworks] New script features

[Stefan Löffler]

Hi,

Am 2010-04-26 15:15, schrieb Paul A Norman:
>>> In any case, it would probably be nice to have a runScript()
>>> function that does what one would expect of it (i.e., as Paul suggested,
>>> run a script identified by some name/label, rather than a TWScript
>>> object we currently have no way of obtaining a handle to).
>>>       
>> Yes, that might be nice. Though it raises questions of context: does the new
>> script execute in its own separate context, or can it be run within the
>> current script's context (allowing sharing of globals, etc)? I suppose that
>> could only work if the scripts are in the same language....
>>
>>     
> There is an interseting cross-platform,  cross-language, cross-compile
> opensource project I've bneen following a bit that has devised a means
> of running ruby, php, python, JavaScript and their own object system
> together, quite facinating. You can actually mix language in scripts.
>
> From: http://www.linuxjournal.com/article/10437 ...
>   

That is indeed fascinating - though I don't think something exactly like
this will hit Tw anytime soon ;). If I understand the article correctly
(I only browsed through it so far) they embed the code in other
documents (html in this case). This means that they effectively have to
parse their source for such code blocks and then distribute them to the
different scripting interpreters. In our case, you'd still have separate
files - although I would very much like the idea that different scripts
can communicate with each other somehow.

>>> To make a long story short, here's a list of things I'd like to see in
>>> scripting (and for the most of them I even have an idea of how to code
>>> them ;)):
>>> 1) Give scripts a way to obtain a handle to their TWScript obj (the
>>> pointer is in TWScriptAPI already, anyway)
>>>       
>> That's easy, I guess; what do you expect it to be used for?
>>
>>     
> I am also fascinated by this one, what have you got up your sleeve for
> us here Stefan?
>   

Nothing in particular, really. It's just a starting point, so that we
have a way for scripts to access the TWScript object, which is sort of
the script's alter-ego in the C++ realm. We'll have to see what we can
implement there, but ultimately I'm aiming for some sort of
representation of the script's functions & properties in C++. This would
be a prerequisite for different scripts (of different languages) to
interact with one another - through the C++ level.

>>> 2) Provide a per-script list/hash of "globals", i.e. of QVariant
>>> objects; this would give us the possibility to pass data between
>>> successive invocations of the same script (need to think about data
>>> lifetime here; possibly need to find a way to clone objects)
>>>       
>> How about also having an application-wide collection of such globals, so
>> that it's possible for a group of related scripts to share data?
>>
>>     
> Introduce savable/persistent namespace objects that could be caled
> from any script?
>   

Hm, well, I wasn't thinking quite that far. In particular, I was not
thinking of whole objects but simply of values (numbers, strings, lists,
etc.). I also wasn't thinking about saving them, just about making them
persistent during the lifetime of the current Tw app (i.e., when you
close Tw, the data will be gone). But of course, ultimately we could
save the data as well. Calling functions probably would be done by
another approach, but it's on the list (nr. 3).

>>> 3) Add the possibility to call functions defined in a script from C+
> Would we need a standarised script format for such?
>   

I don't know yet, really. Ideally, no. Ideally, you would call some
method to register a script function as callable. That would probably
need the function's name and arguments, depending on the scripting
language. So ultimately, this will probably have to be language-specific.
One implication I should emphasize in this context is that when C++ is
able to call a script's functions, this would automatically imply that
in principle, scripts would be able to call (other) scripts' functions
(since they can call C++ functions already, which could then in turn
call the appropriate script function).
Note, however, that these are just ideas. Not completely arbitrary ideas
- I do have some plan in mind about implementation. But if this will
actually be possible in the end and how it will look like is still unclear.

>>> 5) Introduce a new script type ("multi", "mixed", ... ideas welcome)
>>> that defines only functions. There is one special function (e.g. init())
>>> that gets called when the TWScript object is created. Its purpose is to
>>> register menu items, toolbar items, hooks, ... (whatever comes to mind).
>>> Each of them gets connected to a function provided by the script.
>>>       
>> ScriptType: library
>> Defines functions for use as hooks, callback slots, whatever....
>> No need for a magic init() function: the "main program" of the script is
>> executed on load, and can do whatever setup is desired.
>> Or maybe we should have both initialize() and terminate() functions; the
>> latter provides an opportunity for the script library to do last-minute
>> things before the app shuts down, such as saving its globals to a .ini file,
>> to be read by initialize() next time it is loaded.
>>
>>     
> " saving its globals to a .ini file"  -- perhaps JSON if the scripts
> need to read it, or would Tw handle this reinstantation (sp)?
>   

I guess to do this in a portable way, we'd handle this in Tw.
Particularly so, because QVariants can easily be serialized, AFAIK.

-Stefan