[Interest] QDatastream, QMap, QImage serialization

[Jason H]

> Sent: Tuesday, May 22, 2018 at 10:04 AM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On Tuesday, 22 May 2018 10:38:46 -03 Jason H wrote:
> > > How about just using different function names instead? Like, you know,
> > > "texture" and "textureImage"?
> > 
> > How about texture() and texturePixmap()?
> 
> That is source-incompatible.

But the source is "wrong'. ;-) Everything we are talking about is 6.0 stuff. In the past code conversion tools have been provided. However if we were to just use that atom concept from the start the source could never be wrong.  If you don't want atoms, then just provide two overloads taking the return type:
texture(const QPixmap &) - does texture()
texture(const QImage &) - does textureImage()
That is source compatible. And I don't need a function of another name just for the return type.


> >  There is a difference. As you already stated, a QPixmap requires more than
> >  a QImage, so what should be provided is a QImage,
> 
> Now think about how it's constructed internally.
> 
> QBrush only exists to paint, which means GUI (QPaintDevice is the basis of all 
> GUI). It is meant to paint efficiently. If QPixmap can do that more 
> efficiently, why should it store a QImage instead?

Admittedly I don't understand the nuances of QPixmap. But I know working with a QImage should not require a windowing server.