[Interest] QDatastream, QMap, QImage serialization

[Konstantin Shegunov]

On Mon, May 21, 2018 at 7:57 PM, Jason H <jhihn at gmx.com> wrote:

> I can definintely understand if people don't want pixel depenencies in
> their QCoreApplication.
> But I cringe a labeling it GUI. It's graphical but it's not necessarily
> User and definately not interface. I'd call it "graphics" or something. If
> you say GUI I'm thinking a display device and input device (mouse,
> keyboard, touch screen)
>

Fine, you won't get any argument from me on that. I don't think that the
issue of naming is the key here anyway, we can argue the name later.
It's rather: "should it be done? and if it should, which classes go in?"

On Mon, May 21, 2018 at 8:37 PM, Thiago Macieira <thiago.macieira at intel.com>
 wrote:

> It's just that the distinction of which classes can be safely used outside
> the
> GUI thread or even without QGuiApplication isn't very clear. Said library
> would make it very clear and almost impossible to violate, but it could
> also
> preclude certain possible optimisations.
>
> For example, QImage::paintEngine() queries the platform plugin to see if it
>
> can provide a better image painter than QRasterPaintEngine (for HW
> acceleration, I suppose). That is only possible because QImage is in QtGui.
>
> Currently, there are no platforms taking this opportunity, but do we want
> to
> prevent it from ever happening?
>

Wouldn't it be the same from the point of view of a GUI application, when
the platform plugins are already loaded?
And fail for console apps, where there are no loaded plugins to be queried,
so it'd default to the raster engine?
If this is the actual case then probably this is quite acceptable ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180522/fb1f1842/attachment.html>