Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
Em qua 12 fev 2014, às 08:01:23, Kurt Pattyn escreveu: We can always 'duplicate' some code from the std::random library How 'secure' should this be? Is a Mersenne-Twister for instance 'secure' enough? As secure as we can get it. We should use the CPU instructions and/or /dev/random whenever possible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] GL headers in Qt5GuiConfigExtras.cmake
I build 5.2.1 for a embedded system and the generated Qt5GuiConfigExtras.cmake
fails to find GLES2/gl2.h.
The reason is that the including dir GLES2 is used twice in the find command,
GLES2/gl2.h is searched for in /usr/include/GLES2, but there is no
/usr/include/GLES2/GLES2/gl2.h:
set(_GL_INCDIRS /usr/include/GLES2)
find_path(_qt5gui_OPENGL_INCLUDE_DIR GLES2/gl2.h
PATHS ${_GL_INCDIRS}
NO_DEFAULT_PATH
)
gui.pro adds GLES2 to the header path: CMAKE_GL_HEADER_NAME = GLES2/gl2.h
Should I create a patch or is this error only caused by my somehow broken setup?
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] armv5 and armv7 in one apk. How to deploy?
Hello All in this group! Is it possible to place armv5 and armv7 in one apk or I must create different apk for different platforms? Please help me with advice or documentation page. Thanks a lot! -- Oleg Shalnev (Kalpa Project) -- mailto: o...@kalpa.ru skype: oleg_shalnev cell: +79187417217 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
On Wednesday, February 12, 2014 09:19:35 Peter Kuemmel wrote: I build 5.2.1 for a embedded system and the generated Qt5GuiConfigExtras.cmake fails to find GLES2/gl2.h. The reason is that the including dir GLES2 is used twice in the find command You'll need to find out why it's generated that way. Variables from qmake populate the fields. Find out what the variables are, why they have the values they do etc, and whether there is a bug somewhere. , GLES2/gl2.h is searched for in /usr/include/GLES2, but there is no /usr/include/GLES2/GLES2/gl2.h: set(_GL_INCDIRS /usr/include/GLES2) Where does this come from? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] i.MX6 zero copy video playback
Hi, I finally got around to polish and upstream zero copy video playback for the i.MX6. The change: https://codereview.qt-project.org/#change,76764 A video showcasing the functionality: http://www.youtube.com/watch?v=pmxsWGhrrBQ Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] armv5 and armv7 in one apk. How to deploy?
Hi, Long long time ago, with some little effort you could put both armv5 and armv7 libs in the same .pak, sadly starting with Qt 5.2 it is very hard to do it. If your application doesn't do any complicated CPU computation itself and relies only on Qt libs to do the hard work, and if you are using Ministro you can put on your .apk only armv5 libs. Ministro will download armv7 Qt libs on all armv7 devices and armv5 libs on armv5 devices. This way you can target armv5armv7 devices with a single .apk. Cheers, BogDan. Hello All in this group! Is it possible to place armv5 and armv7 in one apk or I must create different apk for different platforms? Please help me with advice or documentation page. Thanks a lot! -- Oleg Shalnev (Kalpa Project) -- mailto: o...@kalpa.ru skype: oleg_shalnev cell : +79187417217 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release Testing)
Hi Kai, On 25.10.13 10:05, Koehne Kai wrote: I think the link is outdated. MinGW-builds nowadays supported both dw2 and sjlj exception handling for 32 bit since ages, see e.g. http://mingw-w64.sourceforge.net/download.php#mingw-builds (Note that the Mingw-w64 and MinGW-builds projects joined forces just recently, so the mingw-builds binaries are the 'officially endorsed' ones). Anyhow, Qt itself doesn't really care about SJLJ vs dw2: It compiles just fine with both versions. It's just that, since 5.1, we're building the 'official' packages with a dw2 toolchain. Are there any plans to also provide official SJLJ packages for mingw-w64 ? Right now people that don't want to build themselves have to go 3rd party sites like http://sourceforge.net/projects/qtx64/files/qt-x64/5.2.1/mingw-4.8/ (Yes, SJLJ is inferior to SEH, but sometimes you don't control the whole stack/hell of DLLs and just need to use SJLJ) thanks, Markus -- Woboq GmbH | http://woboq.com/ Geschäftsführer: Markus Goetz, Olivier Goffart Hermannstr. 134, 12051 Berlin, Germany Handelsregister: Amtsgericht Berlin (Charlottenburg) HRB 137795 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
On Monday 10 Feb 2014 17:07:11 Shaw Andy wrote: Since the feature freeze is on the 14th I have been eagerly awaiting the changes that have been indicated already have been done so I can carry on testing. Have I missed some updates or something? I am concerned because I know how many people use the printing and we need to try and get these changes tested and fixed where necessary in good time for the final so the transition is not really noticed by the users. So is there any update on these patches or should we consider waiting until Qt 5.4 to ensure they are all ready correctly? Sorry, needed to wait until the full stack of changes had been completed and integrated before pushing. The revised patches are up for review, I'm not sure we'll get it done in time, but it's worth a crack, otherwise I'll have to slog through the old code again fixing all the bugs I found for 5.3, only to replace the code again in 5.4. Apologies for the rebase, but it was needed. Main changes are: * Removed QPageMargins and added QMarginsF instead * QPageLayout uses QMarginsF and now has an enum and attribute for QPageLayout::Units to track what units are used for all the margins. Turns out while this complicates some public api, it also simplifies the way the class is used in real code. * QPageSize also has a QPageSize::Unit, that duplicates QPageLayout::Unit but I couldn't find a nice place to put a common enum. * Both QPageLayout::Unit and QPageSize::Unit don't have a value for DevicePixels anymore as it doesn't make sense. That simplifies api in a number of places by removing the resolution parm. The main issues outstanding I see: * Mac issue with PMPaper: in my testing I need the extra PMRetain to prevent a crash, but Morten gets a memory leak with it, and Andy reports it crashes for him anyway. Try the latest code, if the issue still persists I'll look for an alternative way of doing things. * Win is reported as being slow, that's an issue with the old code too, but the new code may make it slightly slower. It's due to the DC being refreshed every time a setting is changed, which is plain slow. Once the new code is in and handling the layout calculations, I think it's possible to remove the DC refresh at every step and just init the DC when start() is called. If anyone else wants to test this, there's a few things you can run besides the auto tests: examples/widgets/richtex/textedit tests/manual/dialogs tests/manual/qprintdevice_dump Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
set(_GL_INCDIRS /usr/include/GLES2)
Where does this come from?
Generated by Qt5GuiConfigExtras.cmake.in
set(_GL_INCDIRS $$CMAKE_GL_INCDIRS)
find_path(_qt5gui_OPENGL_INCLUDE_DIR $$CMAKE_GL_HEADER_NAME
PATHS ${_GL_INCDIRS}
!!IF !mac
NO_DEFAULT_PATH
!!ENDIF
)
gui.pro defines CMAKE_GL_INCDIRS and CMAKE_GL_HEADER_NAME:
!isEmpty(QMAKE_INCDIR_OPENGL_ES2): CMAKE_GL_INCDIRS =
$$cmakeTargetPaths($$QMAKE_INCDIR_OPENGL_ES2)
...
CMAKE_GL_HEADER_NAME = GLES2/gl2.h
and QMAKE_INCDIR_OPENGL_ES2 is set by configure to
QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include/GLES2
So, I would say there is one GLES2 too much in gui.pro.
I only wonder why it works for others (or maybe it is not used at all)
Thanks,
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
On Wednesday, February 12, 2014 12:11:42 Peter Kuemmel wrote: and QMAKE_INCDIR_OPENGL_ES2 is set by configure to QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include/GLES2 Is this correct? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The VS2008 WinCE errors
On Tuesday, February 11, 2014 12:59:45 Thiago Macieira wrote: Current tests are frequently showing the following error messages: c: \work\build\qt\qtbase\tests\auto\corelib\global\qtendian\tst_qtendian.cpp(14 0) : fatal error C1001: An internal error has occurred in the compiler. If this proves to be too much work we can just disable building tests. They aren't run anyway. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release Testing)
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Markus Goetz Sent: Wednesday, February 12, 2014 11:45 AM To: development@qt-project.org Subject: [Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release Testing) Hi Kai, On 25.10.13 10:05, Koehne Kai wrote: I think the link is outdated. MinGW-builds nowadays supported both dw2 and sjlj exception handling for 32 bit since ages, see e.g. http://mingw-w64.sourceforge.net/download.php#mingw-builds (Note that the Mingw-w64 and MinGW-builds projects joined forces just recently, so the mingw-builds binaries are the 'officially endorsed' ones). Anyhow, Qt itself doesn't really care about SJLJ vs dw2: It compiles just fine with both versions. It's just that, since 5.1, we're building the 'official' packages with a dw2 toolchain. Are there any plans to also provide official SJLJ packages for mingw-w64 ? No, there aren't any plans AFAIK. If we'll add a new configuration it'll most likely be a 64 bit one, and we really can't stretch the number of Windows binary packages much further. Right now people that don't want to build themselves have to go 3rd party sites like http://sourceforge.net/projects/qtx64/files/qt-x64/5.2.1/mingw-4.8/ I don't know about this project. However, the mingw-builds folks are also providing Qt packages, which I can only recommend: http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages I'm all for featuring these a bit more prominently within Qt ... (Yes, SJLJ is inferior to SEH, but sometimes you don't control the whole stack/hell of DLLs and just need to use SJLJ) Understood. We just made the choice for DW2 because SJLJ was a lot slower, even for people who don't use exceptions. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The VS2008 WinCE errors
Hi Thiago, the internal error is a compiler bug. We don't exactly know whats necessary to trigger it. It happens more likely if there is more than one instance of the compiler running at the same time, or if a visual studio environment is opened. However some code pathes might be triggering this too. The preprocessor output can be found here: http://www.kdab.com/~bjoern/tst_qatomicint.7z Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Dienstag, 11. Februar 2014, 12:59:45 schrieb Thiago Macieira: Current tests are frequently showing the following error messages: c: \work\build\qt\qtbase\tests\auto\corelib\global\qtendian\tst_qtendian.cpp(14 0) : fatal error C1001: An internal error has occurred in the compiler. Anyone who can try to test what we could shuffle around to get rid of the error? The other error is: ..\tst_qatomicinteger.cpp(168) : error C2027: use of undefined type 'QStaticAssertFailureTest' Line 168 is a function declaration in the middle of the class: void fetchAndSub(); The nearest Q_STATIC_ASSERT is 20 lines down, in a function which is not the one declared above: Q_STATIC_ASSERT(sizeof(QAtomicIntegerT) == sizeof(T)); Q_STATIC_ASSERT(Q_ALIGNOF(QAtomicIntegerT) == Q_ALIGNOF(TypeInStructT)); This appears to be the char16_t test, but since VS 2008 does not support Unicode strings, the test should compile with T == int and simply cause a QSKIP in initTestCase. Given: - the above ICE - the fact that there's problem for compiling short, ushort, wchar_t or char32_t - 16-bit atomics are not supported on WinCE due to lack of intrinsics I'm guessing it's *also* a compiler bug. But can someone verify my assumptions? That it's the char16_t test, that the preprocessor output was correct and using QAtomicIntegerint, that there's a QSKIP in initTestCase? smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release Testing)
On Wed, Feb 12, 2014 at 12:03 PM, Koehne Kai kai.koe...@digia.com wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Markus Goetz Sent: Wednesday, February 12, 2014 11:45 AM To: development@qt-project.org Subject: [Development] SJLJ vs DW2 (Was: Re: Qt 5.2.0 - Beta Release Testing) Hi Kai, On 25.10.13 10:05, Koehne Kai wrote: I think the link is outdated. MinGW-builds nowadays supported both dw2 and sjlj exception handling for 32 bit since ages, see e.g. http://mingw-w64.sourceforge.net/download.php#mingw-builds (Note that the Mingw-w64 and MinGW-builds projects joined forces just recently, so the mingw-builds binaries are the 'officially endorsed' ones). Anyhow, Qt itself doesn't really care about SJLJ vs dw2: It compiles just fine with both versions. It's just that, since 5.1, we're building the 'official' packages with a dw2 toolchain. Are there any plans to also provide official SJLJ packages for mingw-w64 ? No, there aren't any plans AFAIK. If we'll add a new configuration it'll most likely be a 64 bit one, and we really can't stretch the number of Windows binary packages much further. Right now people that don't want to build themselves have to go 3rd party sites like http://sourceforge.net/projects/qtx64/files/qt-x64/5.2.1/mingw-4.8/ I don't know about this project. However, the mingw-builds folks are also providing Qt packages, which I can only recommend: http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages I'm all for featuring these a bit more prominently within Qt ... That would be great. The Qt-builds project has morphed a bit (it's now built via the MSYS2 project). While Qt-builds is fantastic, MSYS2 is IMHO the best thing to happen to Open Source on Windows since MinGW-w64. Alexey ported Arch Linux's pacman package manager and a large set of MSYS2 packages as well as ones for Windows 32bit and Windows 64bit, including of course Qt5, QtCreator and Qbs (and hundreds more packages). You can see the PKGBUILD and patch files here: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qtcreator https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5 Installing Qt5 and all its dependencies is as easy as: pacman -S mingw-w64-i686-qt pacman -S mingw-w64-x86_64-qt building if from source isn't *much* more complicated than: cd /c/repo/mingw-w64-qt5 makepkg-mingw The only real documentation we've got is: http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ Arch Linux users/developers should be quite at home in this environment. (Yes, SJLJ is inferior to SEH, but sometimes you don't control the whole stack/hell of DLLs and just need to use SJLJ) MSYS2's Win64 GCC is SEH (and hence so are all the Win64 packages). Understood. We just made the choice for DW2 because SJLJ was a lot slower, even for people who don't use exceptions. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
and QMAKE_INCDIR_OPENGL_ES2 is set by configure to QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include/GLES2 Is this correct? Yes, in this directory is gl2.h. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Calendar
On 01/17/2014 05:34 PM, Mitch Curtis wrote: On 12/06/2013 02:02 PM, Mitch Curtis wrote: Hello. At the beginning of this year I started work on a Calendar for Qt Quick Controls as a sort of side project. After removing the WIP from the commit message, I got some feedback from developers who either a) had also wrote a Calendar for KDE stuff or b) suggested I ask for feedback from plasma-devel. Rather than add to the already massive list of patch sets for that change, I thought it would be better to truly open up the Calendar for contributions before it goes in by creating a WIP branch for it in the Qt Quick Controls repo [1]: wip/calendar It'll be a throwaway branch, so every commit must be atomic and follow all of the normal Qt commit policies [2][3]. At the end, we'll resubmit every individual change to qtquickcontrols' dev branch. Please feel free to submit patches or provide feedback on what's already there. For example, it has already been suggested that there should be a C++ backend for the models, dates, etc. Cheers. [1] https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a [2] http://qt-project.org/wiki/Branch-Guidelines [3] http://qt-project.org/wiki/Commit_Policy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development For the Plasma folk that are interested - an example that demonstrates events (which are stored in an SQL database) integrated into the Calendar: https://codereview.qt-project.org/#change,75883 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development We've changed a direction a bit and have instead squashed the WIP branch changes into one change, as the history was not really that useful and it makes it easier to review. The final change is: https://codereview.qt-project.org/#change,77806 Styling improvements will come afterwards, but hopefully before 5.3. :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
On Wednesday, February 12, 2014 14:00:11 Peter Kuemmel wrote: and QMAKE_INCDIR_OPENGL_ES2 is set by configure to QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include/GLES2 Is this correct? Yes, in this directory is gl2.h. I don't think I got my point across. Would QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include be correct? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
Gesendet: Mittwoch, 12. Februar 2014 um 14:14 Uhr
Von: Stephen Kelly stephen.ke...@kdab.com
An: development@qt-project.org
Betreff: Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
On Wednesday, February 12, 2014 14:00:11 Peter Kuemmel wrote:
and QMAKE_INCDIR_OPENGL_ES2 is set by configure to
QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include/GLES2
Is this correct?
Yes, in this directory is gl2.h.
I don't think I got my point across. Would
QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include
be correct?
Yes, with this QMAKE_INCDIR_OPENGL_ES2 value the Qt5GuiConfigExtras.cmake would
be correct.
But I don't know the impact of changing QMAKE_INCDIR_OPENGL_ES2 in configure,
it is used at several places:
$ grep QMAKE_INCDIR_OPENGL_ES2 -r *
config.tests/unix/opengles2/opengles2.pro:INCLUDEPATH +=
$$QMAKE_INCDIR_OPENGL_ES2
configure:echo QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2
and QMAKE_LIBS_OPENGL_ES2 in
configure:QMAKE_INCDIR_OPENGL_ES2=`$PKG_CONFIG --cflags-only-I glesv2
2/dev/null | sed -e 's,^-I,,g' -e 's, -I, ,g'`
configure:QMakeVar set QMAKE_INCDIR_OPENGL_ES2
`shellArgumentListToQMakeList $QMAKE_INCDIR_OPENGL_ES2`
configure:echo QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 and
QMAKE_LIBS_OPENGL_ES2 in
configure:if [ -n $QMAKE_INCDIR_OPENGL_ES2 ]; then
configure:echo QMAKE_INCDIR_OPENGL_ES2 = `shellArgumentListToQMakeList
$QMAKE_INCDIR_OPENGL_ES2` $QTCONFIG.tmp
mkspecs/devices/linux-mipsel-broadcom-97425-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2
= $${BRCM_ROCKFORD_PATH}/middleware/v3d/interface/khronos/include
mkspecs/devices/linux-beagleboard-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 =
$${QMAKE_INCDIR_EGL}
mkspecs/devices/linux-archos-gen8-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 =
$${QMAKE_INCDIR_EGL}
mkspecs/devices/linux-rasp-pi-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 =
$${QMAKE_INCDIR_EGL}
mkspecs/devices/linux-sh4-stmicro-ST7540-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2
+= $$QMAKE_INCDIR_EGL
mkspecs/devices/linux-arm-trident-pnx8473-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2
= $${TRIDENT_SHINER_SDK_INCDIR_EGL_OPENGL_ES2}
mkspecs/features/win32/opengl.prf:INCLUDEPATH +=
$$QMAKE_INCDIR_OPENGL_ES2
mkspecs/features/unix/opengl.prf:INCLUDEPATH += $$QMAKE_INCDIR_OPENGL_ES2
mkspecs/common/linux-android.conf:QMAKE_INCDIR_OPENGL_ES2 =
mkspecs/common/linux.conf:QMAKE_INCDIR_OPENGL_ES2 = $$QMAKE_INCDIR_OPENGL
mkspecs/common/ios/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 =
mkspecs/unsupported/linux-host-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 =
$$QMAKE_INCDIR_OPENGL
mkspecs/unsupported/android-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 =
mkspecs/hurd-g++/qmake.conf:QMAKE_INCDIR_OPENGL_ES2 = $$QMAKE_INCDIR_OPENGL
qmake/doc/src/qmake-manual.qdoc:\section1 QMAKE_INCDIR_OPENGL_ES1,
QMAKE_INCDIR_OPENGL_ES2
src/gui/gui.pro:!isEmpty(QMAKE_INCDIR_OPENGL_ES2): CMAKE_GL_INCDIRS =
$$cmakeTargetPaths($$QMAKE_INCDIR_OPENGL_ES2)
src/gui/gui.pro:CMAKE_OPENGL_INCDIRS =
$$cmakePortablePaths($$QMAKE_INCDIR_OPENGL_ES2)
Thanks,
--
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software
Solutions___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
On Wednesday, February 12, 2014 15:11:25 Peter Kuemmel wrote: Gesendet: Mittwoch, 12. Februar 2014 um 14:14 Uhr Von: Stephen Kelly stephen.ke...@kdab.com An: development@qt-project.org Betreff: Re: [Development] GL headers in Qt5GuiConfigExtras.cmake On Wednesday, February 12, 2014 14:00:11 Peter Kuemmel wrote: and QMAKE_INCDIR_OPENGL_ES2 is set by configure to QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include/GLES2 Is this correct? Yes, in this directory is gl2.h. I don't think I got my point across. Would QMAKE_INCDIR_OPENGL_ES2 = .../sysroot/usr/include be correct? Yes, with this QMAKE_INCDIR_OPENGL_ES2 value the Qt5GuiConfigExtras.cmake would be correct. So, what should it *actually* be? Is it a bug that it is one value instead of the other? Where is it set to what it is set to? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ActiveQt AxServer with CMake
Hi, Has anyone managed to create an ActiveQt server with CMake? I got it working with qmake but we need to do this with CMake. I also tried idc manually after CMake but then I keep getting the error: QObject::startTimer: Timers can only be used with threads started with QThread IDL generation failed trying to run program myapp.exe! Thanks, Daniel This message is subject to the following terms and conditions: MAIL DISCLAIMERhttp://www.barco.com/en/maildisclaimer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
On Wednesday 12 Feb 2014 12:03:53 John Layt wrote: On Monday 10 Feb 2014 17:07:11 Shaw Andy wrote: Since the feature freeze is on the 14th I have been eagerly awaiting the changes that have been indicated already have been done so I can carry on testing. Have I missed some updates or something? I am concerned because I know how many people use the printing and we need to try and get these changes tested and fixed where necessary in good time for the final so the transition is not really noticed by the users. So is there any update on these patches or should we consider waiting until Qt 5.4 to ensure they are all ready correctly? Sorry, needed to wait until the full stack of changes had been completed and integrated before pushing. The revised patches are up for review, I'm not sure we'll get it done in time, but it's worth a crack, otherwise I'll have to slog through the old code again fixing all the bugs I found for 5.3, only to replace the code again in 5.4. If people don't quite feel confident taking all the changes at once, one option is to take up Morten's earlier suggestion of not using the new platform plugin code just yet, i.e. * Merge the QPageLayout and QPageSize code and its use in QPrinter and QPrintEngine, as this is the code that fixes many bugs and removes the duplicated inconsistent code that is at the root of many issues. * Change the existing platform code to use QPageSize and QPageLayout internally * Merge the new QPA code, but don't use it as yet,and have the auto tests and manual tests available for people to test it more thoroughly. * Keep the patches switching to the new platform plugin code in reserve to either switch for 5.3 if testing proves the plugin is stable enough, or more likely to use in 5.4 if not. The main issues outstanding I see: I missed the issue around the QPageLayout flag setters/getters which needs clarification. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ActiveQt AxServer with CMake
On Wednesday, February 12, 2014 14:24:05 Fricot, Daniel wrote: Hi, Has anyone managed to create an ActiveQt server with CMake? I got it working with qmake but we need to do this with CMake. You might try the cmake users mailing list. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote: On 11 Feb 2014, at 19:14, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu: http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful No doubt. And we should have a more secure generator, at least until we can rely on std::random. We can always 'duplicate' some code from the std::random library :-) How 'secure' should this be? Is a Mersenne-Twister for instance 'secure' enough? Secure enough for a simple Monte-Carlo style simulation? Yes, definitely, that's what it was designed for. Secure enough for the initial WebSocket implementation in Qt 5.3? Well, not really, but let's go with it (qrand) and fix it in 5.4. Secure enough for cryptography? Hell no! Anyone up for creating a nice function for Qt 5.4? Ping me when the reviews are due. I'm very interested in it, but lack time for programming it. Konrad signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
Hi, The main issues outstanding I see: My finding using Windows 8.1 / HP Color LaserJet 6030 MFP PS Class Driver is that the default paper size is B5 (instead of letter/A4) and it simply does not print (using A4), although the code calling EndPage/EndDoc is executed. Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ActiveQt AxServer with CMake
Has anyone managed to create an ActiveQt server with CMake?
To clarify, is the problem with running the IDC/IDL tools or some
other step? The CMake logic we've used for this is roughly:
set(IDL_COMMANDS
COMMAND idl ${BINARY_PATH} -idl ${BINARY_PATH}.idl
COMMAND midl ${BINARY_PATH}.idl ${BINARY_PATH}.tlb
COMMAND idc ${BINARY_PATH} -tlb ${BINARY_PATH}.tlb)
add_custom_command(TARGET ${SERVER_TARGET} POST_BUILD ${IDL_COMMANDS}
COMMENT Generating and embedding type library)
Where ${SERVER_TARGET} is the name of the executable target that is
the ActiveX server and ${BINARY_PATH}
is set to '$TARGET_FILE:SERVER_TARGET' - CMake automatically expands
that to the .exe path at build time.
So the target is built as normal and then idl/idc is run as a
post-build step whenever the target is rebuilt.
Regards,
Rob.
On 12 February 2014 14:24, Fricot, Daniel daniel.fri...@barco.com wrote:
Hi,
Has anyone managed to create an ActiveQt server with CMake? I got it working
with qmake but we need to do this with CMake. I also tried idc manually
after CMake but then I keep getting the error:
QObject::startTimer: Timers can only be used with threads started with
QThread
IDL generation failed trying to run program myapp.exe!
Thanks,
Daniel
This message is subject to the following terms and conditions: MAIL
DISCLAIMER
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)
On 12 February 2014 14:44, Konrad Rosenbaum kon...@silmor.de wrote: On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote: On 11 Feb 2014, at 19:14, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu: http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful No doubt. And we should have a more secure generator, at least until we can rely on std::random. We can always 'duplicate' some code from the std::random library :-) How 'secure' should this be? Is a Mersenne-Twister for instance 'secure' enough? Secure enough for a simple Monte-Carlo style simulation? Yes, definitely, that's what it was designed for. Secure enough for the initial WebSocket implementation in Qt 5.3? Well, not really, but let's go with it (qrand) and fix it in 5.4. It's really fine for this use-case as I said in my earlier email. Qt does not provide any form of sandbox - all code that can use the websockets classes is either 1) trusted or 2) must be secured by a sandbox provided by the application. Given this, the only purpose of the masking in Qt is to prevent accidental problems due to triggering the class of problems that lead to request smuggling flaws in proxies. Making the mask change is really only necessary so that you won't get a consistent failure (since the second time the mask will be different). This is a completely different environment to use the use of websockets in a browser where untrusted code is being run and could potentially exploit request smuggling to by-pass SOP, which is why they need secure random numbers and we do not. It would be nice to have a secure random number source in Qt, but that's a completely different question. Regards Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Calendar
On Wed, Feb 12, 2014 at 2:12 PM, Mitch Curtis mitch.cur...@digia.com wrote: On 01/17/2014 05:34 PM, Mitch Curtis wrote: On 12/06/2013 02:02 PM, Mitch Curtis wrote: Hello. At the beginning of this year I started work on a Calendar for Qt Quick Controls as a sort of side project. After removing the WIP from the commit message, I got some feedback from developers who either a) had also wrote a Calendar for KDE stuff or b) suggested I ask for feedback from plasma-devel. Rather than add to the already massive list of patch sets for that change, I thought it would be better to truly open up the Calendar for contributions before it goes in by creating a WIP branch for it in the Qt Quick Controls repo [1]: wip/calendar It'll be a throwaway branch, so every commit must be atomic and follow all of the normal Qt commit policies [2][3]. At the end, we'll resubmit every individual change to qtquickcontrols' dev branch. Please feel free to submit patches or provide feedback on what's already there. For example, it has already been suggested that there should be a C++ backend for the models, dates, etc. Cheers. [1] https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a [2] http://qt-project.org/wiki/Branch-Guidelines [3] http://qt-project.org/wiki/Commit_Policy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development For the Plasma folk that are interested - an example that demonstrates events (which are stored in an SQL database) integrated into the Calendar: https://codereview.qt-project.org/#change,75883 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development We've changed a direction a bit and have instead squashed the WIP branch changes into one change, as the history was not really that useful and it makes it easier to review. The final change is: https://codereview.qt-project.org/#change,77806 Styling improvements will come afterwards, but hopefully before 5.3. :) Hi Mitch, I just went over all the code (just skimming over it) and i really like the approach you've chosen :) A real good cool job on your side! Too bad i couldn't provide any help during the development of this. But i will gracefully use your creation when trying to hook in the Akonadi calendar events once Qt 5.3 is out. Thanks again! Cheers, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Plans for printing in 5.3 onwards
* Keep the patches switching to the new platform plugin code in reserve to either switch for 5.3 if testing proves the plugin is stable enough, or more likely to use in 5.4 if not. I like this idea at least, because this enables the reviews to keep going and we can keep testing until we are certain it is all good. Takes the pressure off somewhat then. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Fastest Way to convert a QVideoFrame to an QImage?
Em qua 12 fev 2014, às 09:55:09, Jason H escreveu: Well Qt does NOT support grayscale. None of the QImage::Formats are gray. It's either mono, indexed color or color bits. Which is why I'm a but unsure of what is faster. I would assume setting a pixel on Indexed 8, would take a RGB or index and produce a color index lookup, even when the index is the lookup. qimage.h: #if 0 // reserved for future use Format_RGB15, Format_Grayscale16, Format_Grayscale8, Format_Grayscale4, Format_Grayscale4LSB, Format_Grayscale2, Format_Grayscale2LSB #endif You may want to contribute some of those formats :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] i.MX6 zero copy video playback
Hello, Great! On Wed, Feb 12, 2014 at 10:43 AM, Thomas Senyk thomas.se...@pelagicore.comwrote: Hi, I finally got around to polish and upstream zero copy video playback for the i.MX6. The change: https://codereview.qt-project.org/#change,76764 A video showcasing the functionality: http://www.youtube.com/watch?v=pmxsWGhrrBQ Greets Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
