[Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

-----Original Message-----
From: Interest <interest-bounces+mike.jackson=bluequartz.net at qt-project.org> on behalf of Sze Howe Koh <szehowe.koh at gmail.com>
Date: Monday, May 21, 2018 at 10:17 AM
To: interest <interest at qt-project.org>
Subject: Re: [Interest] QDatastream, QMap, QImage serialization

    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

I agree as that seems like a reasonable abstraction.

    * QPaintDevice has the concept of "physical DPI" and "logical DPI"
    which are GUI-related.

Why can't QPaintDevice be more of a low level or a "Device" independent kind of class? I can write a class that has 2 properties of LogicalDPI and PhysicalDPI. My implementation it would be up to the user to set those. If I select a different implementation based off a "real" physical system then those values are retrieved from the system.
    
    * QPainter depends on QPaintEngine which depends on QPaintDevice

See above.

    * QPen depends on QBrush which depends on QPixmap
    * QPen and QBrush are useless without QPainter
Maybe, maybe not.
    * QImage inherits QPaintDevice
Don't? I just went through a major restructuring of our plugin architecture because developers were using QImage to load images (How dare they...) but the app crashed when run through a command line because a GUI was not available. I understand this is a design decision BUT libTiff sure doesn't need a windowing system to load an image.

    * QRegion depends on QBitmap which inherits QPixmap
    
    
    Regards,
    Sze-Howe

Best
Mike Jackson