[RQt-devel] recent smoke update

[Michael Lawrence]

On Wed, Jan 20, 2010 at 11:35 AM, Deepayan Sarkar <deepayan.sarkar at gmail.com
> wrote:

> 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"?
>
>
This is correct. The classes would be QFont, RQtValue (for the $ method),
and RQtObject for the Ops method, %<<% and other operators.

Michael


> -Deepayan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20100120/9cf475c5/attachment.htm