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
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:
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 depe
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
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 lo
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 co
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 fr
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?
No
-Original Message-
From: Interest on
behalf of Thiago Macieira
Organization: Intel Corporation
Date: Tuesday, May 22, 2018 at 1:36 PM
To:
Subject: Re: [Interest] QDatastream, QMap, QImage serialization
On Tuesday, 22 May 2018 12:24:56 -03 Michael Jackson wrote:
> For
> 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
> > libr
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-incomp
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 do
> 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
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 ?
QGuiAp
-Original Message-
From: Interest on
behalf of Jason H
Date: Tuesday, May 22, 2018 at 10:16 AM
To: Thiago Macieira
Cc:
Subject: Re: [Interest] QDatastream, QMap, QImage serialization
> > There is a difference. As you already stated, a QPixmap requires more
> Sent: Tuesday, May 22, 2018 at 10:04 AM
> From: "Thiago Macieira"
> 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 f
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 pe
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 re
> Sent: Tuesday, May 22, 2018 at 8:08 AM
> From: "Christian Gagneraud"
> To: "Jason H"
> Cc: "Jean-Michaël Celerier" , "Thiago
> Macieira" , interest
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On 22
> Sent: Monday, May 21, 2018 at 4:02 PM
> From: "Thiago Macieira"
> 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 con
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
>
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 acces
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
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
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
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
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 dis
>
> 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
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 du
On Monday, 21 May 2018 11:03:38 -03 Jason H wrote:
> 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 ap
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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
__
thinking a display device and input device (mouse, keyboard, touch screen)
Sent: Monday, May 21, 2018 at 11:46 AM
From: "Konstantin Shegunov"
To: "Christoph Feck"
Cc: "Interests Qt"
Subject: Re: [Interest] QDatastream, QMap, QImage serialization
On Mon, May 21,
> * 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 QPaintDev
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
a
> "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/intere
-Original Message-
From: Interest on
behalf of Thiago Macieira
Organization: Intel Corporation
Date: Monday, May 21, 2018 at 9:49 AM
To:
Subject: Re: [Interest] QDatastream, QMap, QImage serialization
On Sunday, 20 May 2018 21:27:31 -03 Jason H wrote:
> Why is QImage eve
-Original Message-
From: Interest on
behalf of Sze Howe Koh
Date: Monday, May 21, 2018 at 10:17 AM
To: interest
Subject: Re: [Interest] QDatastream, QMap, QImage serialization
On 21 May 2018 at 17:08, Christian Gagneraud wrote:
> On 21 May 2018 at 20:12, Jean-Mich
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
> > 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.f
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 (usin
aud"
> To: "Jean-Michaël Celerier"
> Cc: "Jason H" , "Thiago Macieira" ,
> interest
> Subject: Re: [Interest] QDatastream, QMap, QImage serialization
>
> On 21 May 2018 at 20:12, Jean-Michaël Celerier
> wrote:
> >> Why is QImage even
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
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
___
I
ally 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
>> >
r 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"
> > To: interest@qt-project.org
> > Subject: Re: [Interest] QDatastream, QMap,
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"
> To: interest@qt-project.org
> Subject: Re: [Interest] QDatastream, QMap, QImag
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
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
> metatyp
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 f
en it shows up in the output.
Is there a way to avoid having to manually back-patch it?
Sent: Thursday, May 17, 2018 at 9:51 AM
From: "Jason H"
To: "Jean-Michaël Celerier"
Cc: "Thiago Macieira" , interest
Subject: Re: [Interest] QDatastream, QMap, QImage serializ
ly back-patch it?
Sent: Thursday, May 17, 2018 at 9:51 AM
From: "Jason H"
To: "Jean-Michaël Celerier"
Cc: "Thiago Macieira" , interest
Subject: Re: [Interest] QDatastream, QMap, QImage serialization
I'm not familar with that function, but I would guess bec
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"
To: "Jean-Michaël Celerier"
Cc: "Thiago Macieira" , interest
Subjec
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 call
> 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ôm
> Sent: Wednesday, May 16, 2018 at 11:52 PM
> From: "Thiago Macieira"
> 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 pro
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
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);
...
}
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 kno
58 matches
Mail list logo
