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

Paul A Norman paul.a.norman at gmail.com
Fri May 28 16:16:18 CEST 2010

Ok, after  looking into

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 =


But anything based on things like..


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.


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

More information about the texworks mailing list