On 11/07/2013 07:33 PM, André Pönitz wrote:
On Thu, Nov 07, 2013 at 07:51:16AM +0100, Tomasz Olszak wrote:
2013/11/7 Uwe Rathmann uwe.rathm...@tigertal.de
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote:
Shouldn't they be in Qt5OpenGL.dll?
No, they are
Den 07-11-2013 07:40, Uwe Rathmann skrev:
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote:
Shouldn't they be in Qt5OpenGL.dll?
No, they are where they were supposed to be. That's by design.
With some nasty consequences for us users:
Our applications run on several pieces of
For Qt4 JSON support, I've used Eeli Reilins QtJSON and been very happy
with it: https://github.com/da4c30ff/qt-json. I recommend it.
We've been using Flavio Castelli's QJson in our embedded project with
Qt4 and it's worked out well.
http://qjson.sourceforge.net/
HTH,
-mandeep
Bo.
--
On Fri, 08 Nov 2013 11:47:36 +0100, Bo Thorsen wrote:
With a 7 year old board, this is what you can expect to start hitting.
It's so old, that you just can't expect brand new software to run on it.
The strategy of Qt5 is to introduce a new graphic stack but also to keep
the old old one alive.
On sexta-feira, 8 de novembro de 2013 16:31:37, Mandeep Sandhu wrote:
We've been using Flavio Castelli's QJson in our embedded project with
Qt4 and it's worked out well.
http://qjson.sourceforge.net/
I've played with it too. I would recommend using Girish's parser instead.
Compared to
On Fri, Nov 08, 2013 at 07:15:29PM +, Joseph Crowell wrote:
AFAIK you can build Qt5 with no-opengl switch and you should be able to run
QtWidgets applications without having libQt5OpenGl dependency in libQt5Gui.
The problem is that this won't scale. One cannot provide custom builds of
On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote:
On 7 November 2013 00:38, Thiago Macieira thiago.macie...@intel.com wrote:
On quarta-feira, 6 de novembro de 2013 20:12:33,
phil.kursawe@gmail.comwrote:
I see. I thought Qt renders using the system natively. It could
On quinta-feira, 7 de novembro de 2013 08:34:53, Philipp Kursawe wrote:
OpenGL should not be a dependency on a base windowing framework imho.
We disagree. We concluded a couple of years ago that OpenGL is the future.
Therefore, that's not an argument.
What would be an argument would be to be
On Thu, Nov 07, 2013 at 07:51:16AM +0100, Tomasz Olszak wrote:
2013/11/7 Uwe Rathmann uwe.rathm...@tigertal.de
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote:
Shouldn't they be in Qt5OpenGL.dll?
No, they are where they were supposed to be. That's by design.
On 7 November 2013 19:42, Thiago Macieira thiago.macie...@intel.com wrote:
On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote:
On 7 November 2013 00:38, Thiago Macieira thiago.macie...@intel.com
wrote:
On quarta-feira, 6 de novembro de 2013 20:12:33,
I wonder... what are the reasons for this dependency?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
On quarta-feira, 6 de novembro de 2013 13:26:56, Philipp Kursawe wrote:
I wonder... what are the reasons for this dependency?
The QOpenGL* classes that are in QtGui.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Shouldn't they be in Qt5OpenGL.dll?
On Wed, Nov 6, 2013 at 4:41 PM, Thiago Macieira
thiago.macie...@intel.comwrote:
On quarta-feira, 6 de novembro de 2013 13:26:56, Philipp Kursawe wrote:
I wonder... what are the reasons for this dependency?
The QOpenGL* classes that are in QtGui.
--
2013/11/6 Philipp Kursawe phil.kurs...@gmail.com
Shouldn't they be in Qt5OpenGL.dll?
They are, but when you build Qt with OpenGL support some additional parts
of Qt Gui are built. For example OpenGL type of QPaintEngine is provided:
On quarta-feira, 6 de novembro de 2013 16:43:51, Philipp Kursawe wrote:
Shouldn't they be in Qt5OpenGL.dll?
No, they are where they were supposed to be. That's by design.
The OpenGL integration needs to be provided by the platform plugin anyway, so
OpenGL support ends up getting loaded whether
I see. I thought Qt renders using the system natively. It could load opengl
like it loads SSL support, dynamically.
How do I enable opengl rendering then for my widget based application?
From: Tomasz Olszak
Sent: Wednesday, November 6, 2013 16:58
To: Philipp Kursawe
Cc:
2013/11/6 phil.kurs...@gmail.com
I see. I thought Qt renders using the system natively. It could load
opengl like it loads SSL support, dynamically.
How do I enable opengl rendering then for my widget based application?
See http://qt-project.org/doc/qt-5.0/qtgui/qpaintengine.html#details
On quarta-feira, 6 de novembro de 2013 20:12:33, phil.kurs...@gmail.com wrote:
I see. I thought Qt renders using the system natively. It could load opengl
like it loads SSL support, dynamically.
That's a solution we really dislike. We're forced to do it for SSL, for legal
reasons.
But we
On 7 November 2013 00:38, Thiago Macieira thiago.macie...@intel.com wrote:
On quarta-feira, 6 de novembro de 2013 20:12:33, phil.kursawe@gmail.comwrote:
I see. I thought Qt renders using the system natively. It could load
opengl
like it loads SSL support, dynamically.
That's a solution we
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote:
Shouldn't they be in Qt5OpenGL.dll?
No, they are where they were supposed to be. That's by design.
With some nasty consequences for us users:
Our applications run on several pieces of embedded hardware, where one of
them had been
2013/11/7 Uwe Rathmann uwe.rathm...@tigertal.de
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote:
Shouldn't they be in Qt5OpenGL.dll?
No, they are where they were supposed to be. That's by design.
With some nasty consequences for us users:
Our applications run on several
Why don't you like the dynamic loading solution? I would always prefer it
over static linking, if possible. All plugin based systems (even Qt, where
platform is a plugin) are based on dynamic code loading.
OpenGL should not be a dependency on a base windowing framework imho.
On Wed, Nov 6, 2013
22 matches
Mail list logo
