[Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 11:15:49 -03 Jason H wrote:
> > > 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.

We can do source-incompatible breaks in Qt 6.0, but we have to judge how much 
we do. This one can be easy, but if you add another 999 easy ones, you get 
death by a thousand paper cuts.

I am not convinced that the current way is *wrong*. If it's not, then we 
should leave as-is.

> However if we were to
> just use that atom concept from the start the source could never be wrong. 

I don't see why _ZNK6QBrush7textureE10QImageAtom is a superior function name 
to _ZNK6QBrush12textureImageEv.

> 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.

Won't do (and it's not my module anyway). But I could take the examples of 
QString::mid, QString::midRef and QString::midView.

You haven't convinced me *why* this is necessary in the first place. What's 
wrong with having the type in the function name?

> > 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.

So you're saying "I don't understand why this was chosen in the first place, 
but I am suggesting you change it".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center