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

[Stefan Löffler]

Hi,

Am 2010-05-28 16:16, schrieb 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!
>   

Yes, this works, but with several caveats! First (and probably less
importantly), connecting to signals only works in QtScript, not in other
scripting languages, as this is nothing we coded but something Qt
provides automatically. Secondly (and more importantly), this only works
as long as the script doesn't pass out of scope. This means this only
works if you call dlg.exec() somewhere down the line. For everything
else, we'll need to wait for "library"-type scripts. This is not
dramatic in the current situation, just something you should keep in the
back of the head.

> 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.
>   

I'm not sure exactly what you mean by "simple data types will [...] map
to QTScript functions with more than one variable".
Anyway, things are a little more difficult, and explaining this requires
some C++ background information. I'll try to clear this up a bit, but if
you're not interested in this you can safely skip the next paragraphs.

Simple data types that are present in both C++ and a scripting language
are converted to one another (e.g., QString <-> native string). As for
more complex data types, there are three variants of them.

First, we have types that can be wrapped in QVariant. See
http://doc.qt.nokia.com/4.4/qvariant.html#Type-enum for a list of
natively supported ones. Here we generally have some more complex data
that is still general, though, such as QDateTime, QPoint, QRect, and
several types of lists. They are not associated with a specific context
(a QTableWidget, for example), but are just general purpose data types
that can be used in a variety of contexts. Note, however, that C++
developers can extend this list of data types wrappable in QVariant,
even at run-time. All these QVariant-wrappable items can be used
directly in scripts.

Second, we have types derived from QObject (see
http://doc.qt.nokia.com/4.4/qobject.html). Most notably, these include
all widgets. But this list is extensible as well, and the TW.* objects
are such derivatives of QObject. All these can also be used in scripts.

Third, we have... everything else. And those are not accessible from
scripts. Among other things, this also includes some helper-classes for
the GUI, such as table items, etc.



> 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 guess you get "undefined" as I did?

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

I hope I could shed at least some light onto this :).

HTH
Stefan