[texworks] SCRIPTS: TW.ui

[Paul A Norman]

Thanks Stefan,

>You could try calling retVal=dlg.exec().

I didn't even try that as I had got to thinking that none of the
functions would work from widgets.

It does work, solves the modal issue.

Makes me think again about haveing a webView widget as an optional module.
We could achieve a lot of this sort of thing potentially and avoid the
lack of  Q_INVOKABLE  all around the place.

They list functions that can be called as "pubic slots" as well.

e.g QWideget provides  a whole lot of window functions publically-script wise

This works,

colourDialogue = TW.createUIFromString(colourDialogueXml, null);
	
	colourDialogue.setHidden(true);

  TW.warning(null,"Not Functional Yet","Sorry, doesn\'t Insert Anything Yet");

	retVal = colourDialogue.exec();

Dialogue doesn't show until after the warning message, may be a
flicker of course.

I'll sleep on the rest for now, before posting issues.

Paul

On 27 May 2010 22:50, Stefan Löffler <st.loeffler at gmail.com> wrote:
> 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
>