On 21 May 2018 at 17:08, Christian Gagneraud <chg...@gmail.com> wrote: > On 21 May 2018 at 20:12, Jean-Michaƫl Celerier > <jeanmichael.celer...@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest