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

[Paul A Norman]

Thanks Stefan,

I was not sure what the casting mechanisms were, but it sure explains
the differenet kinds of behaviour that I am encountering.

Sometimes you can directly assign to a property value, when the
documentation recomends using a set function , but the set function
does not work in Script, but direct assignment does (even when the
property should be a const - it behaves as a public property should in
OOP), and other times it is the other way round, you do need to use a
set function and direct assignment to a property is of course not
supported as a const.  ugh!

Otherwise things are going quite well.

Finding work arounds, but a few brick walls, so I may post to your
request for ideas on Scripting and things that might be done in the
core code to help, once I have properly reflected on things.

Hope to have a working full on xcolor package - colour dialogue up soon.

Just for clarification please I thought we were on QT 4.3, but the
help about on 0.3 version 649
reports as QT Application framework 4.6.0 in the Tw  help/ about, but
>4.3 widgets (like QPlainTextEdit ) do not appear to be available for
scripting at run time.

Paul

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