[Interest] QDatastream, QMap, QImage serialization

[Sze Howe Koh]

On 21 May 2018 at 17:08, Christian Gagneraud <chgans at gmail.com> wrote:
> On 21 May 2018 at 20:12, Jean-Michaël Celerier
> <jeanmichael.celerier at gmail.com> wrote:
>>> Why is QImage even a GUI type? 99% of what I do with QImage is not for
>>> GUI. I can understand that QPixmap is GUI, but to me QImage is i/o and
>>> pixel/metadata manipulation (using scanline() where appropriate) . Yes,
>>> occasionally I use a QPainter on one, but that does not beed to be bound to
>>> a windowing system. A non-GUI raster painter would be sufficient.
>>
>> +1 (and also QColor ! plenty of command-line apps that work with colors :p)
>
> +1 (and also QPen and QBrush, they are (should be) just bundled properties)
>
> Once i wrote a graphical document format library (load, store and
> models), that could have not depend on GUI at all if it didn't use
> QColor, QPen, QBrush.

I agree that QColor, QRgb, QRgba64, QGradient (and its subclasses),
QGradientStop, and QPolygon are data types that are independent of
GUIs, so they can be simply moved out of the Qt GUI module if desired.

However, other classes can't be cleanly separated from Qt GUI (at
least without significant re-design) because:
* QPixmap is tied to system graphics resources
* QPaintDevice has the concept of "physical DPI" and "logical DPI"
which are GUI-related.

* QPainter depends on QPaintEngine which depends on QPaintDevice
* QPen depends on QBrush which depends on QPixmap
* QPen and QBrush are useless without QPainter
* QImage inherits QPaintDevice
* QRegion depends on QBitmap which inherits QPixmap


Regards,
Sze-Howe