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. <br><br>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.<br>
<br>Michael<br><br><div class="gmail_quote">On Sun, May 22, 2011 at 3:46 PM, Dianne Cook <span dir="ltr"><<a href="mailto:visnut@gmail.com">visnut@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Michael,<br>
<br>
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.<br>
<br>
Would it be feasible to convert cranvas to use gtk widgets? Do you think? (Why would it be called goocanvas?)<br>
<br>
How is this going to affect your summer work, with visnab?<br>
<br>
cheers,<br>
Di<br>
<div><div></div><div class="h5"><br>
On May 22, 2011, at 12:10 AM, Michael Lawrence wrote:<br>
<br>
> Hi guys,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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)...<br>
><br>
> Michael<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Qtinterfaces-devel mailing list<br>
> <a href="mailto:Qtinterfaces-devel@lists.r-forge.r-project.org">Qtinterfaces-devel@lists.r-forge.r-project.org</a><br>
> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel</a><br>
<br>
---------------------------<br>
Di Cook<br>
<a href="mailto:visnut@gmail.com">visnut@gmail.com</a><br>
<br>
<br>
<br>
<br>
</blockquote></div><br>