[RQt-devel] recent smoke update

[Deepayan Sarkar]

On Wed, Jan 20, 2010 at 11:11 AM, Michael Lawrence
<lawrence.michael at gene.com> wrote:
> Well, the paper was a little tough for me to grok. But anyway, I think we
> need a consistent type conversion policy. When Qt always treats a class as a
> pointer (e.g. QObjects), it's pretty clear that we need to do the same. For
> value types, it's more complicated. Qt uses values to avoid the
> complications of memory management (as with QImage) or to avoid memory
> allocation overhead for small types (like QPen).
>
> From the R user's perspective, memory management is largely irrelevant. But
> given the choice of an opaque pointer or a native R type, I think the user
> would choose the latter. However, I agree with you that there is not always
> such an obvious mapping. QImage is a good example. Would the user really
> expect a huge matrix of pixels? The primary use of a QImage is to display
> it, not to manipulate its pixels, but the same is not true for a QMatrix, or
> QRect, etc. For those classes, the primary interest is in the values (the
> parameters of QMatrix, the coordinates of the rectangle). There it may be
> convenient to perform the conversion up-front, and thus making the interface
> tighter between R and Qt.
>
> That said, there may be cases where one does not want to perform the
> conversion. The collection types (QMap, QList, QVector, etc) have fairly
> obvious analogs in R vectors. The problem is that there is overhead to the
> conversions. If the collection is large, the user may wish to pass opaque
> pointers.
>
> In theory, it's possible to make this optional. That is, the user could as
> part of a MethodCall request that high-level conversion be avoided. This
> would not be that hard to implement. The qinvoke() function could take an
> extra parameter (.convert or something) that would tell the MethodCall
> object to avoid special type handlers for the return value.
>
> I will say that I've never encountered a case with RGtk2 where the
> collections are too large to convert. But this Qt interface is more general
> and so it might come up more often. I think I'll wait for a use-case.

Sounds good.

Just to be clear, when you convert to a native R object, would they
still have a class indicating that they represent something from Qt?
So Qt$QFont() would be a R list, but with class "QFont"?

-Deepayan