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

[Paul A Norman]

P.S> I tried sender but it returns 0.

On 29 May 2010 02:16, Paul A Norman <paul.a.norman at gmail.com> wrote:
> 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
>>
>