Am 16.02.2016 um 08:29 schrieb Knoll Lars:
Hi everybody,
It would be great if those of you who haven’t done so yet fill in the 5.7 new
features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that
we can get a good overview over the bigger new features in 5.7.
In addition,
On 23.04.2015 14:30, René J.V. Bertin wrote:
> On Thursday April 23 2015 11:13:41 Peter Kuemmel wrote:
>> 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.
>
>
On 23.04.2015 20:31, René J.V. Bertin wrote:
> On Thursday April 23 2015 16:58:05 Peter Kuemmel wrote:
>
>> Because the gerrit code is Qt5 not Qt4.
>
> Doh ... I wondered about that and should have realised it was the case seeing
> the dialoghelper file on the list.
>
>> So it needs a complete rev
On 19.05.2014 10:57, Oswald Buddenhagen wrote:
> On Sun, May 18, 2014 at 05:29:56PM +0200, Adam Strzelecki wrote:
>> Hello,
>>
>> I wonder if there was any work done in regards of making Ninja Qmake
>> generator. From my experience Ninja vastly improves (re)build time.
>
>> I wonder if it would be
On 30.05.2014 23:59, Adam Strzelecki wrote:
> Moreover it takes more to build qt-creator with Qbs (20min) than Qmake+make
> (18min). Also it doesn't support precompiled headers, at least not for
> qt-creator, where Qmake+make+PCH goes down to 9min.
Strange, I thought qbs improves build times.
>
On 28.04.2014 18:01, Tony Van Eerd wrote:
>>
>> On 25.04.2014 12:18, Joerg Bornemann wrote:
>>>
>>> Yep, I hear people keep repeating the mantra "QML is declarative. It's
>>> just QML/JS that isn't."
>>
>> I think the "declarative-mantra" is a good idea, especially when used for
>> _specifying_ (no
On 28.04.2014 16:00, Roland Winklmeier wrote:
> 2014-04-27 13:31 GMT+02:00 Peter Kümmel <mailto:syntheti...@gmx.net>>:
>
> On 21.04.2014 13 :39, Roland Winklmeier wrote:
> > - Memory consumption: Even a mini example took about 70 MB of memory,
> > QtWi
On 28.04.2014 09:32, Gunnar Sletta wrote:
>> ATM the problem is to get started because I don't know much about the
>> current architecture of the graphic stack.
>
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-r
On 28.04.2014 09:26, Thiago Macieira wrote:
> Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu:
>>>> ATM the problem is to get started because I don't know much about the
>>>> current architecture of the graphic stack.
>>>> Any hints where to st
On 28.04.2014 08:10, Kurt Pattyn wrote:
>
>
>> On 28 Apr 2014, at 07:53, Peter Kümmel wrote:
>>
>>> On 27.04.2014 22:40, Thiago Macieira wrote:
>>>> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>>>>> On 26.04.2014 17:39, A
On 28.04.2014 00:55, André Pönitz wrote:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
>> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
>>> Having imperative code on the JS side is also the root of the rejection of
>>> QML for many C++ de
On 27.04.2014 22:41, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
>> Then adding 100MB just to run QML really hurts, and you start
>> looking for alternatives, like using only QWidgets with very
>> limited OpenGL support or not to use a
On 27.04.2014 22:40, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>> On 26.04.2014 17:39, André Pönitz wrote:
>>> You could have made the point "declarative structures are good for GUI
>>> description" for Qt Widget'
On 21.04.2014 13:39, Roland Winklmeier wrote:
> - Memory consumption: Even a mini example took about 70 MB of memory,
> QtWidgets need a lot less. This is not a complain, I know the JS runtime
> needs its initial memory. It was just one factor, because our
> application is running as an addon to Fl
On 26.04.2014 17:39, André Pönitz wrote:
>
> You could have made the point "declarative structures are good for GUI
> description" for Qt Widget's .ui files, after all, .ui files contents
> pretty much _is_ declaring layout nesting and property values.
Just an idea:
Declarative-only QML files coul
On 25.04.2014 12:18, Joerg Bornemann wrote:
>
> Yep, I hear people keep repeating the mantra "QML is declarative. It's
> just QML/JS that isn't."
I think the "declarative-mantra" is a good idea, especially when used for
_specifying_ (not programming) the GUI.
At Adobe they tried it with pure C++
On 24.04.2014 21:15, Attila Csipa wrote:
> solutions to cross platform mobile development :( After playing a bit
> with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
> quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing be
On 22.04.2014 07:17, Heikkinen Jani wrote:
> Hi all,
>
> We have new RC snapshot available in
> http://download.qt-project.org/snapshots/qt/5.3/5.3.0-RC/2014-04-21_65/
I tried to update my build scripts, but there are no source packages available.
Isn't a RC a simulation of the release?
Thanks,
http://qt-project.org/doc/qt-5/supported-platforms.html
"Embedded Linux (DirectFB, EGLFS, KMS, and Wayland)"
Am I right that this sentence is the complete documentation
for using Qt 5 on an embedded system?
Nothing about how to build, what's needed for QML,
what for QWidgets, how to replace qws,
On 19.10.2013 17:17, Hausmann Simon wrote:
> Looks good to me. (although I would prefer the more
> descriptive Qt msvc version macros)
>
> Can you submit this to gerrit stable branch and Cc me?
stable for qt4? I had already pushed 2 patches to 4.8.
>
> Simon
>
> *Fra: *Yuchen Deng
> *Sendt: *15:
On 10.09.2013 08:16, Knoll Lars wrote:
>
> Develop it in a playground project, show why it makes sense and once you have
> a stable API let's discuss into which module it should go.
An idea I already had when I saw the QUniquePoiner implementation:
Couldn't we add a new branch to dev/stable/rele
On 06.09.2013 19:52, David Faure wrote:
>
> connect(job, SIGNAL(result(QJob*)),
> this, SLOT(handleResult(QJob*)));
This looks so old-school like in times of futures and monads.
Couldn't such a class be part of the hopefully coming QtConcurrent replacement?
Peter
___
On 05.09.2013 12:10, Daniel Teske wrote:
> QScopedPointer has never been a scoped pointer. It has always had a .reset()
> method. That should never have been part of QScopedPointer.
I wonder if this would happen again with the current review process.
>
> daniel#
_
On 04.09.2013 17:54, Thiago Macieira wrote:
> On quarta-feira, 4 de setembro de 2013 10:20:39, Peter Kümmel wrote:
>>> What's that something else? Remember that QScopedPointer was created to
>>> simplify handling of exceptions (when we tried to care about exceptions).
On 04.09.2013 09:16, Thiago Macieira wrote:
> On quarta-feira, 4 de setembro de 2013 09:00:14, Peter Kümmel wrote:
>> But then you could use take() add wrap the pointer with something else,
>> only this way I would call "explicit".
>
> What's that something el
On 03.09.2013 22:12, Oswald Buddenhagen wrote:
> On Tue, Sep 03, 2013 at 09:20:20PM +0200, Peter Kümmel wrote:
>>>> Adding a move contructor to QScopedPointer makes no sense, because moving
>>>> means 'escaping the scope', which breaks the fundamental point o
On 03.09.2013 22:47, Thiago Macieira wrote:
> On terça-feira, 3 de setembro de 2013 22:12:58, Oswald Buddenhagen wrote:
>> "A non-null QScopedPointer deletes when it leaves the scope."
>>
>> which sounds quite reasonable to me.
>
> It still does that.
>
> Moving out of a QScopedPointer simply
On 04.09.2013 07:36, Olivier Goffart wrote:
> On Tuesday 03 September 2013 21:20:20 Peter Kümmel wrote:
>> It is of great benefit that you never had to think about if
>> QScopedPointer(5.1) will delete when leaving scope.
>
> That's not true.
>
> QScopedPointer&l
>> Adding a move contructor to QScopedPointer makes no sense, because moving
>> means 'escaping the scope', which breaks the fundamental point of
>> QScopedPointer. QScopedPointer is different to std::unique_ptr and should
>> remain so.
I have to agree with Steven. After allowing moving, the sema
On 10.03.2013 16:54, Sze Howe Koh wrote:
>
> Olivier started implementing this:
> https://codereview.qt-project.org/#change,49864
Last year I gave it also a try,
http://lists.qt-project.org/pipermail/development/2012-June/004580.html
http://lists.qt-project.org/pipermail/development/201
On 21.02.2013 14:00, Turunen Tuukka wrote:
>
> Unfortunately we do not have unlimited resources in the release team, so
> pointlessly redoing the packages is not something I want to do.
>
I would release the already packaged versions as they are as a
Digia-only release, and skip 4.8.5/4.7.6 in the
On 19.02.2013 20:29, Turunen Tuukka wrote:
>
> We have the packages ready and tested with minor
> fixes compared to RC1 (21st Dec). If we re-do these
> packages it is a significant effort with very limited benefits.
>
It seems to me this already happens before:
you first do the packaging and the
On 21.02.2013 06:04, Amogh Kudari wrote:
> Hi All,
>
> Any idea on how to proceed to remove this assertion mentioned below.
> Please provide any inputs/suggestions.
>
> Thanks and Regards,
> Amogh.
>
I've tested your program on Windows with msvc12 and wit the 4.8 branch.
It starts here w
>
> The problem with the original request to simply make all changes
> "abandoned" is that it will destroy the differentiation between
> "trash" and "not interested in atm".
Another problem is that some touches your changes you've invested
time and motivation and simply moves it into the trash can
On 01.02.2013 01:37, Alan Alpert wrote:
>
> That said, I'd prefer it for us to reach a consensus that the
> abandoned state should mean abandoned (adj 2 of
> http://en.wiktionary.org/wiki/abandoned) instead of destroyed (past
> participle of verb 1, http://en.wiktionary.org/wiki/destroy). Then
> ab
On 30.01.2013 19:23, Charley Bay wrote:
> I've implemented a C++ "adapter-layer" (mostly template-based) to expose
> C++ objects to QML.
>
> We are in the "early-stages" for its use, and (of course) the "final-API"
> will significantly impact how we expose our (domain-specific) C++ classes
> to QML
On 29.01.2013 13:12, Jason McDonald wrote:
> On Tue, Jan 29, 2013 at 10:00 PM, Sergio Ahumada
> wrote:
>> On 01/29/2013 12:57 PM, Jason McDonald wrote:
>>> I think there is a problem here. The announcement in the link seems
>>> to indicate that the intention was only to present non-approvers with
On 29.01.2013 13:05, Oswald Buddenhagen wrote:
> moin *,
>
> 5.0 is out and the 5.1 feature freeze isn't that far off any more.
> seems like the best time for some serious house cleaning.
> therefore i'd like to urge everyone to give their pending changes which
> haven't seen activity for a long ti
Seems currently everybody could merge to staging.
I as non-approver have a merge button in gerrit.
Or is this only a new feature to see if the
request passes all tests?
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-projec
On 26.01.2013 07:34, Laszlo Papp wrote:
>
> Good question; we discussed this issue before. This is unfortunately also a
> real problem for us to test the module with
> all the combinations for each factor. It requires (semi-)manual testing and
> hence a bit of effort. I see two ways to
> improve
Try without -no-iconv, the error is related to unicode stuff.
On 22.01.2013 08:50, Amogh Kudari wrote:
> Hi Thiago,
>
> Thanks for your quick response.
>
> Now I reconfigured without -qpa option but *still I am getting the same
> errors.*
>
> Now configuration looks something like this...
>
> =
On 18.01.2013 14:37, Motyka Rafal wrote:
> Hello,
>
> Qt 5.0.1 release testing has been started. We would like to kindly ask the Qt
> Community for help by testing the new
> packages.
>
> 1. Installer packages are available here:
> http://releases.qt-project.org/digia/5.0.1/backups/2013-01-18-41
On 10.01.2013 23:31, Sergio Ahumada wrote:
> On 01/10/2013 11:29 PM, Peter Kümmel wrote:
>> On 09.01.2013 17:11, Salovaara Akseli wrote:
>>> Hi,
>>>
>>> Qt 5.0.1 release branching is ongoing and there are already around 300
>>> commits available si
On 09.01.2013 17:11, Salovaara Akseli wrote:
> Hi,
>
> Qt 5.0.1 release branching is ongoing and there are already around 300
> commits available since Qt 5.0.0 release.
Ahm, what was the difference between release and a tag, and between release
and stable?
>
> There are also quite many bugs r
On 10.01.2013 19:56, Ruslan Nigmatullin wrote:
> Botan, as I see is C++ wrapper around OpenSSL itself.
Are you sure? It looks different on their site:
http://botan.randombit.net/index.html
> Qt already has OpenSSL dependency. What's are benefits of using it if Botan
> is just additional dependa
On 04.01.2013 12:27, Thiago Macieira wrote:
> On sexta-feira, 4 de janeiro de 2013 09.35.33, Peter Kümmel wrote:
>> Isn't on Windows only PATH used to figure out which Dll to load?
>
> Correct.
>
>> Then
>> qt.conf in the same dir as QtCore/qmake should b
On 02.01.2013 14:18, Thiago Macieira wrote:
> On quarta-feira, 2 de janeiro de 2013 14.01.02, Peter Kümmel wrote:
>> On 02.01.2013 13:50, Yves Bailly wrote:
>>> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>>>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves B
On 02.01.2013 14:33, Lincoln Ramsay wrote:
> On 2/01/13 11:01 PM, Peter Kümmel wrote:
>> On 02.01.2013 13:50, Yves Bailly wrote:
>>> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>>>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote:
>>>>
On 02.01.2013 13:50, Yves Bailly wrote:
> Le 02/01/2013 13:42, Thiago Macieira a écrit :
>> On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote:
>>> Does anyone knows where I could find the source code of the "official"
>>> installer, or at least some information about what it does? B
On 04.12.2012 12:28, Oswald Buddenhagen wrote:
> On Mon, Dec 03, 2012 at 04:29:24PM +, Knoll Lars wrote:
>> Dev is the branch where you can land anything that's supposed to go into
>> 5.1. The following policies apply:
>>
>> Stable:
>>
>> This branch will be the basis for Qt 5.0 and subsequent
On 08.10.2012 18:07, Thiago Macieira wrote:
> On segunda-feira, 8 de outubro de 2012 16.37.46, Peter Kümmel wrote:
>> Currently on Windows private headers are needed when
>> #include is used.
>>
>> \include\QtGui\QtGui
>> \include\QtGui\QPlatformNativeInte
Currently on Windows private headers are needed when
#include is used.
\include\QtGui\QtGui
\include\QtGui\QPlatformNativeInterface
which needs 5.0.0\qpa\qplatformnativeinterface.h
Is this by design?
Peter
___
Development mailing list
Development@
This discussion shows another problem.
ATM it is not possible to release a Qt4 version
(has Qt5 the same problem?) with a proper version
number based on an already released version and
containing only some patches.
This is not only a scenario when the Qt copyright
changes. It could happen all the
"The ABI incompatibilities have been fixed for GCC version 4.7.2
but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may
be incompatible with C++11 code compiled with different GCC
versions and with C++98/C++03 code compiled with any version."
Did they know what they were doing with 4.7.0/
On 11.09.2012 16:55, kai.koe...@nokia.com wrote:
>
> There's nothing wrong with cross-compilation. But what we need first and
> foremost is a reliable, native MinGW environment for developing Qt
> applications, since the vast majority of Qt developers that develop for
> Windows also develop _on_
On 03.09.2012 16:10, kai.koe...@nokia.com wrote:
>>
>> My suggestion on how to proceed is to choose one that offers the following or
>> most of the following:
>>
>> - most recent GCC (4.7 preferably, 4.6 if not)
>
> Latest mingw-builds and latest rubenv packages both provide 4.7.1
>
>> - *worki
On 30.08.2012 18:16, Thiago Macieira wrote:
> On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
>> There are more differences than that. There are differences in
>> features, such as threading support, large-file support, etc.
>> Mingw-w64 is usually ahead of any other in t
On 31.08.2012 09:02, Pau Garcia i Quiles wrote:
>
>> All those MinGW and forks contain mingw32-make.exe util which does have -j
>> option, but in fact this option doesn't make the real parallel build. Maybe
>> sh.exe is needed, but this shell util will pass the incompatible path string
>> so that t
On 01.09.2012 12:52, Thiago Macieira wrote:
> On sábado, 1 de setembro de 2012 12.47.15, Peter Kümmel wrote:
>> So you think it is possible to use DW2 for 32 bit binaries?
>
> Yes.
>
>> What happens if a binary compiled with GCC/DW2 calls a
>> C++ function in a D
On 01.09.2012 12:47, Peter Kümmel wrote:
> On 01.09.2012 12:39, Thiago Macieira wrote:
>> On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote:
>>>"As a general rule, you should choose the default SJLJ packages,
>>> unless you know you ne
On 01.09.2012 12:39, Thiago Macieira wrote:
> On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote:
>> "As a general rule, you should choose the default SJLJ packages,
>>unless you know you need faster exception handling and can guarantee
>>
On 30.08.2012 18:16, Thiago Macieira wrote:
> On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
>> There are more differences than that. There are differences in
>> features, such as threading support, large-file support, etc.
>> Mingw-w64 is usually ahead of any other in t
On 30.08.2012 18:16, Thiago Macieira wrote:
>
> My suggestion on how to proceed is to choose one that offers the following or
> most of the following:
>
> - most recent GCC (4.7 preferably, 4.6 if not)
> - *working* GDB and tested with Creator, with Python support
> - large file support, thre
On 30.08.2012 13:23, lars.kn...@nokia.com wrote:
> Hi everybody,
>
> the Qt 5 beta has now been released. Please find all the details at
>
> http://www.qt-project.org/wiki/Qt-5-Beta
>
> and my blog post at
>
> http://labs.qt.nokia.com/2012/08/30/qt-5-beta-is-here/
>
> Enjoy!
>
> Lars
>
Where shoul
On 31.08.2012 13:54, Thiago Macieira wrote:
> On sexta-feira, 31 de agosto de 2012 13.40.38, Peter Kümmel wrote:
>>> On the #qt-release channel, then reviewed through Gerrit.
>>> https://codereview.qt-project.org/33837
>>
>> This is a little bit "behind clo
On 31.08.2012 13:31, Thiago Macieira wrote:
> On sexta-feira, 31 de agosto de 2012 12.05.00, Laszlo Papp wrote:
>>> On my suggestion, we dropped .tar.bz2. We're keeping .tar.gz to ensure
>>> maximum
>>> compatibility and .tar.xz because it's the smaller of the three.
>>
>> Was this decision publicl
On 31.08.2012 09:00, Yves Bailly wrote:
> Hello all,
>
> Le 30/08/2012 14:33, Yves Bailly a écrit :
>> Le 30/08/2012 13:23, lars.kn...@nokia.com a écrit :
>>> the Qt 5 beta has now been released. Please find all the details at
>>> http://www.qt-project.org/wiki/Qt-5-Beta
>>>
>>
>> Trying to compile
On 29.08.2012 02:02, Rohan McGovern wrote:
>>
>> Is there a list which configurations are checked by the CI?
>>
>
> Yes, you can check the list from testresults.qt-project.org, e.g.
> http://testresults.qt-project.org/ci/QtBase_master_Integration/latest-success/
For the quality gate checks such a
On 28.08.2012 21:14, Peter Kümmel wrote:
> On 28.08.2012 20:46, Peter Kümmel wrote:
>>>>
>>>> But also jom fails, I thought jom could also handle mingw makefiles?
>>>
>>> No, Jom only handles NMake makefiles, afaik.
>>>
>>
>> Che
On 28.08.2012 21:12, marius.storm-ol...@nokia.com wrote:
> On 28/08/2012 13:46, ext Peter Kümmel wrote:
>> On 28.08.2012 19:59, marius.storm-ol...@nokia.com wrote:
>>> On 28/08/2012 12:48, ext Peter Kümmel wrote:
>>>> But also jom fails, I thought jom could al
On 28.08.2012 20:46, Peter Kümmel wrote:
>>>
>>> But also jom fails, I thought jom could also handle mingw makefiles?
>>
>> No, Jom only handles NMake makefiles, afaik.
>>
>
> Checked it again: I could build qt/4.8 with jom.
>
> So I would s
On 28.08.2012 19:59, marius.storm-ol...@nokia.com wrote:
> On 28/08/2012 12:48, ext Peter Kümmel wrote:
>> On 28.08.2012 19:27, marius.storm-ol...@nokia.com wrote:
>>> On 28/08/2012 12:16, ext Peter Kümmel wrote:
>>>> Have I missed something or is building with
On 28.08.2012 19:27, marius.storm-ol...@nokia.com wrote:
> On 28/08/2012 12:16, ext Peter Kümmel wrote:
>> I've tried to build qtbase
>> 1. on Windows 7
>> 2. rubenvb's mingw-w64:
>> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Wi
I've tried to build qtbase
1. on Windows 7
2. rubenvb's mingw-w64:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/
3. in Windows shell cmd.exe
4. as shadow build with ..\qtbase\configure.bat -fast -nomake demos -nomake
exa
to be copied to
> win32-mainwindow/platforms. I cannot imagine that the msvc runtime is
> missing, because you are using the mingw compiler and the compiler does
> not use the msvc runtine...
>
> Am 28.08.2012 13:37, schrieb Peter Kümmel:
>> On 28.08.2012 12:18, Peter Kümmel wro
On 28.08.2012 12:18, Peter Kümmel wrote:
> On 28.08.2012 12:04, Stephen Kelly wrote:
>> On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:
>>> I tried it again from scratch, and I was wrong, it also doesn't work
>>> on 12.04, only one file is copied: lib/cm
On 28.08.2012 12:04, Stephen Kelly wrote:
On Tuesday, August 28, 2012 11:49:28 Peter Kümmel wrote:
I tried it again from scratch, and I was wrong, it also doesn't work
on 12.04, only one file is copied: lib/cmake/Qt5Core/Qt5CTestMacros.cmake
Ok. Please tell me how to try it out.
On 28.08.2012 11:03, Stephen Kelly wrote:
> On Tuesday, August 28, 2012 10:44:58 Peter Kümmel wrote:
>>>> In the build dir the files are in lib/cmake, but
>>>> they are not copied to the install dir.
>>>
>>> Does the install step complete without war
On 28.08.2012 10:34, Stephen Kelly wrote:
> On Monday, August 27, 2012 19:23:19 Peter Kümmel wrote:
>> On 27.08.2012 19:14, Peter Kümmel wrote:
>>> Cross-compiling with mkspec/win win32-g++ doesn't
>
> This doesn't mean anything to me. What is the host and what i
On 27.08.2012 19:14, Peter Kümmel wrote:
> Cross-compiling with mkspec/win win32-g++ doesn't
> install the cmake files into lib/cmake.
>
> The line in mkspecs/features/create_cmake.prf
>
> INSTALLS += cmake_qt5_module_files
>
> is called but ignored, there
Cross-compiling with mkspec/win win32-g++ doesn't
install the cmake files into lib/cmake.
The line in mkspecs/features/create_cmake.prf
INSTALLS += cmake_qt5_module_files
is called but ignored, there are no install rules
in the Makefiles for cmake files.
Any ideas how to fix this?
Peter
_
On 27.08.2012 13:30, Thiago Macieira wrote:
> On segunda-feira, 27 de agosto de 2012 13.23.47, Peter Kümmel wrote:
>> On 27.08.2012 13:12, Peter Kümmel wrote:
>>> qtbase/examples/widgets/mainwindows/mainwindow
>>> crashes here immediately on startup. Attached the back
On 27.08.2012 13:12, Peter Kümmel wrote:
qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.
It's a fresh Qt5 build on a virtual machine.
Ubuntu 12.04 based distro
gcc 4.6.3
All is fine with Qt4.
I have a debug setup here so I
qtbase/examples/widgets/mainwindows/mainwindow
crashes here immediately on startup. Attached the backtrace.
It's a fresh Qt5 build on a virtual machine.
Ubuntu 12.04 based distro
gcc 4.6.3
All is fine with Qt4.
I have a debug setup here so I could provide more information.
Peter
(gdb) bt
#0
On 26.08.2012 20:14, Peter Kümmel wrote:
> http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
>
> When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
> exist, moc throws an error, but when FILE isn't present at all
> moc silently doesn'
http://doc-snapshot.qt-project.org/5.0/qtplugin.html#Q_PLUGIN_METADATA
When Q_PLUGIN_METADATA() is used with a FILE name which doesn't
exist, moc throws an error, but when FILE isn't present at all
moc silently doesn't generate the pluginMetaData[]s.
Isn't this a bug?
Peter
__
On 26.08.2012 18:16, Thiago Macieira wrote:
> On domingo, 26 de agosto de 2012 17.31.07, Peter Kümmel wrote:
>> When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
>> but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
>> A bug
When building plugins, moc generates files with '#ifdef QT_NO_DEBUG'
but the lib/cmake modules doesn't add QT_NO_DEBUG for release builds.
A bug?
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinf
On Sun, 19 Aug 2012 12:00:25 +0200
Thiago Macieira wrote:
>
> I'd actually prefer that you clean this up *after* we switch buildsystems,
Ahhh! :)
> whenever that happens. Cleaning up configure is an unnecessary task if we're
> going to throw it away soon after.
>
> Please keep changes to the
Qt could be compiled native or cross for a system
different to the system on which Qt is build.
But this is not how mkspecs/ is organized:
linux-*native
win32-*native
wince* cross
unsupported/* cross and native
device/* cross
also configure supports different opti
sorry, wrong list.
On 10.07.2012 11:21, Peter Kümmel wrote:
> On 09.07.2012 17:35, David Cole wrote:
>> Not sure what your main goal was for that test, but a similar test already
>> exists to ensure proper definition of
>
> http://www.cmake.org/Bug/view.php?id=13069
>
On 09.07.2012 17:35, David Cole wrote:
> Not sure what your main goal was for that test, but a similar test already
> exists to ensure proper definition of
http://www.cmake.org/Bug/view.php?id=13069
Seems there is no test which checks if -DCMAKE_BUILD_TYPE=XXX triggers the
selection of the matc
On 26.06.2012 23:17, Olivier Goffart wrote:
>
> I'm not sure the class name is that important.
> I mean, if Foo().metaObject()->className() is just "Foo" it is still ok.
> Because it is hard to support, and hardly usefull.
OK, I thought className() is used by qobject_cast, but it isn't,
so it's m
On 22.06.2012 09:26, Olivier Goffart wrote:
>
> Nice stuff. Now you just need to make it for Qt5, and handle all the special
> cases :-)
>
> There is a room for tests in tets/auto/tools/moc (I'm saying that because you
> made your test somewhere else)
>
OK, ported to Qt5 now:
https://qt.gitorious.
On 26.06.2012 12:28, Oswald Buddenhagen wrote:
> On Mon, Jun 25, 2012 at 12:56:15PM +0200, ext Peter Kümmel wrote:
>> Shadow builds [...] are broken:
>>
> fix integrated
Yes it works now. Thanks!
Wouldn't this be a test case for t
On 25.06.2012 16:03, Иван Комиссаров wrote:
> Same for OpenSuse
>
And Ubuntu:
features/qt_module_config.prf:87: ERROR creating directory /mkspecs/modules-inst
Also here the the outdir path is lost.
Peter
___
Development mailing list
Development@qt-proj
On 19.06.2012 14:31, Oswald Buddenhagen wrote:
> moin,
>
> the buildsystem branch of qtbase is currently being integrated. this is
> ~120 commits worth of qmake& project file fixes and cleanups. there are
> some changes to how modularization (in particular configure tests) is
> handled, and cross-
After the "noise" here "real" code:
https://qt.gitorious.org/~syntheticpp/qt/qt4/commit/c1b839494d90e8c1a93b0dd2e08a2a365095d89f
Based on Qt 4.8.2.
moc creates a header when it finds a template, if not then nothing changes.
(It builds Qt with the patch, but it's a hack in the parser)
In summary
On 20.06.2012 13:38, Thiago Macieira wrote:
> On quarta-feira, 20 de junho de 2012 13.09.40, Peter Kümmel wrote:
>> On 20.06.2012 12:31, Thiago Macieira wrote:
>>> On quarta-feira, 20 de junho de 2012 10.47.01, Peter Kümmel wrote:
>>>> When Foo is used, we would
On 20.06.2012 13:44, Giuseppe D'Angelo wrote:
> Is it me or this thread was badly derailed?
>
> Cheers,
Don't worry I will be bashed down soon.
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/de
1 - 100 of 121 matches
Mail list logo
