On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote:
> > > * C++11 Standard Library compatibility list
> > >
> > >
> > > * no volunteers yet
> >
> >
> >
> > Is this a matter of converting this documented into qdoc?
> >
> >
> >
> > https://codereview.qt-project.org/#/c/142782/
>
> We
On 09/06/16 03:08, Thiago Macieira wrote:
Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight
escreveu:
** General sentiment:
- As long as Qbs looks like a part of Qt, it is perceived as a Qt
product, and is less attractive to external users.
- Yet, there remains a conflict:
On 6 September 2016 at 16:20, Thiago Macieira wrote:
> Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu:
>> On 6 September 2016 at 01:52, Konstantin Tokarev wrote:
>> > 05.09.2016, 16:38, "Kevin Kofler" :
>> >> Andrew Knight wrote:
>> >>> * Quick survey: which build syste
Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu:
> On 6 September 2016 at 01:52, Konstantin Tokarev wrote:
> > 05.09.2016, 16:38, "Kevin Kofler" :
> >> Andrew Knight wrote:
> >>> * Quick survey: which build system do you use (raise of hands by ~40
> >>> people)
> >>> -
On 6 September 2016 at 01:52, Konstantin Tokarev wrote:
> 05.09.2016, 16:38, "Kevin Kofler" :
>> Andrew Knight wrote:
>>> * Quick survey: which build system do you use (raise of hands by ~40
>>> people)
>>> - CMake ~70%
>>> - qmake ~20%
>>> - Qbs ~10%
>>
>> That basically says it all. :-)
Ye
On 5 September 2016 at 23:08, NIkolai Marchenko wrote:
> Been using QBS for the last 6 months, transformed all projects to it(from
> qmake). Never looked back.
> It just clicks for me. Most everything seems logical (if poorly explained)
> when you understand how to do it.
I have switched quite a
Em segunda-feira, 5 de setembro de 2016, às 14:12:23 PDT, Jake Petroules
escreveu:
> Many of you seem to not understand how complex build tools can get and just
> how simple Qbs can make problems that are incredibly challenging in other
> systems. Perhaps you should actually try Qbs before complai
Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via
Development escreveu:
> I think something was lost in transit on this point. I don’t think it would
> be a PITA to write a CMake buildsystem for Qt. I recall the above point was
> in reference to ‘compiling host tools and
Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight
escreveu:
> ** General sentiment:
> - As long as Qbs looks like a part of Qt, it is perceived as a Qt
> product, and is less attractive to external users.
> - Yet, there remains a conflict: "if Qt doesn't use it, I don't want
Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo
escreveu:
> Random comments:
>
> Il 02/09/2016 17:01, Thiago Macieira ha scritto:
> > https://wiki.qt.io/QtCS2016_QtCore
> >
> > * Deprecation of APIs
> >
> > * qrand/qsrand -> replacement is Standard Library or you
Em segunda-feira, 5 de setembro de 2016, às 18:46:04 PDT, Alexander Nassian
escreveu:
> Please don’t get me wrong, but that would imply that if enough people (for
> whatever reason) expect eg. QSettings to be compatible with WinAPI calls
> that should be changed. If I’m not wrong QThread doesn’t e
Em segunda-feira, 5 de setembro de 2016, às 18:46:41 PDT, Giuseppe D'Angelo
escreveu:
> Il 05/09/2016 17:04, Alexander Nassian ha scritto:
> > Is, or should, that even be supported? I’m just wondering because when
> > I’m using Qt to create a thread, I also use Qt to quit it. Why should
> > anybod
Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor Engelmann
escreveu:
> So what if the user adds an asm statement that changes a register and
> doesn't declare that register to be changed? That would also cause his
> "Qt" application to misbehave... or what if he links the object fi
On 2016-09-05, Giuseppe D'Angelo wrote:
>> * C++ ABI
>> * libstdc++ still breaking compatibility in std::function
>> * not now, revisit in a year or two
>
> There hasn't been time to discuss this at QtCon, but I'd say we should
> not spend another year before revisiting this at the next Qt
> On 05 Sep 2016, at 19:27, Marc Mutz wrote:
>
> On Monday 05 September 2016 19:20:29 J-P Nurmi wrote:
On 05 Sep 2016, at 18:53, Marc Mutz wrote:
On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote:
with the upcoming qtcon and my subsequent vacation, my availability will
On Monday 05 September 2016 09:47:45 Jani Heikkinen wrote:
Hi Jani,
> We have released Qt 5.8.0 Alpha, see
> http://blog.qt.io/blog/2016/09/05/qt-5-8-alpha-released/
>
> At this time we managed to release it almost as planned, big thanks everyone
> involved!
It would be great if alpha/beta r
Hey Thiago, others.
I plan to work on adding static trace points to Qt in the next months, i.e.
find an abstraction that works with DTrace/SystemTap UDST/xperf as well as
custom trace point APIs that are sometimes used in the automotive sector e.g.
One thing that I noticed already is that often
On Montag, 5. September 2016 14:12:23 CEST Jake Petroules wrote:
> On Sep 5, 2016, at 3:38 PM, Kevin Kofler
> mailto:kevin.kof...@chello.at>> wrote:
> - (Milian) CMakeis used by e.g. clang and it works for them
>
> … and the whole stack of software from the KDE project, and other large
> project
On Monday 05 September 2016 19:00:40 Giuseppe D'Angelo wrote:
> > * QStringView & QByteArrayView
> >
> > * Deprecate QStringRef
> > * Not QArrayView: discuss later
>
> IOW: the views will have the full blown QByteArray/QString API on them?
The const subset, yes, minus deprecated API, if a
On 05.09.2016 19:29, Marc Mutz wrote:
On Monday 05 September 2016 19:20:29 J-P Nurmi wrote:
On 05 Sep 2016, at 18:53, Marc Mutz wrote:
On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote:
with the upcoming qtcon and my subsequent vacation, my availability will
be rather sporadic, so
On Saturday 03 September 2016 09:03:21 Thiago Macieira wrote:
> > Can't swallow doesn't mean can't catch. You can catch it, but you can't
> > not rethrow. But if you call std::terminate(), the rethrow will never be
> > reached.
>
> But that doesn't do what we want. We want to rethrow the __forced_
On Monday 05 September 2016 19:20:29 J-P Nurmi wrote:
> > On 05 Sep 2016, at 18:53, Marc Mutz wrote:
> >> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote:
> >> with the upcoming qtcon and my subsequent vacation, my availability will
> >> be rather sporadic, so consider this:
> >> - i
> On 05 Sep 2016, at 18:53, Marc Mutz wrote:
>
>> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote:
>> with the upcoming qtcon and my subsequent vacation, my availability will
>> be rather sporadic, so consider this:
>> - i'm not going to do reviews on a regular basis, so it's unwise
Random comments:
Il 02/09/2016 17:01, Thiago Macieira ha scritto:
> https://wiki.qt.io/QtCS2016_QtCore
>
> * Deprecation of APIs
> * qrand/qsrand -> replacement is Standard Library or your own
Unfortunately there's no replacement for a thread safe, easy to use,
deterministic, low quality ran
On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote:
> with the upcoming qtcon and my subsequent vacation, my availability will
> be rather sporadic, so consider this:
> - i'm not going to do reviews on a regular basis, so it's unwise to just
> add me to them and expect a reaction. send
> Am 05.09.2016 um 18:38 schrieb Giuseppe D'Angelo :
>
> Il 05/09/2016 16:08, Viktor Engelmann ha scritto:
>> We can lock away OUR guns so the user can't shoot himself in the foot
>> with them, but if he goes out and buys his own gun, there is nothing we
>> can (or should) do about it.
>
> That's
Il 05/09/2016 17:04, Alexander Nassian ha scritto:
> Is, or should, that even be supported? I’m just wondering because when
> I’m using Qt to create a thread, I also use Qt to quit it. Why should
> anybody use a „foreign“ API?
Maybe one is just using a 3rd party library that assumes pthreads, not
Il 05/09/2016 16:08, Viktor Engelmann ha scritto:
> We can lock away OUR guns so the user can't shoot himself in the foot
> with them, but if he goes out and buys his own gun, there is nothing we
> can (or should) do about it.
That's not the point. The point is that every time we do an apparently
Hi,
Is, or should, that even be supported? I’m just wondering because when I’m
using Qt to create a thread, I also use Qt to quit it. Why should anybody use a
„foreign“ API?
Beste Grüße / Best regards,
Alexander Nassian
> Am 02.09.2016 um 12:32 schrieb Giuseppe D'Angelo :
>
> Howdy,
>
> I'm
On Sep 5, 2016, at 4:12 PM, Jake Petroules
mailto:jake.petrou...@qt.io>> wrote:
On Sep 5, 2016, at 3:38 PM, Kevin Kofler
mailto:kevin.kof...@chello.at>> wrote:
- (Milian) CMakeis used by e.g. clang and it works for them
… and the whole stack of software from the KDE project, and other large
On Sep 5, 2016, at 3:38 PM, Kevin Kofler
mailto:kevin.kof...@chello.at>> wrote:
- (Milian) CMakeis used by e.g. clang and it works for them
… and the whole stack of software from the KDE project, and other large
projects.
Keep in mind that "large projects use X, therefore X is great" is a poor
So what if the user adds an asm statement that changes a register and
doesn't declare that register to be changed? That would also cause his
"Qt" application to misbehave... or what if he links the object files to
a custom loader that doesn't call the constructors for global objects?
We can lock a
05.09.2016, 16:38, "Kevin Kofler" :
> Andrew Knight wrote:
>> - (Tobias) Cmake is the "worst" system in Qt Creator because CMake
>> doesn't give enough feedback to the IDE. We need first-class support for
>> CMake in Qt Creator, though, so that is irrelevant to the discussion of
>> which syst
Andrew Knight wrote:
> - (Tobias) Cmake is the "worst" system in Qt Creator because CMake
> doesn't give enough feedback to the IDE. We need first-class support for
> CMake in Qt Creator, though, so that is irrelevant to the discussion of
> which system we use to build Qt.
Anything you can get int
Hi Steve,
On 09/05/16 15:40, Stephen Kelly wrote:
- (Stephen) "In reality, rewriting Qt's build system in CMake will
actually be a PITA, and will require changes to CMake to make everything
better"
I think something was lost in transit on this point. I don’t think it would be
a PITA to write
Thanks Andrew for these notes! You did really well to capture the key points
from a complex and meandering discussion.
>- (Stephen) "In reality, rewriting Qt's build system in CMake will
>actually be a PITA, and will require changes to CMake to make everything
>better"
I think something
On Samstag, 3. September 2016 15:03:05 CEST Thiago Macieira wrote:
> https://wiki.qt.io/QtCS2016_MetaObject
>
> * qMetaType() == qMetaType()
> ** Because QMetaObject::normalizedType("const T") == "T"
> ** Fix it
QMetaObject::normalizedType("const T") -> "T" //OK
QMetaObject::normalizedType("T co
Thank you to everyone who was at QtCon during the past weekend!
I had a really good time, and from discussions there, others did as well.
The session videos (for the sessions that had cameras) are coming online soon,
right after we get the titles correct.
While I see a good number of session not
On Mon, Sep 5, 2016 at 12:27 PM, Sune Vuorela wrote:
> On 2016-09-05, Andrew Knight wrote:
> > tl;dr: Lots of discussion on the merits of which build system (CMake,
> > Qbs) should replace qmake in building Qt; lots of supporters of CMake
> > but no volunteers to do the work, many reasons to use
Been using QBS for the last 6 months, transformed all projects to it(from
qmake). Never looked back.
It just clicks for me. Most everything seems logical (if poorly explained)
when you understand how to do it.
One thing QBS needs is better documentation, because a lot of things that
are "obvious"
On 2016-09-05, Andrew Knight wrote:
> tl;dr: Lots of discussion on the merits of which build system (CMake,
> Qbs) should replace qmake in building Qt; lots of supporters of CMake
> but no volunteers to do the work, many reasons to use Qbs as well. Some
I do think that there is volunteers to g
I really want to move to QBS, because of its advantages (speed, good
dependency tracking, nice syntax, fexibility). However, as long as
Qt-Creator keeps generating new projects using qmake templates, I am not
so confident in the future of QBS. Also, if QBS is not used for all own
projects, my c
We had a vibrant discussion on Qt Build Systems, hosted by Kai.
tl;dr: Lots of discussion on the merits of which build system (CMake,
Qbs) should replace qmake in building Qt; lots of supporters of CMake
but no volunteers to do the work, many reasons to use Qbs as well. Some
related discussion
Hi,
We have released Qt 5.8.0 Alpha, see
http://blog.qt.io/blog/2016/09/05/qt-5-8-alpha-released/
At this time we managed to release it almost as planned, big thanks everyone
involved!
Br,
Jani
---
Jani Heikkinen
Release Manager
The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.hei
44 matches
Mail list logo