Potentially interesting paper attached. Haven't read it yet.<br><br><div class="gmail_quote">On Wed, Jan 20, 2010 at 6:54 AM, Michael Lawrence <span dir="ltr"><<a href="mailto:michafla@gene.com">michafla@gene.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;"><br><br><div class="gmail_quote"><div class="im">On Wed, Jan 20, 2010 at 1:39 AM, Deepayan Sarkar <span dir="ltr"><<a href="mailto:deepayan.sarkar@gmail.com" target="_blank">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 Mon, Jan 18, 2010 at 12:11 AM, Michael Lawrence<br>
<div><<a href="mailto:lawrence.michael@gene.com" target="_blank">lawrence.michael@gene.com</a>> wrote:<br>
<br>
</div><div>> Ok, this looks interesting. After we fix this bug though, I think we need to<br>
> make qtbase convert QColor to the high-level integer matrix as returned by<br>
> qcolor(). And QPen might belong as an R list, as I think you were doing<br>
> before. In general, I think the value types like QColor, QMatrix, etc,<br>
> should be converted to native R structures, instead of opaque external<br>
> pointers. The functions already exist for this; they just need to integrated<br>
> better into the smoke stuff.<br>
<br>
</div>Sure, but could you outline the advantages? What I mean is that even<br>
for things with obvious analogs, the Qt pointer representation may<br>
give some useful freebies; let's say QImage::invertPixels(). I see the<br>
point in making it into a native R structure, but wouldn't it be<br>
better to have access to both at the user level? So I'm thinking of<br>
<br>
im <- Qt$QImage("foo.png")<br>
<br>
returning a "QImage", and have user-level as.raster() and as.QImage()<br>
methods for conversion.<br>
<br></blockquote></div><div><br>There's nothing preventing us in general from calling Qt methods on R-level structures. Take QMatrix for example. It maps to a 3x2 R matrix with a special class c("QMatrix", "RQtValue", "RQtObject"). Then the code will be smart enough to allow:<br>
<br>mat <- QMatrix()<br>mat[1,2] <- 2<br>mat <- mat$invert()<br><br>Where 'invert' is implemented by Qt.<br> <br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is there a technical advantage (like more stability) to not allowing<br>
something like this for the value types? What about things that don't<br>
have an obvious analog?<br>
<font color="#888888"><br></font></blockquote></div><div><br>Well, there are certainly cases like QImage that should probably remain external. There's too much data there to be copied around. Basically, except for QString and maybe QByteArray, any class that uses the shared pointers should probably remain as a pointer.<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>
</blockquote></div><br>