On Wed, Jan 29, 2014 at 12:54 AM, Olivier Goffart <oliv...@woboq.com> wrote: > On Tuesday 28 January 2014 11:28:42 Alan Alpert wrote: >> On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser <mark...@gmail.com> wrote: > >> > While browsing through the code (qquickdrag.cpp) i found these two >> > >> > commented lines: >> > // TODO: how to handle drag image? >> > // drag->setPixmap(iconPixmap); >> > >> > Along with that no more function for "setPixmap" that is exposed to QML. >> > That makes me fear that the setPixmap property is not there anymore. >> > >> > Odd, since it would be an API break which i can't really imagine from Qt. >> > >> > I hope someone else more knowledgeable in this area can chime in? >> >> Use of direct QPixmaps in QML is discouraged, because there's no real >> way to manage the memory of the pointer. If there were a QObject or >> QJSValue wrapper around QPixmap then a setPixmap could be added, >> similar to the setPixmap in QDrag (although not actually accepting a >> QPixmap type). >> >> So without a good solution handy, that part has been left "for later". > > I don't quite understand the problem. QPixmap manage its own memory. And you > can use it in a QVariant for example, which can already be handled by QML.
It's the QPixmap pointer which is unmanged, not any internal pointers. Passing it around by value in a QVariant is ugly*, and we're trying to drop QVariants in favor of JS vars (in which case ,we're back to the wrapped JS type approach). *variant APIs lose type safety, and it's just like passing an opaque pointer so you can't do much more with it than you could when you drop to C++ to create one anyways. -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
