> Sent: Tuesday, May 22, 2018 at 8:08 AM > From: "Christian Gagneraud" <chg...@gmail.com> > To: "Jason H" <jh...@gmx.com> > Cc: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>, "Thiago > Macieira" <thiago.macie...@intel.com>, interest <interest@qt-project.org> > Subject: Re: [Interest] QDatastream, QMap, QImage serialization > > On 22 May 2018 at 02:03, Jason H <jh...@gmx.com> wrote: > > Going through the list of Qt GUI classes, there are several that I think > > should be moved: > > QImage > > QStandardItem* > > It's GUI stuff, what's wrong with that?
They are not. There's a good reason to use Qt Model View in a headless server. There's need to render images and deliver to clients as byte streams. Qt is extremely performant and scalable on servers. I've written a few processes that just maintain databases, and standard item would have helped, but I just provided my own QAbstractItemModel class. It's a minor thing, but I could have just used the standard item. > > Matrix and Vector classes > > Definitely, I should be able to do 2D/3D/4D transforms without Qt GUI. > But aren't they part of QtCore already? They are not. > > QPdfWriter > > If only Qt could deal with modern PDF to start with, gui or not... The limited support for PDF has been sufficient - not great, but sufficient - for me to generate the PDFs that I needed to. > > QPen, QBrush, etc. > > Yep! > > > QText* QTextDocument et al. > > QValidator et al. > > That's GUI stuff, definitely. These things don't make sense out of GUI > context. It's pushing a bit far, but as i get pushed a bit far i start > to get where you're coming from .... Where is that exactly? ;-) > > QFont* (where applicable. QFontDatabase, QRawFont) > > How fonts can be separated from GUI? Good luck with that! > Honestly, try to build Qt on a Linux headless server without > installing an X server.... Unix epic fail! Because fonts have a size. Fonts can be used on images. ... > To summarise: > - Qt is a graphical toolkit > - Some Qt classes shouldn't be part of QtGui > - We have to accept that Qt doesn't give a bullock about mathematical > exactness (Graphical rendering is key) So where I am coming from is that I'll generate some code that runs on either the client or the server (usually a graphical client). Then I run into a use case where it's got to run on a server. I have two options: 1. Get Qt to run "headless" on that server. 2. write an alternate implementation and deal with integration issues. If you're using domain-specific types, you are then stuck maintaining two implementations forever. This is not coding less and creating more, it's the opposite - coding more and creating less. But when running headless on a server, I also need that server to be very stingy about the resources it uses because it's handling multiple clients. In relational database parlance, there is something called "functional dependencies" which produces a minimal factorization of relationships. There's a case to me made that over time, in Qt, things ended up where they made sense, not with the things they actually depend on. I'm not saying everything needs to go into Qt core either. clearly, there can be SQL-only servers, so I'm not suggesting we make them have QImage capability. Anyway, I would have thought that with the advent of IoT, and the push for it, that more headless Qt apps would be enabled and enriched by not needing all of QtGUI. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
