[texworks] Scripts: Globals

[Stefan Löffler]

Hi,

Am 2010-11-03 08:19, schrieb Paul A Norman:
> 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.

Yup.

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

Yup2.

> 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.

Sounds good. I'm not sure how easy an ApplicationShutdown hook is to
implement, but by all means add it to the hook request issue.

> 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?

Normally, this should not matter. IIRC, the script object in Tw is only
recreated (and thereby the globals info destroyed) if the script type
(standalone/hook) has changed (or of course the file has been added or
deleted). In all other cases (name changes, code changes, etc.) the
original object (and with it the globals data) should be retained. So
this could cause a little bit of inconvenience during development, but
when using a final script this shouldn't be an issue.

>> 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.

Yeah, that would work, too. I'm not sure if it is very useful, though,
in most cases. Normally, I'd expect the xml data to be easily available
through other channels (e.g., hard-coded in the script, or in an
external file), so "wasting" additional space in memory seems rather
pointless. But there probably are occasions where this is handy. Just
remember that Tw aims at being rather lightweight, so if a dozen scripts
start loading a complex dialog files this can significantly increase the
memory consumption of Tw.

> 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.)

No, the xml file is used essentially as a kind of template which the
dialog is then dynamically modeled after. There is no data
synchronization. But of course you can query data from the dialog from
the script after the dialog was closed, store that somewhere, and
reinitialize the next time.

> Can a script call or chain to another script?

Not at the moment, but this is planned for the future (see "library"
scripts).

> Some questions please derived form the TW debugger---
>
> For some time I have wondered about these top level components:-

I'm no expert in the internals of Qt, but I think this is the way
QtScript defines common objects of the JavaScript language.

> gc - what is that please?

I'd guess this is a garbage collector...

> 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?

These all are standard EMCA objects, AFAIK. So basically anything for
which you can say "new ...()".

> Top.TW

I've never seen the "Top." prefix, but other than that this is exactly
the TW object you can use in the script. If you look at its children,
you'll see among other things app, target, script, ...

> makeConnection(QObject*,QString,QObject*,QString)
>
>       Is that bor slots?

Yes. I recommend using it with caution, if at all, however, for anything
other than experimenting. It should be possible to connect to signals of
modal dialogs if they are destroyed at the end of the script. Signals of
anything that can outlive the script should not be connected (the script
won't be restarted to respond to a signal; if it's still running, it
should be OK).

> objectName ?

TWScriptAPI (the C++ class of the TW object) is derived from QObject so
it can easily be handled. Every QObject class has an objectName. It's
currently not used, though.

> Top.TW.app.unixSignal(int)
>
>      Does that potentially send a WIndows message as well?

I have no clue what it does. It doesn't seem to be documented in the
official Qt docs, and it doesn't come from us.

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

Exactly. It's defined in TWScriptAPI.cpp as
    QCoreApplication::processEvents(QEventLoop::ExcludeUserInputEvents);
It's primarily useful for displaying information to the user during long
operations. If yield is not called, any updates to the display are
queued and probably executed much later. To process these update
requests, you can call yield. Note that user input events (keyboard,
mouse, ...) are deliberately excluded so the user can't, e.g., close a
window that is essential to the script.

Phew, quite a list of questions ;).
HTH
Stefan