[texworks] Scripts: Globals

[Paul A Norman]

Thanks Stefan,

Thought it was time to nail a few things down, and pass my
understanding  past someone to make sure I was getting  right on a few
things.

Hope to use all this recent  info gathering for "the common good" -
got a couple of things in in the pipeline.

Just another quick one, - will scirpts with ui dialogs be making it
into ver 0.4 stable release?

Paul

On 4 November 2010 01:11, Stefan Löffler <st.loeffler at gmail.com> wrote:
> 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
>