On sábado, 26 de novembro de 2016 00:51:06 PST Samuel Gaist wrote:
> The library as it is currently could even be in its own repository however
> the goal in the long run is to replace the code used in QSystemTrayIcon by
> calls to this module which at this time duplicates the showMessage logic
> f
> On Nov 25, 2016, at 3:51 PM, Samuel Gaist wrote:
>
> Hi,
>
> As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d
> like to open a discussion about adding a new library in qtbase.
>
> Why this discussion ?
>
> Currently in work a pluggable notification system develop
Hi,
As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d
like to open a discussion about adding a new library in qtbase.
Why this discussion ?
Currently in work a pluggable notification system developed in its own library
in qtbase.
Why add a new library ?
Originally t
The merging has become a huge burden on more than one person. Distributing it
over every developer has a couple of positive side effects:
* The code bases have deviated quite a bit in certain areas (c++11 usage,
configuration system, removal of WinCE to name just some examples) to make
merges d
25.11.2016, 22:12, "Ernst Maurer" :
> hello
>
> just faced with a requirement to build qt/cmake based project from command
> line or another IDE, and could not. what is a qtcreator magic which helps to
> do this successfully?
>
> tried to build simplest sample project from actual documentation
Thiago Macieira wrote:
> What option are you choosing for the other packages that do use the
> libstdc++ API?
Rebuilding them all, and everything that does not work when building in
random (basically alphabetical, though the order is not guaranteed) order
(with the mass rebuild script) has to be
Ernst Maurer wrote:
> just faced with a requirement to build qt/cmake based project from command
> line or another IDE, and could not. what is a qtcreator magic which helps
> to do this successfully?
This is really a question for qt-interest (about developing WITH Qt), not
qt-devel (about developi
On Fri, Nov 25, 2016 at 09:11:13PM +0100, Oswald Buddenhagen wrote:
> On Fri, Nov 25, 2016 at 08:41:42PM +0100, André Pönitz wrote:
> > On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote:
> > > 1) The whole motivation for stop doing merges from 5.6 forward is the
> > > high number of
Also a +1 from me. Its simply the easiest and most hassle free way for
newcomers to start on Windows and it runs everywhere. In my opinion 32bit
should have been completely stopped 10 years ago, but sadly the reality is ugly.
Beste Grüße / Best regards,
Alexander Nassian
> Am 25.11.2016 um 19:2
On Fri, Nov 25, 2016 at 08:41:42PM +0100, André Pönitz wrote:
> On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote:
> > 1) The whole motivation for stop doing merges from 5.6 forward is the
> > high number of conflicts between the branches.
>
> That's not true, it's also about the t
On sexta-feira, 25 de novembro de 2016 10:51:06 PST Giuseppe D'Angelo wrote:
> Out of curiosity, why does a ABI break not incur in a soname change?
Because they technically did not break BC. Programs that were compiled and
linked against an older version will continue to run exactly as before.
T
On sexta-feira, 25 de novembro de 2016 01:37:32 PST Kevin Kofler wrote:
> libstdc++ now has a sub-ABI-version that was already bumped recently for
> better C++11 compliance. It can be bumped again, without even changing the
> soname, and all libraries using the std:: types in their APIs will have a
hello
just faced with a requirement to build qt/cmake based project from command
line or another IDE, and could not. what is a qtcreator magic which helps
to do this successfully?
tried to build simplest sample project from actual documentation here (
http://doc.qt.io/qt-5/cmake-manual.html) , th
On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote:
> Il 25/11/2016 13:40, Oswald Buddenhagen ha scritto:
> > - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to
> > merge tags)
> > - you may integrate only changes which have been already integrated into
> > a
Bo Thorsen wrote:
> The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is
> that a valid reason for MinGW? I would have thought that the guys using
> it pretty much have to compile everything themselves anyway.
C libraries are normally interoperable between VC and MinGW. Even C++
On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote:
> So, while on one hand this new branching scheme distributes the burden
> from the current merge masters onto the bigger community, in practice
> I'm very afraid (read: almost certain) that this will mean that very
> few people wil
Hi,
This nice thing about the MinGW package is, that you get Qt, Creator,
the compiler and the debugger in one package. I already recommended this
package to people that wanted to start Windows development and this
always worked fine.
So another +1 for MinGW 32bit build from my side.
Andre
Il 25/11/2016 13:40, Oswald Buddenhagen ha scritto:
> - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to
> merge tags)
> - you may integrate only changes which have been already integrated into
> a stable mainline
Sorry, but need to raise an objection against this strategy
hello,
as discussed at the QtCS and these lists, forward-merging from the LTS
branch 5.6 is becoming a significant burden.
therefore, 5.6 is switching to a cherry-pick based model:
- 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to
merge tags)
- you may integrate only change
On Freitag, 25. November 2016 10:51:06 CET Giuseppe D'Angelo wrote:
> On Fri, Nov 25, 2016 at 1:37 AM, Kevin Kofler
wrote:
> > libstdc++ now has a sub-ABI-version that was already bumped recently for
> > better C++11 compliance. It can be bumped again, without even changing the
> > soname, and al
Sean Harmer:
>>> what is the reason that when doing incremental builds with the 5.8
>>> branch that qmake gets run in each and every subdir please? It
>>> *really* slows down doing incremental builds. Is there any way to
>>> avoid this or can we go back to the 5.7 behaviour please?
I can confirm t
On Friday 25 November 2016 09:36:19 Mitch Curtis wrote:
> > -Original Message-
> > From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> > project.org] On Behalf Of Sean Harmer
> > Sent: Friday, 25 November 2016 10:16 AM
> > To: development@qt-project.org
> > Subject: [Deve
On Fri, Nov 25, 2016 at 1:37 AM, Kevin Kofler wrote:
> libstdc++ now has a sub-ABI-version that was already bumped recently for
> better C++11 compliance. It can be bumped again, without even changing the
> soname, and all libraries using the std:: types in their APIs will have a
> broken ABI.
Ou
> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Sean Harmer
> Sent: Friday, 25 November 2016 10:16 AM
> To: development@qt-project.org
> Subject: [Development] Very slow incremental builds with 5.8
>
> Hi all,
>
> wha
Hi all,
what is the reason that when doing incremental builds with the 5.8 branch that
qmake gets run in each and every subdir please? It *really* slows down doing
incremental builds. Is there any way to avoid this or can we go back to the
5.7 behaviour please?
Cheers,
Sean
--
Dr Sean Harmer
We have been using the MinGW binaries of Qt for years in production without
problems. Until now 64bit has not been required, so we only used 32bit
which is able to run on all windows platforms. A non-negligible part of
users are using 32bit windows (on tablets for example), so it does not seem
a ve
26 matches
Mail list logo
