> 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
>
> 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
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
>
> 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
>
> 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.
Pete
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
>
> 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
> KD
> 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:
> > > &g
> > 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.kda
> > 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 CMA
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
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
>
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 2
> 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
(
> > 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"
> 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
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, th
>
> 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
18 matches
Mail list logo
