Re: [Development] Binary incompatible Qt 5 version
> Von: "Thiago Macieira" > > > Mixing different Qt versions in the same process is not supported. I must > point > out that none of the backtraces in either link show this. You can't use plugins compiled with an older Qt version. https://bugs.kde.org/show_bug.cgi?id=349371 I assume there are some toxic compiler flags which where maybe used by the system Qt build. > > >From what I can tell quickly examining both links, the root cause is not yet > determined. At least this way: no crashes when old plugins are disabled. > > -- > 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribute to the Qt
> > Or do you want to help improve the C++11 support in Qt? Is there a TODO list about possible improvements? And what's the policy about C++14? Isn't C++14 mostly a patch/cleanup of C++11? > > Or... > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > ___ > 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] Binary incompatible Qt 5 version
Is it obvious that the Qt 5.4.1 version installed by the system on a KDE machine is binary incompatible to a locally compiled Qt 5.5.0? That they are binary incompatible is shown by sporadic QtCreator crashes: https://bugs.kde.org/show_bug.cgi?id=347524 https://bugreports.qt.io/browse/QTCREATORBUG-14745 The crash happens when QBrush objects are passed around by KDE's style plugin breeze.so. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
> > QAbstactSocket is listed in the Wiki as a design mistake. > > Don't repeat it, please. Also using Qt's event system for such low-level byte swinging is a bad choice: https://codereview.qt-project.org/#/c/75708/ Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS-UP: Qt 5.4.2 release coming
> > Hi Peter, > > Thanks! > > Why an incomplete copy/paste? I see it's missing the changes to > tools/qtconfig/mainwindow.cpp, did you omit other changes as well? Because the gerrit code is Qt5 not Qt4. So it needs a complete review and test by you if it works on Mac, I don't have a Mac. Peter > > R. > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS-UP: Qt 5.4.2 release coming
René, maybe this helps you a bit: https://codereview.qt-project.org/#/c/111056/ It's only a incomplete copy and paste of your Qt 4 patch, but it could show you the direction. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GL headers in Qt5GuiConfigExtras.cmake
> > 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? I've uploaded a patch for further discussion: https://codereview.qt-project.org/#change,78038 > > Thanks, > > -- > Stephen Kelly | 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
> Gesendet: Mittwoch, 12. Februar 2014 um 14:14 Uhr
> Von: "Stephen Kelly"
> 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 | 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
> > 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 | 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
> > 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
[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
Re: [Development] Qt 5.2.1 Release Candidate available
Which changes will be part of 5.2.1? Only blockers or also some bug fixes currently in stable? > Gesendet: Freitag, 31. Januar 2014 um 09:20 Uhr > Von: "Heikkinen Jani" > An: "Thiago Macieira" , > "development@qt-project.org" > Betreff: Re: [Development] Qt 5.2.1 Release Candidate available > > And packages are now here: > http://download.qt-project.org/community_releases/additional_qt_src_pkgs/ > > Br, > Jani > > > -Original Message- > > From: development-bounces+jani.heikkinen=digia@qt-project.org > > [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] > > On Behalf Of Heikkinen Jani > > Sent: 31. tammikuuta 2014 7:58 > > To: Thiago Macieira; development@qt-project.org > > Subject: Re: [Development] Qt 5.2.1 Release Candidate available > > > > OK, I'll copy these somewhere later today > > > > Br, > > Jani > > > > > -Original Message- > > > From: development-bounces+jani.heikkinen=digia@qt-project.org > > > [mailto:development-bounces+jani.heikkinen=digia@qt-project.org] > > > On Behalf Of Thiago Macieira > > > Sent: 31. tammikuuta 2014 2:59 > > > To: development@qt-project.org > > > Subject: Re: [Development] Qt 5.2.1 Release Candidate available > > > > > > On quarta-feira, 29 de janeiro de 2014 12:30:10, Thiago Macieira wrote: > > > > On quarta-feira, 29 de janeiro de 2014 18:55:53, Sergio Ahumada wrote: > > > > > I fail to see how is this related to Qt 5.2.1 > > > > > > > > > > Are you sure a git build doesn't work? Even if it doesn't, that would > > > > > need > > > > > to be fixed in qtftp/qthttp > > > > > > > > That's the nature of the bug report: an extracted .tar.gz from > > gitorious.org > > > > does not build. If you use git clone, it does. > > > > > > > > All this takes is that someone create the correct .tar.gz and .zip. I've > > > > already volunteered to do it if someone can give me the instructions on > > > how > > > > to build source packages. > > > > > > > > I'm calling it a showstopper for Qt because it used to work with 5.0. > > > > It's > > a > > > > Qt 5.1 regression that has gone unfixed. > > > > > > Release files ready: > > > http://macieira.org/~thiago/tmp/ > > > > > > Someone with the appropriate rights, please download them from there > > > and place > > > somewhere in qt-project.org mirrors. > > > > > > I've also pushed v5.0.0 tags to the respective repositories. > > > -- > > > 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 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] Visual C++ 2013 binaries
MSVC 2013 now supports ISO C11 language features (also breaks Qt4 ATM). Gesendet: Samstag, 19. Oktober 2013 um 14:54 Uhr Von: "Nagy-Egri Máté Ferenc" An: "development@qt-project.org" Betreff: Re: [Development] Visual C++ 2013 binaries I have tried to build Qt 5.0 alpha with Visual Studio 2013 RTM and I got the following errors: c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58) : error C2883: 'std::signbit' : function declaration conflicts with 'signbit' introduced by using-declaration (util\qqmladaptormodel.cpp) C:\Kellekek\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(324) : see declaration of 'signbit' c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58) : error C2084: function 'bool signbit(double)' already has a body (util\qqmladaptormodel.cpp) C:\Kellekek\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(324) : see previous definition of 'signbit' c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58) : error C2883: 'std::signbit' : function declaration conflicts with 'signbit' introduced by using-declaration (util\qqmllistaccessor.cpp) C:\Kellekek\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(324) : see declaration of 'signbit' c:\qt-src\qtdeclarative\src\qml\jsruntime\qv4global_p.h(58) : error C2084: function 'bool signbit(double)' already has a body (util\qqmllistaccessor.cpp) C:\Kellekek\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(324) : see previous definition of 'signbit' qqmlpropertymap.cpp NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft Visual Studio 12.0\VC\BIN\amd64\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft Visual Studio 12.0\VC\BIN\amd64\nmake.exe"' : return code '0x2' Seems as if some declarations made to compensate for lack of STL conformance on VS2012 are no longer needed. I have encountered trivial functions missing from VS2012 STL as well. Some of these whould be revisited. Configuration is: configure.bat -platform win32-msvc2013 -opensource -debug-and-release -c++11 -mp -opengl desktop -nomake examples -prefix C:\Kellekek\Qt\5.2-alpha -bindir C:\Kellekek\Qt\5.2-alpha\bin\x64 -libdir C:\Kellekek\Qt\5.2-alpha\lib\x64 Regards, Máté Feladó: Yves Bailly Elküldve: péntek, 2013. október 18. 20:50 Címzett: development@qt-project.org On 18/10/2013 17:23, Thiago Macieira wrote: > On sexta-feira, 18 de outubro de 2013 08:23:35, Yves Bailly wrote: >> Greetings all, >> >> As most already probably know, Visual C++ 2013 is out. >> >> While it's most probably too late for the upcoming Qt 5.2, are there >> any plan to provided binaries from Visual 2013 in the future? For >> Qt 5.2.1, 5.2.2... or later? >> >> This information can have a significant impact on our planning here. > > Please note that before we produce binaries, we need to make sure Qt compiles > with that compiler. There will be no official binaries or official support until > this commit goes through: > > https://codereview.qt-project.org/65262 Of course, that's obvious :-) > Which means we need at least one person to apply and confirm Qt still builds. > > I tried installing VS2013 yesterday and it locked up my Windows 8. Three times > in a row. Seems a good first release... *sigh* I'll do my best to take the time to try it on monday. Regards, -- (o< | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ 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] Fwd: [graphics] SG13 Chicago Meeting Minutes
> Von: "Thiago Macieira" > Betreff: [Development] Fwd: [graphics] SG13 Chicago Meeting Minutes If someone is more interested in Herb Sutter's vision of C++, its standardization, and what SG13 is, see his talk here: http://channel9.msdn.com/Events/GoingNative/2013/Keynote-Herb-Sutter-One-Cpp (more concrete about graphics from 1:17:50) Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The place of QML
> > Now we suddenly have an easy to use, yet compulsory, Turing complete > > language with essentially no support from off-the-shelf tools. > > It's this "compulsory" part that I don't understand. > The current situation is that if you don't want to use > QML you don't use it. Does "don't use it" mean I should use QWidgets? But who wants to base a new project on a system which is officially called something that sounds like "obsolete" and "dead (no new features)"; I know the marketing calls this only "done". And AFAIK QML can't be used like .ui files for complete feature rich desktop applications, or I'm wrong? There is no smooth migration path for old-school Qt/C++ developers. Peter -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCreator C++ code parser and clang integration status
> Hello. > > When I tried to use QtCreator in my current development projects based > on C++11 features I was faced with some issues in qtc internal C++ > parser. One of such issues (code completion support for auto > variables) I recently fixed and pushed into master qtc branch. I could > try to fix others, but I think what it will be waste of time if clang > frontend will be integrated into qtc in the near future. May be my > help in this integration could be more useful. So, my question is: > which help is needed? Should I try to fix current version of C++ > parser or it will better if I focus on clang wrapper? ATM they don't know which route they will go. Maybe they will drop clang because it is much slower then the old parser, maybe they switch to clang. In any case, your risk to waste your time. I personally prefer clang (maybe only optionally), but I stopped testing it because of the 'maybe'. Peter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
Off topic: > > There would still be silent errors for people who have reimplemented > the createRequest method (it's virtual). > Technically interesting here is the question how such a situation cloud be managed? Using C++11 'final' would prevent the reimplementation. But using pre C++11, the only idea I have is to define a dummy function with a different return value, only this why the compiler would complain. Peter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
> > Well, having method createX which creates Y doesn't sound good to me > either. > Yes, this is worse than a binary-only bug. I don't know the policy for API changes for Qt 5.0, but when such a thing couldn't be fixed, nothing else is worth braking source code compatibility. I would fix it because it is super simple to create a script which simply replaces all the relevant strings in the source files. Peter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
