[RQt-devel] direction of Qt

[Michael Lawrence]

We can stick with Qt until the GTK+ stack has obvious advantages. My email
was more of a forecast of this happening; it has not happened yet.

The good thing is that the infrastructure is already there for GTK+,
although the RGtk2 code generator needs to be updated to the new API
description standard (which ironically I helped to define). That would
greatly facilitate, say, binding the Clutter canvas (which still has a ways
to go to match QGraphicsView for our needs). GooCanvas is an existing
Cairo-based canvas library that was more of a proof-of-concept and is in
maintenance-mode.

Michael

On Sun, May 22, 2011 at 3:46 PM, Dianne Cook <visnut at gmail.com> wrote:

> Hi Michael,
>
> It's disappointing to hear the synopsis about qt!  The major advantage, as
> outline by you, for qt, was its speed of drawing large amounts of
> information. Otherwise we would have stuck with gtk.
>
> Would it be feasible to convert cranvas to use gtk widgets? Do you think?
> (Why would it be called goocanvas?)
>
> How is this going to affect your summer work, with visnab?
>
> cheers,
> Di
>
> On May 22, 2011, at 12:10 AM, Michael Lawrence wrote:
>
> > Hi guys,
> >
> > Recently, Nokia has been making some statements about the course of Qt
> development. Frankly, it is pretty concerning. They have shifted focus to
> the "Qt Quick" framework, which is meant to be "designer-oriented" and
> driven from a declarative Javascript-based language called QML. This means
> that previous "core" classes like QWidget, the whole QGraphicsView framework
> upon which qtpaint is based, and the existing (fast) QPainter
> implementations, are now in "maintenance mode" at best. There will be a move
> to mobile-friendly OpenGL ES paint engines, which are way slower than the
> previous OpenGL implementation for many of the drawing modes in qtpaint. In
> fact, the GL engine currently used by qtpaint has been officially abandoned
> by Nokia (while we can volunteer to maintain it, it's probably better to
> just scavenge it for its fast paths). While minor, support for SVG output
> has also been dropped.
> >
> > As far as developing a GUI with R (via qtbase), one can either use the
> maintenance-mode QWidget-based system, or clumsily interact with the QML DOM
> via the QtDeclarative module. Perhaps the best role for R in such a scenario
> would be to expose R-based classes to QML, but then people need to learn
> Javascript.
> >
> > Meanwhile, GTK+/Cairo keep moving along, with a cool new HTML5 backend,
> multi-touch support, and Android in the works... maybe goocanvas is worth a
> hard look (despite it being in maintenance mode itself)...
> >
> > Michael
> >
> >
> > _______________________________________________
> > 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
>
> ---------------------------
> Di Cook
> visnut at gmail.com
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20110522/0f089a34/attachment.htm>