[RQt-devel] "super" and "this" within scope of callbacks

[Michael Lawrence]

On Wed, Aug 11, 2010 at 9:13 AM, John Verzani <verzani at math.csi.cuny.edu>wrote:

> When defining classes and setting methods (qsetClass, qsetMethod) the
> environment has the object "this" and "super" available to it. Would this be
> possible within a callback set by qconnect? In RGtk2 and tcltk there is a
> way to get the object within the callback without having to use global
> variables or pass that object in through user.data.
>
> E.g., something like this
>
> b <- Qt$QPushButton("click me")
> qconnect(b, "pressed", function(...) print(this$text))
>
> It is easy enough to hack qconnect to add in "this" to the environment of
> the handler, but I'm not sure how "super" would be done.
>
>

I agree that it would be convenient to have a pointer to the sender. I don't
like the idea the idea of using 'this' though. Usually, my signal handlers
are a method in another class, so 'this' would conflict. Also, conceptually
it does not make sense, as the handler is usually not a method of the
sender. Same with super.

The reason Qt does not pass the instance to the handler is that the handlers
are methods that should be invokable even when there is no signal emission.
Also, the handler is always a closure, with the enclosing "environment"
being another instance that can easily hold a reference to the sender. This
works well for me, although I can see that a simple Hello World application
might run into some difficulties. Or cases where a slot is connected to many
signals, but then the protected QObject::sender method is available for
those using a class. Even then, many signals provide additional arguments
that make the sender irrelevant.

We could add a 'sender' variable to the enclosure. However, qtbase is in
some ways extending the R language by adding the 'this' and 'super'
keywords. If possible, we should limit the number of keywords. Also, an
arbitrary R function is distinct from a method, which is by definition
enclosed within an instance that essentially contains the 'this' and 'super'
objects. I would rather not mess with the enclosing environment of a signal
handler.

What if we tried to bring things back towards GTK+, C# events, etc, and just
have the sender passed as the first argument? Obviously, we would not want
this in many cases, so it would need to be an option that is off by default.


qconnect(b, "pressed", function(x) print(x$text()), sender = TRUE)

Would this work?
Honestly, my original plan was just to have people use the user-data. If
they need additional user-data, perhaps it is time to start thinking about a
class.

Thanks,
Michael


> --
> John Verzani
> Chair, Department of Mathematics
> College of Staten Island, CUNY
> verzani at math.csi.cuny.edu
>
> _______________________________________________
> Qtinterfaces-devel mailing list
> Qtinterfaces-devel at lists.r-forge.r-project.org
>
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20100811/eabf4633/attachment.htm>