[texworks] SCRIPTS: TW.ui

[Stefan Löffler]

Hi,

Am 2010-05-27 12:12, schrieb Paul A Norman:
>>> Do the dialogues automatically pass from scope and memory when the
>>> script stops, or should I free them in some way? Or is that where the
>>> parnet comes in?
>>>       
>> Dialogs should not be destroyed automatically when the script ends. In
>> fact, I think that at the moment, they are never destroyed (until the
>> application terminates or the parent (if any) is destroyed). This is
>> something Jonathan should fix - hopefully together with the fact that
>> dialogs are shown automatically. Could you post an issue for these two
>> issues on GC?
>>     
> Yep, I have attached a zip with a script that might illustrate the
> problem. Any one wnating to see what this is about, put the unzipped
> files in a (sub)Script directory.
>
> The .ui was set to modal in Qt Designer, but that behaviour is
> currently ignored, and UI show that it is so - the form reports to
> script that it si modal, but I use a warning box form script to
> display that while the form is still open!
>
> That menas that a Script finishes running, while the dialogue has only
> just opened and no user input can be processed by the script at all as
> yet, unless i have yet to find how to safely put  the script into some
> sort of while(){loop} and monitor the situation until the dialogue
> form closes? - a virtual modal dialogue?
>   

You could try calling retVal=dlg.exec(). This would be the normal way to
show a modal dialog, and I'd expect it to still work. In fact (as I
pointed out in my previous mail) I wouldn't put any show command on the
C++ side of it all. IMO, createUi() should only create the object in
memory, leaving all interactions, further initializations, showing, etc.
to the script.

> Another problem is that Qt is not using as many properties as I expected.
>
> Many values of useful things have to be returned by a function call.
> However I have no slot to work with, or enabling to call .ui widget's
> own Qt functions as yet from script.
>   

Slots will hopefully come in the (not too distant) future. First I need
Jonathan to commit some of my patches, though, so we can do more testing
and my working copy of the sources doesn't diverge too much from the
official ones.
As for calling functions, this is a general limitation of Qt scripting.
You can only call functions from scripts that are either public slots,
or declared as Q_INVOKABLE (which is not very common in the Qt sources,
AFAIK). And you can access properties, of course.

I know that for some widgets (particularly those that are dealing with
some sort of list) the methods of interaction are very limited, or even
non-existent. I'd actually consider this a Qt bug (the important
functions should be Q_INVOKABLE), and this should be reported to the Qt
developers (if it hasn't been already).

We may need to work around this, though, for the time being. If you (or
someone else) have time, you could perhaps compose a list of functions
you'd like to see available to scripts, so we'd have a starting point
from a script author's perspective. Just keep the list as short and
simple as possible.

If I have time, I'll look at your scripts later and maybe comment in
more detail.

HTH
Stefan