[texworks] SCRIPT Prototype: A work in progress - LaTeX xcolor colour names dialogue

[Paul A Norman]

Ok, after  looking into
http://doc.qt.nokia.com/4.3/qtscript.html#using-signals-and-slots

I think that I have a solution for my Colour Dialogue that will not
involve the clipboard.
Implementation - that is for the new day |-)

I can connect QTScript functions and objects to QWdiget slots directly.

Didn't expect so many to work!

Another thing I didn't expect was that simple data types will return
and map to QTScript functions with more than one variable, more
complex ones, I hoped would cast to QVariant as the documentation
suggests ("Other types will be wrapped using
QScriptEngine::newVariant()."), don't.

This worked for me:

colourDialogue = TW.createUI(__FILE__.replace(".js",".ui"));
	
function handleTableItem(intRow,intCol)
 {
    TW.warning(null, "Trial, Row - Column",  "Row - " + intRow + " ~
Column - " + intCol);
  }

colourTable_svgnames =
TW.findChildWidget(colourDialogue,"colourTable_svgnames");

colourTable_svgnames.cellDoubleClicked.connect(handleTableItem);

But anything based on things like..

colourTable_svgnames.itemDoubleClicked.connect(handleTableItemVariant);

which would return a more complex object like QTableWidgetItem - does not.

(I do the appropriate disconnects.)

So sometimes the variables expected can be mapped, other times for as
yet unclear reasons they do not.

Paul

On 28 May 2010 17:34, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> Am 2010-05-28 01:14, schrieb Paul A Norman:
>> I have been involved in seeing php used as a scripting language to
>> Delphi projects. There quite often more generic top level  objects are
>> exposed to script, that enabled script to do virtually anything that
>> the host programme can do. I realise there may be real security fears,
>> but defining a safe and  a stable approach to this might enable things
>> to happen more easily.
>>
>
> We may of course be able to provide php as additional scripting language
> (if it provides all the interfaces we need), but this wouldn't change
> the issue at hand. What is exposed and what isn't is not a question of
> the scripting language - this is done in a central point in the C++ code
> that all scripting instances share. The only thing that changes between
> different scripting languages is _how_ data needs to be converted, _how_
> functions are called, etc. But _what_ is available is always the same.
>
>> For example if such a thing were done, could script create new
>> widgets/forms etc on the fly?
>> In the example I just quoted that was possible, as generic functions
>> were prepared and made available to script, and some of the exposed
>> objects in the executable provided those resources any way.
>>
>
> Creating new widgets directly is not quite trivial, as they don't tie in
> too well into the framework we use for exposing objects to scripts, AFAIK.
> You should be able to create new widgets with the Ui loader, though. In
> the worst case you'd have to create them in a dummy wrapper dialog. So
> in that case, we'd only need to provide a way to reparent those widgets
> so you can effectively "cut them out" of the dummy and "paste" them
> wherever you want. Note that this doesn't change the situation for
> predefined top-level dialogs (such as the color dialog) as they can't be
> wrapped in a dummy - so for them we'd still need the functions mentioned
> below.
>
> Cheers,
> Stefan
>