Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

On 5/24/18, 4:16 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Thursday, 24 May 2018 16:57:03 -03 Michael Jackson wrote:
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> '/tmp/runtime-buildbot'

This one means your environment isn't properly set up. Make sure 
XDG_RUNTIME_DIR is set correctly to the correct path.

> qt.qpa.screen: QXcbConnection: Could not connect to
> display
> Could not connect to any X display.

export QT_QPA_PLATFORM=offcreen

> So what, _exactly_, am I missing. Is there a platform plugin that I need 
to
> force load in these situations?

Yes, the offscreen one.

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

Well I got a bit farther and was able to use the -platform offscreen arguments 
to our command line applications (still worried what will happen when our 
libraries are called from Python) and I got really close. BUT this happens:

"This plugin does not support application fonts"

Some of the "painting" that we do involves fonts (and scaling them up or down 
depending on the size of the output image).

So I would sum up the whole thread as "technically" one can use QtGui 
application but anything past trivial painting isn't practically possible 
across platforms.

--
Mike Jackson


 



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Thursday, 24 May 2018 16:57:03 -03 Michael Jackson wrote:
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> '/tmp/runtime-buildbot'

This one means your environment isn't properly set up. Make sure 
XDG_RUNTIME_DIR is set correctly to the correct path.

> qt.qpa.screen: QXcbConnection: Could not connect to
> display
> Could not connect to any X display.

export QT_QPA_PLATFORM=offcreen

> So what, _exactly_, am I missing. Is there a platform plugin that I need to
> force load in these situations?

Yes, the offscreen one.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

On 5/24/18, 3:53 PM, "Michael Jackson"  wrote:

On 5/22/18, 3:18 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Tuesday, 22 May 2018 15:38:00 -03 Michael Jackson wrote:
> If it is a raster only then _why_ is it in QtGUI? There is no reason 
for it
> to depend on anything in GUI if there are no accelerated bits of code 
or
> any other codes (I'm sure I am wrong there) that depend on a windowing
> system?

Nothing in QtGui depends on the windowing system. Those bits live in 
the QPA 
plugin or in a separate library loaded by that plugin. This is the 
third time 
I've said so in this thread, including the email you replied to.

QtGui is the library that provides the foundation for all graphical and 
user-
interface functionality. It *integrates* with the windowing system of 
your 
choice by way of a semi-private extension API known as QPA (Qt Platform 
Abstraction). One of those windowing systems is the "offscreen" one, 
which 
connects to no WS server: effectively, a command-line application.

> Bottom Line: I have a reasonable use-case where I need to "draw" into 
a
> "Canvas" from a command line app.

Use QtGui.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
  
Ok, You told me. Multiple times even. So let me try this in a practical 
manner. I re-enabled one of our unit tests that uses QImage which means I have 
to link it against QtGui. Done. It compiles. Great. The unit test attempts to 
run and I get the following:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildbot'
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.

The top part of the code is:

  // Instantiate the QGuiApplication that we need to get the current path and 
load plugins.
  QGuiApplication app(argc, argv);
  QGuiApplication::setOrganizationName("Your Company");
  QGuiApplication::setOrganizationDomain("Your Domain");
  QGuiApplication::setApplicationName("");

The I try some QImage testing.

The same kind of result I also see on macOS. The "user" running our build not 
is NOT logged in. The test from above was on a Ubuntu 16.04 system running the 
precompiled Qt 5.10.1 binary from http://download.qt.io.

So what, _exactly_, am I missing. Is there a platform plugin that I need to 
force load in these situations?

--
Mike Jackson





___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

On 5/22/18, 3:18 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Tuesday, 22 May 2018 15:38:00 -03 Michael Jackson wrote:
> If it is a raster only then _why_ is it in QtGUI? There is no reason for 
it
> to depend on anything in GUI if there are no accelerated bits of code or
> any other codes (I'm sure I am wrong there) that depend on a windowing
> system?

Nothing in QtGui depends on the windowing system. Those bits live in the 
QPA 
plugin or in a separate library loaded by that plugin. This is the third 
time 
I've said so in this thread, including the email you replied to.

QtGui is the library that provides the foundation for all graphical and 
user-
interface functionality. It *integrates* with the windowing system of your 
choice by way of a semi-private extension API known as QPA (Qt Platform 
Abstraction). One of those windowing systems is the "offscreen" one, which 
connects to no WS server: effectively, a command-line application.

> Bottom Line: I have a reasonable use-case where I need to "draw" into a
> "Canvas" from a command line app.

Use QtGui.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
  
Ok, You told me. Multiple times even. So let me try this in a practical manner. 
I re-enabled one of our unit tests that uses QImage which means I have to link 
it against QtGui. Done. It compiles. Great. The unit test attempts to run and I 
get the following:



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Konstantin Shegunov]

On Tue, May 22, 2018 at 4:22 PM, Thiago Macieira 
wrote:

> On Tuesday, 22 May 2018 05:07:05 -03 Konstantin Shegunov wrote:
> > Wouldn't it be the same from the point of view of a GUI application, when
> > the platform plugins are already loaded?
> > And fail for console apps, where there are no loaded plugins to be
> queried,
> > so it'd default to the raster engine?
> > If this is the actual case then probably this is quite acceptable ...
>
> Please rephrase. Your question doesn't make sense. I wouldn't be asking if
> it
> were the same.


Forget it. Your latter comments made what I was thinking about a moot point.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 14:35:28 -03 Jason H wrote:
> Like screens, input methods, windows, sessions, clipboards, font, palettes,
> etc. Maybe these things are lighter weight than I think they are
> (particularly for the "offscreen" plugin )

You may be right that this is unneeded weight for the command-line 
applications that show no GUI and yet still need some painting primitives.

But we're not going to spend a lot of effort splitting the library. Those 
applications are a minority in the Qt world and they are served by QtGui as-
is. The effort of splitting plus the drawbacks in having a library boundary 
are most likely bigger than the gain in having smaller libraries.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 14:45:53 -03 Jason H wrote:
> But for people in my position, knowing that QGuiApplication with offscreen
> platform the raster implementation we are looking for, is not immediately
> obvious. It took you saying that for me to know that. I don't see how it
> can be gleamed from the docs.

That's why I said that QGuiApplication should have that option in the 
constructor or in a static method. Mucking with the platform plugin choice by 
way of the environment is the wrong thing to do -- suppose you want to launch 
a graphical application from your non-graphical one.

If you want this to happen, file a suggestion. I don't work on QtGui.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

> On Tuesday, 22 May 2018 12:24:56 -03 Michael Jackson wrote:
> > For Qt6 what I would like to see is QPainter abstracted out to just an
> > interface and have the normal accelerated implementation that we have now
> > in QtGui but also have a non-accelerated version living in QtCore or a
> > library that does NOT depend on a windowing system.
> 
> You've described QtGui in Qt 5.
> 
> The raster implementation lives in QtGui. The HW-accelerated implementation 
> lives in the QPA plugin or in a private library loaded by that plugin.

Thiago, you're probably reading my later post about the confusion of 
QGuiApplication right about now. :-) The information that you've shared in this 
thread has been invaluable, but it isn't in the docs. Paraphrasing, the docs 
state:
- QApplication is for widget based apps, 
- QGui is for plug-in based apps, 
- QCoreApplication has an vent loop but no GUI 

But for people in my position, knowing that QGuiApplication with offscreen 
platform the raster implementation we are looking for, is not immediately 
obvious. It took you saying that for me to know that. I don't see how it can be 
gleamed from the docs.

Anyway, thank you so much for the insight. :-)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 12:24:56 -03 Michael Jackson wrote:
> For Qt6 what I would like to see is QPainter abstracted out to just an
> interface and have the normal accelerated implementation that we have now
> in QtGui but also have a non-accelerated version living in QtCore or a
> library that does NOT depend on a windowing system.

You've described QtGui in Qt 5.

The raster implementation lives in QtGui. The HW-accelerated implementation 
lives in the QPA plugin or in a private library loaded by that plugin.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

> On Tue, May 22, 2018 at 3:15 PM, Jason H  wrote:
> > (...)
> > Admittedly I don't understand the nuances of QPixmap. But I know working 
> > with a QImage should not require a windowing server.
> 
> Where did you see QImage needs a windowing server ?
> Which QPA plugin are you using for headless apps ?
> 
> QGuiApplication should work fine for command-line-only apps, just use
> a QPA plugin that doesn't require a window system, try the offscreen
> plugin.
> 
> A good example of a gui app running on headless server is PhantomJS,
> which runs the entire QtWebKit stack.

Your point is correct. I misspoke when I said "windowing server". But 
QGuiApplication brings a lot in that isn't needed. Like screens, input methods, 
windows, sessions, clipboards, font, palettes, etc. Maybe these things are 
lighter weight than I think they are (particularly for the "offscreen" plugin ) 
and this is all much ado about nothing? If so then I apologize, but I think I 
am write to be confused by QCoreApplication, QGuiApplication, QApplication.

"The QApplication class manages the GUI application's control flow and main 
settings."
vs 
"The QGuiApplication class manages the GUI application's control flow and main 
settings." 
continuing...
"QGuiApplication contains the main event loop, where all events from the window 
system and other sources are processed and dispatched."

I got the idea of "window server" because QGuiApplication refers to "window 
system". So my next thought was "I don't want or need all that jazz." Maybe I'm 
wrong, maybe the language is not the best. But I don't seem to be alone in my 
desire to work with QImages without bringing in a window system. Maybe 
"offscreen" is the Pareto solution. 








___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Sérgio Martins]

On Tue, May 22, 2018 at 3:15 PM, Jason H  wrote:
> (...)
> Admittedly I don't understand the nuances of QPixmap. But I know working with 
> a QImage should not require a windowing server.

Where did you see QImage needs a windowing server ?
Which QPA plugin are you using for headless apps ?

QGuiApplication should work fine for command-line-only apps, just use
a QPA plugin that doesn't require a window system, try the offscreen
plugin.

A good example of a gui app running on headless server is PhantomJS,
which runs the entire QtWebKit stack.

Regards,
Sergio Martins
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

-Original Message-
From: Interest <interest-bounces+mike.jackson=bluequartz@qt-project.org> on 
behalf of Jason H <jh...@gmx.com>
Date: Tuesday, May 22, 2018 at 10:16 AM
To: Thiago Macieira <thiago.macie...@intel.com>
Cc: <interest@qt-project.org>
Subject: Re: [Interest] QDatastream, QMap, QImage serialization

> >  There is a difference. As you already stated, a QPixmap requires more 
than
> >  a QImage, so what should be provided is a QImage,
> 
> Now think about how it's constructed internally.
> 
> 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. 

THIS. I had to refactor a bunch of our code because our application needs to 
create an "image" of some data. I was using QPainter/QImage to do this, but 
then the use case came up of having to run the code on a headless server or 
through command line Python. I would get failures because there was no 
windowing system to use for QImage. I ended finding "libHaru" which allows one 
to "Draw" a PDF without the need for a windowing system. The API is similar to 
QPainter, one can draw basic polygons, fills, brushes, pens, lines. All 
_without_ the need for a windowing system. I didn't really want to bring in 
another dependency but I didn't really have a choice: QImage simply will not 
work in this situation.

For Qt6 what I would like to see is QPainter abstracted out to just an 
interface and have the normal accelerated implementation that we have now in 
QtGui but also have a non-accelerated version living in QtCore or a library 
that does NOT depend on a windowing system. All the other classes that have 
been discussed as having to be moved like the Polygon/Matrix classes should 
also be moved. There are a lot of science type of apps that could instantly 
make use of these kinds of things. Instead I have to bring in something huge 
like ITK just to read/write some images.

My point is that for me, I am ok with a non-accelerated 2D drawing system if it 
does not depend on a windowing system. Qt is a wonderful overall toolkit. It 
isn't *just* a GUI toolkit as another poster has suggested. It is a unifying 
toolkit that is well written and documented that is cross platform.

Just my nickel's worth.
--
Mike Jackson 
 

 


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

> Sent: Tuesday, May 22, 2018 at 10:04 AM
> From: "Thiago Macieira" <thiago.macie...@intel.com>
> To: interest@qt-project.org
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On Tuesday, 22 May 2018 10:38:46 -03 Jason H wrote:
> > > How about just using different function names instead? Like, you know,
> > > "texture" and "textureImage"?
> > 
> > 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. However if we were to just 
use that atom concept from the start the source could never be wrong.  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.


> >  There is a difference. As you already stated, a QPixmap requires more than
> >  a QImage, so what should be provided is a QImage,
> 
> Now think about how it's constructed internally.
> 
> 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. 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 10:57:08 -03 Jason H wrote:
> > > 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.

Item models are in QtCore.

It's just the *standard* item models, which contain icons, tooltips, status 
tips, fonts, size hints, fore and background colours, etc. that are in QtGui.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 10:38:46 -03 Jason H wrote:
> > How about just using different function names instead? Like, you know,
> > "texture" and "textureImage"?
> 
> How about texture() and texturePixmap()?

That is source-incompatible.

>  There is a difference. As you already stated, a QPixmap requires more than
>  a QImage, so what should be provided is a QImage,

Now think about how it's constructed internally.

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?

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

> 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

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

> Sent: Monday, May 21, 2018 at 4:02 PM
> From: "Thiago Macieira" <thiago.macie...@intel.com>
> To: interest@qt-project.org
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On Monday, 21 May 2018 15:50:02 -03 Jason H wrote:
> > I don't think C++ has a good concept of what it is that I want to do. C++
> > does not allow multiple return types from functions, therefore, the only
> > way to get the type you want returned is provide an overload with different
> > parameters.  What is needed is something "orthogonal" to an enum. Whereas
> > enums are all the same type, you need a thing that is the same "thing" but
> > different type. You can't use enums names because it's too easy to convert
> > between them since they are all ints under the hood.
> > 
> > class QPixmapAtom {};
> > class QImageAtom {};
> > class QBrush {
> > ...
> > QPixmap texture(QPixmapAtom());
> > QImage texture(QImageAtom());
> > };
> 
> How about just using different function names instead? Like, you know, 
> "texture" and "textureImage"?

How about texture() and texturePixmap()? There is a difference. As you already 
stated, a QPixmap requires more than a QImage, so what should be provided is a 
QImage, which then can be converted with QPixmap::fromImage();. If we want to 
move QImage out of GUI, then dropping the pixmap function would help. Would it 
not?




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Tuesday, 22 May 2018 05:07:05 -03 Konstantin Shegunov wrote:
> > For example, QImage::paintEngine() queries the platform plugin to see if
> > it
> > 
> > can provide a better image painter than QRasterPaintEngine (for HW
> > acceleration, I suppose). That is only possible because QImage is in
> > QtGui.
> > 
> > Currently, there are no platforms taking this opportunity, but do we want
> > to
> > prevent it from ever happening?
> 
> Wouldn't it be the same from the point of view of a GUI application, when
> the platform plugins are already loaded?
> And fail for console apps, where there are no loaded plugins to be queried,
> so it'd default to the raster engine?
> If this is the actual case then probably this is quite acceptable ...

Please rephrase. Your question doesn't make sense. I wouldn't be asking if it 
were the same.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Christian Gagneraud]

On 23 May 2018 at 00:25, william.croc...@analog.com
 wrote:
>
>> To summarise:
>> - Qt is a graphical toolkit
>
>
> ...and I used it to create a graphical application.
> But then my users wanted to create hard copy from
> batch jobs running on our compute farm. Those machines
> do not provide access to an X server and, as we have discovered,
> Qt needs an X server for a lot of things.
>
> So, now, if my app does not detect an X server, I start up
> an Xvfb instance and continue on with use of a regular QApplication.

That's exactly what i'm doing too, except that i don't let the app
decide the world it's running into.

But i think you missed the point of build-time dependencies, No X
headers = no QPolygonF,  why?
A polygon is "just" defined by a set of ordered point in a 2D space.
Anyway, i'm not here to blame Qt, Qt provides graphically rendererable
polygon, not mathematically-defined polygons

> Works great.

Works great here too.

Chris

>
> Bill
>
>> - 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)
>>
>> My 2 cents.
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[william.croc...@analog.com]

To summarise:
- Qt is a graphical toolkit


...and I used it to create a graphical application.
But then my users wanted to create hard copy from
batch jobs running on our compute farm. Those machines
do not provide access to an X server and, as we have discovered,
Qt needs an X server for a lot of things.

So, now, if my app does not detect an X server, I start up
an Xvfb instance and continue on with use of a regular QApplication.

Works great.

Bill


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

My 2 cents.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Christian Gagneraud]

On 22 May 2018 at 02:03, Jason H  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?

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

> QPdfWriter

If only Qt could deal with modern PDF to start with, gui or  not...

> 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 

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

> Various geometrics (QPolygon, QRegion)

Unfortunately, look at all the "qt private" stuff behind these, it's quite ugly.
May I add the mighty QPainterPath? A very promising piece of code,
unless you realised it's tailored to graphical/painting operation.
Contains hard coded CPU calculation precision limit, approximation of
all sort, circles as polygon, dirty bezier approximation/optimisation,

QGraphicsScene/View attempted to introduced qreal instead of int, what
did go wrong? 
Premature optimisation that wasn't actually premature back at that
time... Who to blame?
Anyone running on a processor w/o floating point registers nowaday?

But again, how dare do we ask for more?
Qt is a graphical toolkit, not a scientific spline/polygon/geometry library.
Maybe look at boost::geometry instead
Well, watch your CPU burning templates and meta-programming
And failing like shit! Understandable compiler errors are utopia,
opaque meta-programming logic brings opaque meta-programming errors.
I once tried to contribute to https://www.cgal.org/ but gave up b/c
filling a bug report wasn't even human friendly.
(PS: I had fun with their stuff, try it!)

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)

My 2 cents.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Konstantin Shegunov]

On Mon, May 21, 2018 at 7:57 PM, Jason H  wrote:

> I can definintely understand if people don't want pixel depenencies in
> their QCoreApplication.
> But I cringe a labeling it GUI. It's graphical but it's not necessarily
> User and definately not interface. I'd call it "graphics" or something. If
> you say GUI I'm thinking a display device and input device (mouse,
> keyboard, touch screen)
>

Fine, you won't get any argument from me on that. I don't think that the
issue of naming is the key here anyway, we can argue the name later.
It's rather: "should it be done? and if it should, which classes go in?"

On Mon, May 21, 2018 at 8:37 PM, Thiago Macieira 
 wrote:

> It's just that the distinction of which classes can be safely used outside
> the
> GUI thread or even without QGuiApplication isn't very clear. Said library
> would make it very clear and almost impossible to violate, but it could
> also
> preclude certain possible optimisations.
>
> For example, QImage::paintEngine() queries the platform plugin to see if it
>
> can provide a better image painter than QRasterPaintEngine (for HW
> acceleration, I suppose). That is only possible because QImage is in QtGui.
>
> Currently, there are no platforms taking this opportunity, but do we want
> to
> prevent it from ever happening?
>

Wouldn't it be the same from the point of view of a GUI application, when
the platform plugins are already loaded?
And fail for console apps, where there are no loaded plugins to be queried,
so it'd default to the raster engine?
If this is the actual case then probably this is quite acceptable ...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Monday, 21 May 2018 15:50:02 -03 Jason H wrote:
> I don't think C++ has a good concept of what it is that I want to do. C++
> does not allow multiple return types from functions, therefore, the only
> way to get the type you want returned is provide an overload with different
> parameters.  What is needed is something "orthogonal" to an enum. Whereas
> enums are all the same type, you need a thing that is the same "thing" but
> different type. You can't use enums names because it's too easy to convert
> between them since they are all ints under the hood.
> 
> class QPixmapAtom {};
> class QImageAtom {};
> class QBrush {
> ...
> QPixmap texture(QPixmapAtom());
> QImage texture(QImageAtom());
> };

How about just using different function names instead? Like, you know, 
"texture" and "textureImage"?

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Roland Hughes]

On 05/21/2018 10:53 AM, Thiago Macieira wrote:

On Sunday, 20 May 2018 21:27:31 -03 Jason H wrote:

Why is QImage even a GUI type?

"Has pixels" is the simplest defintiion of GUI.
Not exactly a definition which should actually be used though. While 
facial recognition may make for impressive displays on cop shows and 
seismic data make look wonderful in certain movies, the reality is that 
it is just data bundles which an algorithm runs over looking for patters 
much like a text search performed via a command line editor.


QColor could even be classified as such. Maybe.

Pen and brush though, they exist for the physical act of painting and 
primarily for that.


Having said all of that though, and given QPixmap can be loaded in a 
worker thread I don't have a major issue with the current split between 
GUI and core.


It does make one wonder about what shortcuts were taken to require 
painting only occur in the GUI. That would be a much more beneficial 
conversation for the Qt community as a whole, especially since we can 
paint off-screen then blit it on. It would seem that off-screen painting 
should be threadable.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

>
> On Monday, 21 May 2018 13:04:00 -03 Jason H wrote:
> > which makes me think it should be T texture();
> 
> THAT is not going to happen.
> 
> Find a non-template name and we can talk.

I don't think C++ has a good concept of what it is that I want to do. C++ does 
not allow multiple return types from functions, therefore, the only way to get 
the type you want returned is provide an overload with different parameters.  
What is needed is something "orthogonal" to an enum. Whereas enums are all the 
same type, you need a thing that is the same "thing" but different type. You 
can't use enums names because it's too easy to convert between them since they 
are all ints under the hood. 

class QPixmapAtom {};
class QImageAtom {};
class QBrush {
...
QPixmap texture(QPixmapAtom());
QImage texture(QImageAtom());
};

However this idea of class atoms I think is completely foreign to C++. It also 
allows for inheritance where something can inherit QImageAtom (which enums 
can't do (I don' think...)) providing more specialization of the atom.  (A 
molecule?) (You can call it a "hint" as well though existing "hints" in Qt are 
enums, so I'm trying to stay away from that.)

What I like about it is I don't have to remember if texture() returns a pixmap 
or an image. It'll return a type matching whatever "atom" I gave it. 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Monday, 21 May 2018 11:46:54 -03 Christoph Feck wrote:
> Maybe for Qt6 we could have a thin QtGuiCore library, which manipulates
> image data and colors, but does not have a dependency on GUI servers
> (OpenGL, X11, etc.)

I think even that name was proposed before. I don't remember if it was during 
the Qt 5.0 development time or not.

But we decided not to. With most of the actual windowing code moved to plugins 
(and libraries loaded by those plugins, like libQt5XcbQpa), QtGui *is* that 
GuiCore library.

It's just that the distinction of which classes can be safely used outside the 
GUI thread or even without QGuiApplication isn't very clear. Said library 
would make it very clear and almost impossible to violate, but it could also 
preclude certain possible optimisations.

For example, QImage::paintEngine() queries the platform plugin to see if it 
can provide a better image painter than QRasterPaintEngine (for HW 
acceleration, I suppose). That is only possible because QImage is in QtGui. 
Currently, there are no platforms taking this opportunity, but do we want to 
prevent it from ever happening?

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

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

What is the logical / physical DPI of a QImage? I'd assume 1:1.

QBrush can return a a texture as:
- QPixmap texture() or 
- QImage textureImage()

which makes me think it should be T texture();

All this non-gui art refactoring definitely has to wait until Qt6, but I think 
it'd be very welcome by the (surprisingly) many of us using Qt for non-gui 
stuff. 



Additionally, I was wondering if there is a Qt-based image manipulation 
library? I've been hacking my own together called FluentImage, which is QImage 
with a d "fluent" interface. Or may be add it to QImage?

FluentImage blurred = FlutentImage(QImage()).scale(.5).rotate(45).blur(); 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Konstantin Shegunov]

On Mon, May 21, 2018 at 5:46 PM, Christoph Feck  wrote:
>
> Maybe for Qt6 we could have a thin QtGuiCore library, which manipulates
> image data and colors, but does not have a dependency on GUI servers
> (OpenGL, X11, etc.)


This makes most sense to me. I wouldn't really want the core, which is
already pretty big, to get yet another big portion of code to accommodate
the cases, that I feel, are not that common, albeit I would think they're
really rare as well.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jean-Michaël Celerier]

> "Has pixels" is the simplest defintiion of GUI.

plenty of programs working with pixels don't have GUIs. Stuff like
imagemagick, pdftk, ffmpeg, etc etc
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

-Original Message-
From: Interest <interest-bounces+mike.jackson=bluequartz@qt-project.org> on 
behalf of Thiago Macieira <thiago.macie...@intel.com>
Organization: Intel Corporation
Date: Monday, May 21, 2018 at 9:49 AM
To: <interest@qt-project.org>
Subject: Re: [Interest] QDatastream, QMap, QImage serialization

On Sunday, 20 May 2018 21:27:31 -03 Jason H wrote:
> Why is QImage even a GUI type? 

"Has pixels" is the simplest defintion of GUI.

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

 Let's agree to disagree. LibTiff deals with "pixels" and it does not need a 
windowing system or define a "GUI" to do its work.

--
Mike Jackson



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

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

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

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Christoph Feck]

On 21.05.2018 16:36, Murphy, Sean wrote:

Why is QImage even a GUI type?


"Has pixels" is the simplest defintiion of GUI.


As a counter to that: QImage be safely used outside of the GUI thread which
is not true for most classes that are considered GUI classes...


But doesn't QImage need PNG to serialize data? I wouldn't want a libpng 
dependency in command line applications.


Maybe for Qt6 we could have a thin QtGuiCore library, which manipulates 
image data and colors, but does not have a dependency on GUI servers 
(OpenGL, X11, etc.)


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Murphy, Sean]

> > Why is QImage even a GUI type?
> 
> "Has pixels" is the simplest defintiion of GUI.

As a counter to that: QImage be safely used outside of the GUI thread which
is not true for most classes that are considered GUI classes...

Sean


This message has been scanned for malware by Forcepoint. www.forcepoint.com
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Sze Howe Koh]

On 21 May 2018 at 17:08, Christian Gagneraud  wrote:
> On 21 May 2018 at 20:12, Jean-Michaël Celerier
>  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

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

Going through the list of Qt GUI classes, there are several that I think should 
be moved:
QImage
QStandardItem*
Matrix and Vector classes
QPdfWriter
QPen, QBrush, etc.
QText* QTextDocument et al.
QValidator et al.
QFont* (where applicable. QFontDatabase, QRawFont)
Various geometrics (QPolygon, QRegion)

I'm not sure if these should be moved to Qt Core, as it would add to that 
library's size or go into their own "visual" device indepenent library. 
Ideally, I want QImage supported in core. But the other ramification is you 
won't need a QGUIApplication or QApplication class and can stick to 
QCoreApplication. In the past I've had to pass a bogus window system to use it 
for a server based app. Could it use stub classes for those not wanting imaging 
capability in Qt Core?


> Sent: Monday, May 21, 2018 at 5:08 AM
> From: "Christian Gagneraud" <chg...@gmail.com>
> To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>
> Cc: "Jason H" <jh...@gmx.com>, "Thiago Macieira" <thiago.macie...@intel.com>, 
> interest <interest@qt-project.org>
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> 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.
> 
> Chris
> 
> >
> >
> > ---
> > Jean-Michaël Celerier
> > http://www.jcelerier.name
> >
> > On Mon, May 21, 2018 at 2:27 AM, Jason H <jh...@gmx.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.
> >>
> >> I (Qt?) uses QPixmap whenever it has to display an image.
> >>
> >>
> >> > Sent: Sunday, May 20, 2018 at 11:54 AM
> >> > From: "Thiago Macieira" <thiago.macie...@intel.com>
> >> > To: interest@qt-project.org
> >> > Subject: Re: [Interest] QDatastream, QMap, QImage serialization
> >> >
> >> > On Sunday, 20 May 2018 07:26:47 -03 Konstantin Shegunov wrote:
> >> > > On Thu, May 17, 2018 at 5:58 PM, Thiago Macieira
> >> > > <thiago.macie...@intel.com>
> >> > > wrote:
> >> > > > On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
> >> > > > > Is there a reason why calling qRegisterStreamOperators()
> >> > > > > would't
> >> > > > > work ?
> >> > > >
> >> > > > Because the vector containng the list of function pointers doesn't
> >> > > > exist
> >> > > > for
> >> > > > metatypes < QMetaType::User.
> >> > >
> >> > > Is this by design, or just an unfortunate legacy?
> >> >
> >> > It's by design that the vector starts at QMetaType::User.
> >> >
> >> > > I would've expected
> >> > > (obviously wrongly) that the core classes provide and support all the
> >> > > functionalities of properly registered custom types.
> >> >
> >> > Except where it was too hard and we haven't done it. Serialisation
> >> > appears to
> >> > be one such case.
> >> >
> >> > > And a follow up question: I'm not intimate with the internals, so is
> >> > > it
> >> > > feasible to actually bring this to consistency and have the stream
> >> > > operators registered in the meta-type system for the core classes?
> >> >
> >> > Yes. Patch accepted. See qguivariant.cpp: the two save and load
> >> > fu

Re: [Interest] QDatastream, QMap, QImage serialization

[Andy]

On Mon, May 21, 2018 at 9:49 AM Thiago Macieira 
wrote:

> On Sunday, 20 May 2018 21:27:31 -03 Jason H wrote:
> > Why is QImage even a GUI type?
>
> "Has pixels" is the simplest defintiion of GUI.
>

GUI is more than that - it involves displaying said pixels. Otherwise it's
just data.

If you look at practical use cases like writing a lib or a command line
tool which processes image data, then pulling in GUI for it seems
heavy-handed.


> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Sunday, 20 May 2018 21:27:31 -03 Jason H wrote:
> Why is QImage even a GUI type? 

"Has pixels" is the simplest defintiion of GUI.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Christian Gagneraud]

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.

Chris

>
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Mon, May 21, 2018 at 2:27 AM, Jason H <jh...@gmx.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.
>>
>> I (Qt?) uses QPixmap whenever it has to display an image.
>>
>>
>> > Sent: Sunday, May 20, 2018 at 11:54 AM
>> > From: "Thiago Macieira" <thiago.macie...@intel.com>
>> > To: interest@qt-project.org
>> > Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>> >
>> > On Sunday, 20 May 2018 07:26:47 -03 Konstantin Shegunov wrote:
>> > > On Thu, May 17, 2018 at 5:58 PM, Thiago Macieira
>> > > <thiago.macie...@intel.com>
>> > > wrote:
>> > > > On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
>> > > > > Is there a reason why calling qRegisterStreamOperators()
>> > > > > would't
>> > > > > work ?
>> > > >
>> > > > Because the vector containng the list of function pointers doesn't
>> > > > exist
>> > > > for
>> > > > metatypes < QMetaType::User.
>> > >
>> > > Is this by design, or just an unfortunate legacy?
>> >
>> > It's by design that the vector starts at QMetaType::User.
>> >
>> > > I would've expected
>> > > (obviously wrongly) that the core classes provide and support all the
>> > > functionalities of properly registered custom types.
>> >
>> > Except where it was too hard and we haven't done it. Serialisation
>> > appears to
>> > be one such case.
>> >
>> > > And a follow up question: I'm not intimate with the internals, so is
>> > > it
>> > > feasible to actually bring this to consistency and have the stream
>> > > operators registered in the meta-type system for the core classes?
>> >
>> > Yes. Patch accepted. See qguivariant.cpp: the two save and load
>> > functions are
>> > currently null pointers. Replace with actual functions that save QtGui
>> > types
>> > to a QDataStream and properly loaded back.
>> >
>> > --
>> > Thiago Macieira - thiago.macieira (AT) intel.com
>> >   Software Architect - Intel Open Source Technology Center
>> >
>> >
>> >
>> > ___
>> > Interest mailing list
>> > Interest@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/interest
>> >
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jean-Michaël Celerier]

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


---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, May 21, 2018 at 2:27 AM, Jason H <jh...@gmx.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.
>
> I (Qt?) uses QPixmap whenever it has to display an image.
>
>
> > Sent: Sunday, May 20, 2018 at 11:54 AM
> > From: "Thiago Macieira" <thiago.macie...@intel.com>
> > To: interest@qt-project.org
> > Subject: Re: [Interest] QDatastream, QMap, QImage serialization
> >
> > On Sunday, 20 May 2018 07:26:47 -03 Konstantin Shegunov wrote:
> > > On Thu, May 17, 2018 at 5:58 PM, Thiago Macieira <
> thiago.macie...@intel.com>
> > > wrote:
> > > > On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
> > > > > Is there a reason why calling qRegisterStreamOperators()
> would't
> > > > > work ?
> > > >
> > > > Because the vector containng the list of function pointers doesn't
> exist
> > > > for
> > > > metatypes < QMetaType::User.
> > >
> > > Is this by design, or just an unfortunate legacy?
> >
> > It's by design that the vector starts at QMetaType::User.
> >
> > > I would've expected
> > > (obviously wrongly) that the core classes provide and support all the
> > > functionalities of properly registered custom types.
> >
> > Except where it was too hard and we haven't done it. Serialisation
> appears to
> > be one such case.
> >
> > > And a follow up question: I'm not intimate with the internals, so is it
> > > feasible to actually bring this to consistency and have the stream
> > > operators registered in the meta-type system for the core classes?
> >
> > Yes. Patch accepted. See qguivariant.cpp: the two save and load
> functions are
> > currently null pointers. Replace with actual functions that save QtGui
> types
> > to a QDataStream and properly loaded back.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
> >
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

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.

I (Qt?) uses QPixmap whenever it has to display an image. 


> Sent: Sunday, May 20, 2018 at 11:54 AM
> From: "Thiago Macieira" <thiago.macie...@intel.com>
> To: interest@qt-project.org
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On Sunday, 20 May 2018 07:26:47 -03 Konstantin Shegunov wrote:
> > On Thu, May 17, 2018 at 5:58 PM, Thiago Macieira <thiago.macie...@intel.com>
> > wrote:
> > > On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
> > > > Is there a reason why calling qRegisterStreamOperators() would't
> > > > work ?
> > > 
> > > Because the vector containng the list of function pointers doesn't exist
> > > for
> > > metatypes < QMetaType::User.
> > 
> > Is this by design, or just an unfortunate legacy?
> 
> It's by design that the vector starts at QMetaType::User.
> 
> > I would've expected
> > (obviously wrongly) that the core classes provide and support all the
> > functionalities of properly registered custom types.
> 
> Except where it was too hard and we haven't done it. Serialisation appears to 
> be one such case.
> 
> > And a follow up question: I'm not intimate with the internals, so is it
> > feasible to actually bring this to consistency and have the stream
> > operators registered in the meta-type system for the core classes?
> 
> Yes. Patch accepted. See qguivariant.cpp: the two save and load functions are 
> currently null pointers. Replace with actual functions that save QtGui types 
> to a QDataStream and properly loaded back.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Sunday, 20 May 2018 07:26:47 -03 Konstantin Shegunov wrote:
> On Thu, May 17, 2018 at 5:58 PM, Thiago Macieira 
> wrote:
> > On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
> > > Is there a reason why calling qRegisterStreamOperators() would't
> > > work ?
> > 
> > Because the vector containng the list of function pointers doesn't exist
> > for
> > metatypes < QMetaType::User.
> 
> Is this by design, or just an unfortunate legacy?

It's by design that the vector starts at QMetaType::User.

> I would've expected
> (obviously wrongly) that the core classes provide and support all the
> functionalities of properly registered custom types.

Except where it was too hard and we haven't done it. Serialisation appears to 
be one such case.

> And a follow up question: I'm not intimate with the internals, so is it
> feasible to actually bring this to consistency and have the stream
> operators registered in the meta-type system for the core classes?

Yes. Patch accepted. See qguivariant.cpp: the two save and load functions are 
currently null pointers. Replace with actual functions that save QtGui types 
to a QDataStream and properly loaded back.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Konstantin Shegunov]

On Thu, May 17, 2018 at 5:58 PM, Thiago Macieira 
wrote:

> On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
> > Is there a reason why calling qRegisterStreamOperators() would't
> > work ?
>
> Because the vector containng the list of function pointers doesn't exist
> for
> metatypes < QMetaType::User.


Is this by design, or just an unfortunate legacy? I would've expected
(obviously wrongly) that the core classes provide and support all the
functionalities of properly registered custom types.
And a follow up question: I'm not intimate with the internals, so is it
feasible to actually bring this to consistency and have the stream
operators registered in the meta-type system for the core classes?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Thursday, 17 May 2018 05:01:18 PDT Jean-Michaël Celerier wrote:
> Is there a reason why calling qRegisterStreamOperators() would't
> work ?

Because the vector containng the list of function pointers doesn't exist for 
metatypes < QMetaType::User. You can't modify the built-in types.

Deriving from QImage and doing what you suggested would work.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

I'm not familar with that function,  but I would guess because it's a QVariant holding a QImage?

There already are those stream operators, and I think they are already registered.

 


I'm not understanding why QVariatn doesn't know how/why to call it?

I'd figure that QVariant would write the type, the 0 byte, then have the object QDataStream& operator << into the QIODevice itself?

 


Sent: Thursday, May 17, 2018 at 8:02 AM
From: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>
To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>
Cc: "Thiago Macieira" <thiago.macie...@intel.com>, interest <interest@qt-project.org>
Subject: Re: [Interest] QDatastream, QMap, QImage serialization


Sorry, I meant qRegisterMetaTypeStreamOperators()

 



 

 

---
Jean-Michaël Celerier

http://www.jcelerier.name



 

On Thu, May 17, 2018 at 2:01 PM, Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> wrote:



> The problem is that QVariant doesn't know how to call it. 

 

Is there a reason why calling qRegisterStreamOperators() would't work ?


 



 

 

---
Jean-Michaël Celerier

http://www.jcelerier.name





 
On Wed, May 16, 2018 at 11:52 PM, Thiago Macieira <thiago.macie...@intel.com> wrote:

On Wednesday, 16 May 2018 14:38:08 PDT Jérôme Godbout wrote:
> You will need to provide your own
>
> QDataStream& operator<<(QDataStream& ds, const QImage& img)

That's not needed (and won't compile). It already exists.

The problem is that QVariant doesn't know how to call it. So when you have a
QImage inside a QVariant and you try to serialise that QVariant, you get
nothing useful.

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


 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest









___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jean-Michaël Celerier]

Sorry, I meant qRegisterMetaTypeStreamOperators()



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, May 17, 2018 at 2:01 PM, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > The problem is that QVariant doesn't know how to call it.
>
> Is there a reason why calling qRegisterStreamOperators() would't
> work ?
>
>
>
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Wed, May 16, 2018 at 11:52 PM, Thiago Macieira <
> thiago.macie...@intel.com> wrote:
>
>> On Wednesday, 16 May 2018 14:38:08 PDT Jérôme Godbout wrote:
>> > You will need to provide your own
>> >
>> > QDataStream& operator<<(QDataStream& ds, const QImage& img)
>>
>> That's not needed (and won't compile). It already exists.
>>
>> The problem is that QVariant doesn't know how to call it. So when you
>> have a
>> QImage inside a QVariant and you try to serialise that QVariant, you get
>> nothing useful.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jean-Michaël Celerier]

> The problem is that QVariant doesn't know how to call it.

Is there a reason why calling qRegisterStreamOperators() would't
work ?




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, May 16, 2018 at 11:52 PM, Thiago Macieira  wrote:

> On Wednesday, 16 May 2018 14:38:08 PDT Jérôme Godbout wrote:
> > You will need to provide your own
> >
> > QDataStream& operator<<(QDataStream& ds, const QImage& img)
>
> That's not needed (and won't compile). It already exists.
>
> The problem is that QVariant doesn't know how to call it. So when you have
> a
> QImage inside a QVariant and you try to serialise that QVariant, you get
> nothing useful.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jason H]

> Sent: Wednesday, May 16, 2018 at 11:52 PM
> From: "Thiago Macieira" <thiago.macie...@intel.com>
> To: interest@qt-project.org
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On Wednesday, 16 May 2018 14:38:08 PDT Jérôme Godbout wrote:
> > You will need to provide your own
> > 
> > QDataStream& operator<<(QDataStream& ds, const QImage& img)
> 
> That's not needed (and won't compile). It already exists.
> 
> The problem is that QVariant doesn't know how to call it. So when you have a 
> QImage inside a QVariant and you try to serialise that QVariant, you get 
> nothing useful.

So could I provide a QImage derived class? What overrides would I need? Just 
the Qvariant ones?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Wednesday, 16 May 2018 14:38:08 PDT Jérôme Godbout wrote:
> You will need to provide your own
> 
> QDataStream& operator<<(QDataStream& ds, const QImage& img)

That's not needed (and won't compile). It already exists.

The problem is that QVariant doesn't know how to call it. So when you have a 
QImage inside a QVariant and you try to serialise that QVariant, you get 
nothing useful.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Jérôme Godbout]

You will need to provide your own

QDataStream& operator<<(QDataStream& ds, const QImage& img)

{

ds << img.height() << img.width() << img.format() << img.data()

}

and

QDataStream& operator>>(QDataStream& ds, QImage& img)

{

  int height;

   ds >> height;

   img.setHeight(height);

   ...

}

Then you might want to serialize the QByteArray and image format or anything 
required to rebuild the image from the data.

http://doc.qt.io/qt-5/qimage.html#fromData-1


I have check in depth the needed data but you get the idea



From: Interest <interest-bounces+godboutj=amotus...@qt-project.org> on behalf 
of Jason H <jh...@gmx.com>
Sent: May 16, 2018 4:51 PM
To: interestqt-project.org
Subject: [Interest] QDatastream, QMap, QImage serialization

I'm trying to write a GUI utility to provide a simple UI. I'm wanting a 
no-frills database of several Qt types, and I'm trying to use QVariantMap for 
that. It's going well except that QImages aren't being serialized correctly. 
Yes, I know there is a QVariant limitation with "GUI types" ( 
http://doc.qt.io/qt-5/qvariant.html#a-note-on-gui-types ) however QImage has an 
operator QVariant(). I was expecting to see pixel data get stored in the file, 
but it's just being stored as an empty QString. So it seems that QDataStream 
can't serialize a QImage? I know that's not true, so it looks like QDataStream 
can't serialize a QVariant that is a QImage. I think that's what I'm running 
into. I would expect some QByteArray fall-back, but the bytes aren't making it 
to disk. It would be ok for me if I had to manually convert the image later 
from an opaque byte array, so long as it was written and read properly.

What's the best way to accomplish this serialization?

Many thanks!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Thiago Macieira]

On Wednesday, 16 May 2018 13:51:39 PDT Jason H wrote:
> I'm trying to write a GUI utility to provide a simple UI. I'm wanting a
> no-frills database of several Qt types, and I'm trying to use QVariantMap
> for that. It's going well except that QImages aren't being serialized
> correctly. Yes, I know there is a QVariant limitation with "GUI types" (
> http://doc.qt.io/qt-5/qvariant.html#a-note-on-gui-types ) however QImage
> has an operator QVariant(). I was expecting to see pixel data get stored in
> the file, but it's just being stored as an empty QString. So it seems that
> QDataStream can't serialize a QImage? I know that's not true, so it looks
> like QDataStream can't serialize a QVariant that is a QImage. I think
> that's what I'm running into. I would expect some QByteArray fall-back, but
> the bytes aren't making it to disk. It would be ok for me if I had to
> manually convert the image later from an opaque byte array, so long as it
> was written and read properly.

QImage has an operator<< for QDataStream that writes PNG content to the 
stream. However QVariant cannot serialise non-QtCore types to QDataStream.

> What's the best way to accomplish this serialization?

Manually serialise your QVariantMap: for each value that is an image, call 
that operator<< directly. That implies manually deserialising too, which means 
detecting when the stream contains an image.

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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QDatastream, QMap, QImage serialization

[Jason H]

I'm trying to write a GUI utility to provide a simple UI. I'm wanting a 
no-frills database of several Qt types, and I'm trying to use QVariantMap for 
that. It's going well except that QImages aren't being serialized correctly. 
Yes, I know there is a QVariant limitation with "GUI types" ( 
http://doc.qt.io/qt-5/qvariant.html#a-note-on-gui-types ) however QImage has an 
operator QVariant(). I was expecting to see pixel data get stored in the file, 
but it's just being stored as an empty QString. So it seems that QDataStream 
can't serialize a QImage? I know that's not true, so it looks like QDataStream 
can't serialize a QVariant that is a QImage. I think that's what I'm running 
into. I would expect some QByteArray fall-back, but the bytes aren't making it 
to disk. It would be ok for me if I had to manually convert the image later 
from an opaque byte array, so long as it was written and read properly.

What's the best way to accomplish this serialization?

Many thanks!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest