[texworks] Scripts: Globals

[Paul A Norman]

On 2 November 2010 19:56, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> Am 2010-11-02 01:24, schrieb Paul A Norman:
>>>> What is the difference between
>>>>
>>>>     TW.app.setGlobal(QString,QVariant);
>>>>
>>>> and
>>>>
>>>>     TW.script.setGlobal(QString,QVariant);
>>> Practically, there is not very much difference at the moment -
>>> conceptionaly, there is, though.
>>> With TW.script...., things are stored with the script. I.e., the data
>>> only exist as long as the script does. If the script is reloaded (e.g.,
>>> because it was moved, or the file changes, ...), the data is thrown
>>> away. Note that "reload script list" _should_ be intelligent enough to
>>> reload scripts only when necessary.
>> What are the advantages of storing data globally in TW.script.xxxGlobal
>> If a script's own global will do the trick anyway(?) - is this
>> conceived for some future thing when it will be possible to run
>> scripts con-currently and use this mechanism to pass objects between
>> them while active?
>
> Note: Storing data globally is done with TW.app, not TW.script.
> IIRC, historically TW.app globals were added first. Only later, the
> TW.script object was actually exposed to scripting and globals could be
> assigned to that.
> The general idea indeed is that TW.app globals are really global
> (accessible everywhere), whereas TW.script globals are "local" to the
> script in question, but allow to pass data between different invocations
> of the same script.
>
> One thing I should emphasize (and forgot to before), though, is that
> scripts in Tw live longer than you might think. Under normal
> circumstances, they are loaded when Tw starts, and are unloaded when it
> ends (provided you don't change and refresh them in between). This is
> entirely different from their execution (which only lasts a relatively
> short time, e.g. when the user clicks the menu item).
>
Ok, so

1.  A TW.script.xxxGlobal is paired with its creating script and is
only available from that script if invoked again during the current Tw
Editing session.

2. TW.app.xxxGlobal is settable from any script, and available to any
script running in the current Tw editing session.

This suggests we may find a beforeApplicationShutsdown hook useful for
facilitating the persisting of anything that needs to be committed to
disk from Globally script set/updated information? And an
ApplicationStarted as suggested on the GC already as an opportunity to
reload such persisted data/info.

And "(provided you don't change and refresh them in between)" suggests
a hook so that script.globals can be captured before reloading?  And
reloaded after script reloading?
 BeforeScriptReload AfterScriptReload - or just use App.Globals and
not Script.Globals? Or will this just be so infrequent for the normal
user that it does not matter perhaps?


>>>> And is a QTScript object able to be passed as a QVariant?
>>> I just tested your code fragment below and yes, it seems so.
>> Ok, I asked because it was not working for me with more complex
>> objects including functions, I'll revisit it and check my work again
>> carefully.
>
> Hm, functions may be a different matter as they don't convert to a
> simple Qt type (see
> http://doc.trolltech.com/4.5/qscriptvalue.html#toVariant). As such, I
> wouldn't expect functions to work, unfortunately. Note, though, that
> there is no safe way to use such a global in other scripts (maybe even
> written in another scripting language), so it's kind of beside the
> point, at least for TW.app globals. Globals are primarily intended to
> store/transfer data (as in integers, strings, arrays, ...), not to
> transfer code.
> I'm not 100% sure, though, since there might be some specialties
> involved in how JavaScript handles methods (something to do with the
> prototype, I think, but I'm no expert here).
>
> Note that you could store the string that goes into eval() in a global,
> though. I'm not sure if that's what you want (speedwise, for instance).
>

I think speed wise that would be quite good and effective - thank you
for the suggestion.

> Interesting. An ApplicationStartup hook would definitely be more suited
> for that ;). (Note that in that case, you wouldn't really need to run
> your checks (though checks are always a good idea ;)) as there aren't
> any globals present at startup)
> Regarding the function problem, see above. You may need to do
> eval(TW.app.getGlobal(...)).
>
>> >From your knowledge of the overall framework, could a whole complex
>> (memory-wise -> large) dialog be safely/**reliably** stored in this
>> way?
>
> Um, that's a tough one. The size in memory shouldn't be a problem. What
> I'm a little more concerned about is the complexity. A dialog usually
> isn't just one object, it contains separate widgets, etc. Overall, I'd
> expect it to work, though. Note that if you want to reuse the dialog,
> you may need to reinitialize some data (e.g., clear all fields the user
> should edit) during each run of the dialog. Note also that you should
> pass NULL (or any equivalent) to the parent parameter of createUI...()
> to avoid the destruction of the dialog when its parent is closed.
> It's been a while since I've actively worked on the code, though, so
> there may be some unpleasant surprises that slipped my memory - like
> some garbage collection routines somewhere...

So again use your thought of storing strings, in this case load the
Qt_dialog.ui as a string and store globally  and
TW.createUIFromString(QString) it as needed?

I think that would be very effective. It would reinitialize the dialog
each time wiping out user information.

So can we access the underlying xml of a Qt_dialog while it is running
or is it not rendering back changes and user choices to xml once it is
loaded from disk? - I think we could capture any needed settings
through a custom close() of a dialog, and set them to disk/ or Global
for reloading later depending on degree of  need for re-use. (some
things the user might appreciate seeing as they last left them.)

Can a script call or chain to another script?

Some questions please derived form the TW debugger---

For some time I have wondered about these top level components:-

gc - what is that please?

Object - ?

Function - ?

Array - is that EMCA or a Qt thing

String -  is that EMCA or a Qt thing,

and Boolean

Date - does that follow the Qt help info?

Top.TW

makeConnection(QObject*,QString,QObject*,QString)

      Is that bor slots?

objectName ?


Top.TW.app.unixSignal(int)

     Does that potentially send a WIndows message as well?

yield()

   Does that release processing time back to the application / System
? Sort of like application.preocessMessages ?

Paul
> HTH
> Stefan
>