[RQt-devel] recent smoke update

[Michael Lawrence]

Potentially interesting paper attached. Haven't read it yet.

On Wed, Jan 20, 2010 at 6:54 AM, Michael Lawrence <michafla at gene.com> wrote:

>
>
> On Wed, Jan 20, 2010 at 1:39 AM, Deepayan Sarkar <
> deepayan.sarkar at gmail.com> wrote:
>
>> On Mon, Jan 18, 2010 at 12:11 AM, Michael Lawrence
>> <lawrence.michael at gene.com> wrote:
>>
>> > Ok, this looks interesting. After we fix this bug though, I think we
>> need to
>> > make qtbase convert QColor to the high-level integer matrix as returned
>> by
>> > qcolor(). And QPen might belong as an R list, as I think you were doing
>> > before. In general, I think the value types like QColor, QMatrix, etc,
>> > should be converted to native R structures, instead of opaque external
>> > pointers. The functions already exist for this; they just need to
>> integrated
>> > better into the smoke stuff.
>>
>> Sure, but could you outline the advantages? What I mean is that even
>> for things with obvious analogs, the Qt pointer representation may
>> give some useful freebies; let's say QImage::invertPixels(). I see the
>> point in making it into a native R structure, but wouldn't it be
>> better to have access to both at the user level? So I'm thinking of
>>
>> im <- Qt$QImage("foo.png")
>>
>> returning a "QImage", and have user-level as.raster() and as.QImage()
>> methods for conversion.
>>
>>
> 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:
>
> mat <- QMatrix()
> mat[1,2] <- 2
> mat <- mat$invert()
>
> Where 'invert' is implemented by Qt.
>
>
>> Is there a technical advantage (like more stability) to not allowing
>> something like this for the value types? What about things that don't
>> have an obvious analog?
>>
>>
> 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.
>
>
>> -Deepayan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20100120/1220df59/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a12-matthews.pdf
Type: application/pdf
Size: 945257 bytes
Desc: not available
Url : http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20100120/1220df59/attachment-0001.pdf