<br><br><div class="gmail_quote">On Wed, Jan 20, 2010 at 11:35 AM, Deepayan Sarkar <span dir="ltr"><<a href="mailto:deepayan.sarkar@gmail.com">deepayan.sarkar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Jan 20, 2010 at 11:11 AM, Michael Lawrence<br>
<div class="im"><<a href="mailto:lawrence.michael@gene.com">lawrence.michael@gene.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> Well, the paper was a little tough for me to grok. But anyway, I think we<br>
> need a consistent type conversion policy. When Qt always treats a class as a<br>
> pointer (e.g. QObjects), it's pretty clear that we need to do the same. For<br>
> value types, it's more complicated. Qt uses values to avoid the<br>
> complications of memory management (as with QImage) or to avoid memory<br>
> allocation overhead for small types (like QPen).<br>
><br>
> From the R user's perspective, memory management is largely irrelevant. But<br>
> given the choice of an opaque pointer or a native R type, I think the user<br>
> would choose the latter. However, I agree with you that there is not always<br>
> such an obvious mapping. QImage is a good example. Would the user really<br>
> expect a huge matrix of pixels? The primary use of a QImage is to display<br>
> it, not to manipulate its pixels, but the same is not true for a QMatrix, or<br>
> QRect, etc. For those classes, the primary interest is in the values (the<br>
> parameters of QMatrix, the coordinates of the rectangle). There it may be<br>
> convenient to perform the conversion up-front, and thus making the interface<br>
> tighter between R and Qt.<br>
><br>
> That said, there may be cases where one does not want to perform the<br>
> conversion. The collection types (QMap, QList, QVector, etc) have fairly<br>
> obvious analogs in R vectors. The problem is that there is overhead to the<br>
> conversions. If the collection is large, the user may wish to pass opaque<br>
> pointers.<br>
><br>
> In theory, it's possible to make this optional. That is, the user could as<br>
> part of a MethodCall request that high-level conversion be avoided. This<br>
> would not be that hard to implement. The qinvoke() function could take an<br>
> extra parameter (.convert or something) that would tell the MethodCall<br>
> object to avoid special type handlers for the return value.<br>
><br>
> I will say that I've never encountered a case with RGtk2 where the<br>
> collections are too large to convert. But this Qt interface is more general<br>
> and so it might come up more often. I think I'll wait for a use-case.<br>
<br>
</div></div>Sounds good.<br>
<br>
Just to be clear, when you convert to a native R object, would they<br>
still have a class indicating that they represent something from Qt?<br>
So Qt$QFont() would be a R list, but with class "QFont"?<br>
<font color="#888888"><br></font></blockquote><div><br>This is correct. The classes would be QFont, RQtValue (for the $ method), and RQtObject for the Ops method, %<<% and other operators. <br><br>Michael<br> <br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
-Deepayan<br>
</font></blockquote></div><br>