Re: [Interest] What for does qt5gui need OpenGL?
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 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 designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. 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 Qt for each realistic user configuration, let alone proactively package such stuff in large quantities. Requiring the users to run one, or one out of a few blessed configurations is likewise infeasible. Runtime detection of capabilities and selecting features _then_ is the only viable appraoch. Andre' The platform developers can and should provide custom builds of Qt 5 for their embedded platform. The fact that embedded platform developers didn't know enough about Qt to know that they could compile Qt 5 without Open GL worrys me. Also note he wants this support because of a 7 year old embedded graphic chip. What functionality did embedded devices have 7 years ago? How far can you expect to push a 7 year old embedded graphics chip? I say stay in the past with the old Qt for that ancient device and let the rest of us move in to the future. ___ 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] What for does qt5gui need OpenGL?
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 embedded hardware, where one of them had been designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. There are reasons why Qt 4.8 is still the platform, where most users are, and one of them is because of such a design decision. After the switch from Qt 3 to 4, there were a bunch of companies that had to stay on Qt 3. A few even use it today. The reason is that Qt progressed into something that didn't work well for their platform. For whatever reason. 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. It's nice if it does, and recompiling Qt without GL might be your solution. But in general, there are some who will be hit when software moves on. This sucks for those who get hit. But there's no way the community can support every piece of legacy hardware used with Qt 3 or 4. Of course, the trick is to annoy as few as possible. But annoying some is inevitable. I don't think you will see a Qt 4.9. I might be wrong, but I doubt it. What you could do instead is to start a backport library for 4.8 where you put stuff like the JSON class in. Make it public in github, you're not going to be the only one stuck on Qt 4. There might be others who will contribute other classes to this. 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. Bo. -- Bo Thorsen, European Engineering Manager, ICS Integrated Computer Solutions. Delivering World-Class Applications http://ics.com/services ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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. -- Bo Thorsen, European Engineering Manager, ICS Integrated Computer Solutions. Delivering World-Class Applications http://ics.com/services ___ 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] What for does qt5gui need OpenGL?
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. Of course I can't expect to run something new on an outdated board, but it doesn't necessarily has to mean regression when using the old graphic stack. Almost all embedded applications with some history are running QWS/ widgets where is no comparable replacement in Qt5 ( I know nobody wants to work on QWS code for understandable reasons ). In fact this is the point where our Qt5 consideration failed - sorry for my ignorance about the no-opengl flag, but we never got so far. -- If someone is interested: we are also writing a new application on a brand new type of hardware - so no legacy issues here: Our main problem is/was, that our test department is using a VNC based test tool and beside X11 there is no easy way to get it running with Qt5 ( Qt4/QWS supports it out of the box ). For a QML application Qt5/X11 is o.k., but when using widgets only the combination Qt4/X11 offers hardware acceleration. Finally we decided to go with Qt5/X11 ( hoping for some VNC support in Wayland later ) - and for no strong reason with QML. I don't think you will see a Qt 4.9. I might be wrong, but I doubt it. What you could do instead is to start a backport library for 4.8 where you put stuff like the JSON class in. Such a backport already exists - that's why I mentioned it. Being the maintainer of the Qwt project I'm in contact with many developers of Qt applications and as far as I can see almost nobody did a Qt5 migration - even if it would be pretty easy for average desktop application code. Maybe you have a good explanation for this ? Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 QJsonDocument, Girish's parser is only about 10x slower. Flavio's is 30x. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 Qt for each realistic user configuration, let alone proactively package such stuff in large quantities. Requiring the users to run one, or one out of a few blessed configurations is likewise infeasible. Runtime detection of capabilities and selecting features _then_ is the only viable appraoch. The platform developers can and should provide custom builds of Qt 5 for their embedded platform. The fact that embedded platform developers didn't know enough about Qt to know that they could compile Qt 5 without Open GL worrys me. The platform case is not the problem as such. The worrying case are the people who need to build Qt for an unknown set of target configuration, like the typical pre-build Windows application that bundles their libraries, or even Linux distributions themselves. Andre' ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 load opengl like it loads SSL support, dynamically. That's a solution we really dislike. Would you mind explaining why? My knowledge of this level of design is virtually non-existent so your input would be hugely appreciated (even if you can just provide me with a few related key words so that I may research the concepts that influenced the design decision myself). Dynamic loading a library requires that we write the code to find the library to be loaded. That's extra code that we need to write, duplicating what the dynamic loader already has. Unlike plugins, libraries can be anywhere in the system. Also, libraries on Unix systems have version numbers attached to the file names and we have to know *which* number to find. For example, for libudev, we need to scan for both libudev.so.0 and libudev.so.1. That means we, the developers, need to guess what the system has. We can't indiscriminately load any number, since we don't know whether libudev.so.2 will retain compatibility. Dynamic loading also requires that we provide fallback code, if the library we request is missing. That's because dynamic loading does not write a requirement into the library's header, which packaging tools know to look for. For the libudev case, we had to ensure that QtSerialPort has fallback in case it can't use udev to find the serial ports. For SSL support, we transferred the to the users: you *have* to check if QSslSocket::supportsSsl() returns true before you start using SSL. Another drawback is that it generates worse code. Unless we start writing assembly by hand, per platform, our finding and calling of functions in loaded libraries is not going to be as efficient as the one generated by the compiler and linker. We've done both solutions that search for all functions at startup (SSL), which in turn means we have a load-time impact searching for functions that may or may not ever be used; and we have solutions that do lazy lookups (D-Bus), but then the application has no graceful way to fail if a function is missing at runtime: it can only crash. There's also an issue of thread-safety: libraries properly linked to get loaded and initialised before the application reaches main(), which means no threads are running. Libraries dynamically loaded may be loaded into the application while multiple threads are running. Some libraries may not like being accessed from multiple threads. And then there's the question of when to unload them. We have to figure out when to unload those libraries by ourselves. I did a lot of work to rewrite the QLibrary static unloader in Qt 5.2 and, trust me, it was not easy. Moreover, we may end up unloading a library from QtCore's global destructors before another global destructor gets run, one that still requires the library. Our best bet would be to actually leak the loaded libraries. Finally, on platforms that make use of prelinking, libraries only loaded through dynamic loading will, at best, not be prelinked. At worst, it will actually have been prelinked to the wrong address and cause a pessimisation. So, in all, I will oppose any use of dynamic loading of libraries. I will accept only when we're forced to, like udev and OpenSSL. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 able to support in the same build multiple GL libraries: ANGLE, desktop GL, GL ES, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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. With some nasty consequences for us users: Our applications run on several pieces of embedded hardware, where one of them had been designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. 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 Qt for each realistic user configuration, let alone proactively package such stuff in large quantities. Requiring the users to run one, or one out of a few blessed configurations is likewise infeasible. Runtime detection of capabilities and selecting features _then_ is the only viable appraoch. Andre' ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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, 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 really dislike. Would you mind explaining why? My knowledge of this level of design is virtually non-existent so your input would be hugely appreciated (even if you can just provide me with a few related key words so that I may research the concepts that influenced the design decision myself). Dynamic loading a library requires that we write the code to find the library to be loaded. That's extra code that we need to write, duplicating what the dynamic loader already has. Unlike plugins, libraries can be anywhere in the system. Also, libraries on Unix systems have version numbers attached to the file names and we have to know *which* number to find. For example, for libudev, we need to scan for both libudev.so.0 and libudev.so.1. That means we, the developers, need to guess what the system has. We can't indiscriminately load any number, since we don't know whether libudev.so.2 will retain compatibility. Dynamic loading also requires that we provide fallback code, if the library we request is missing. That's because dynamic loading does not write a requirement into the library's header, which packaging tools know to look for. For the libudev case, we had to ensure that QtSerialPort has fallback in case it can't use udev to find the serial ports. For SSL support, we transferred the to the users: you *have* to check if QSslSocket::supportsSsl() returns true before you start using SSL. Another drawback is that it generates worse code. Unless we start writing assembly by hand, per platform, our finding and calling of functions in loaded libraries is not going to be as efficient as the one generated by the compiler and linker. We've done both solutions that search for all functions at startup (SSL), which in turn means we have a load-time impact searching for functions that may or may not ever be used; and we have solutions that do lazy lookups (D-Bus), but then the application has no graceful way to fail if a function is missing at runtime: it can only crash. There's also an issue of thread-safety: libraries properly linked to get loaded and initialised before the application reaches main(), which means no threads are running. Libraries dynamically loaded may be loaded into the application while multiple threads are running. Some libraries may not like being accessed from multiple threads. And then there's the question of when to unload them. We have to figure out when to unload those libraries by ourselves. I did a lot of work to rewrite the QLibrary static unloader in Qt 5.2 and, trust me, it was not easy. Moreover, we may end up unloading a library from QtCore's global destructors before another global destructor gets run, one that still requires the library. Our best bet would be to actually leak the loaded libraries. Finally, on platforms that make use of prelinking, libraries only loaded through dynamic loading will, at best, not be prelinked. At worst, it will actually have been prelinked to the wrong address and cause a pessimisation. So, in all, I will oppose any use of dynamic loading of libraries. I will accept only when we're forced to, like udev and OpenSSL. -- 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 Hi Thiago, Thank you very much for taking the time out to write that up. I appreciate it immensely! Have a great weekend, William. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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. -- 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] What for does qt5gui need OpenGL?
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: http://qt-project.org/doc/qt-5.0/qtgui/qpaintengine.html#Type-enum -- regards, Tomasz Olszak ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 QtGui contained OpenGL-related classes or not. So we might as well deep-integrate the functionality. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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: interest@qt-project.org 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: http://qt-project.org/doc/qt-5.0/qtgui/qpaintengine.html#Type-enum -- regards, Tomasz Olszak___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 QGLWidget is what you looking for. -- regards / pozdrawiam, Tomasz Olszak Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Developer | http://qt-project.org http://linkedin.com/in/tolszak ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 don't want it, neither for OpenGL, nor for ICU. And we're only doing it for udev in Qt 5.2 because we're, again, forced to. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 really dislike. Would you mind explaining why? My knowledge of this level of design is virtually non-existent so your input would be hugely appreciated (even if you can just provide me with a few related key words so that I may research the concepts that influenced the design decision myself). Thanks! William Hallatt ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. There are reasons why Qt 4.8 is still the platform, where most users are, and one of them is because of such a design decision. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 pieces of embedded hardware, where one of them had been designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. AFAIK you can build Qt5 with no-opengl switch and you should be able to run QtWidgets applications without having libQt5OpenGl dependency in libQt5Gui. -- regards, Tomasz Olszak ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
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 at 11:38 PM, Thiago Macieira thiago.macie...@intel.comwrote: 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 really dislike. We're forced to do it for SSL, for legal reasons. But we don't want it, neither for OpenGL, nor for ICU. And we're only doing it for udev in Qt 5.2 because we're, again, forced to. -- 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
