On Wed, May 29, 2019 at 02:44:31PM +0200, Mutz, Marc via Development wrote:
> On 2019-05-29 13:52, Konstantin Tokarev wrote:
> > 29.05.2019, 13:56, "Mutz, Marc via Development"
> > :
> > > Hi,
> > >
> > > Here's a list of stuff I consider has served it's purpose and is no
> > > longer needed, with
Hi,
În ziua de vineri, 31 mai 2019, la 08:36:31 EEST, Thiago Macieira a scris:
> On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> > BTW, are you also planning to drop support for using PCH with GCC-like
> > compilers when building Qt? It's a thing that is trivial to do with make
>
On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> BTW, are you also planning to drop support for using PCH with GCC-like
> compilers when building Qt? It's a thing that is trivial to do with make or
> qmake, but turns into rocket science with cmake.
PCH becomes "not our problem" if
On Thursday, 30 May 2019 15:37:32 PDT Konstantin Tokarev wrote:
> > I understand, but aside from qmake, I don't know of any build system that
> > allows for building both host and target in the same build. That means
> > whatever we use in Qt 6, we'll a separate build for host tools when cross-
> >
31.05.2019, 00:57, "Thiago Macieira" :
> On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
>> > 3) all tools in cross builds link to a host QtCore that must be
>> > preinstalled Preferably, reuse the tools from that host build instead of
>> > building again
>> The latter item im
31.05.2019, 00:57, "Thiago Macieira" :
> On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
>> > 3) all tools in cross builds link to a host QtCore that must be
>> > preinstalled Preferably, reuse the tools from that host build instead of
>> > building again
>> The latter item im
On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
> > 3) all tools in cross builds link to a host QtCore that must be
> > preinstalled Preferably, reuse the tools from that host build instead of
> > building again
> The latter item implies that there should be some compatibility guran
31.05.2019, 00:19, "Thiago Macieira" :
> On Thursday, 30 May 2019 11:43:54 PDT Konstantin Tokarev wrote:
>> Does it mean that moc will be reimplemented to avoid using Qt classes?
>
> No, but moc should be the only bootstrapped tool. My point is that we should
> do away with the bootstrap library
On Thursday, 30 May 2019 11:43:54 PDT Konstantin Tokarev wrote:
> Does it mean that moc will be reimplemented to avoid using Qt classes?
No, but moc should be the only bootstrapped tool. My point is that we should
do away with the bootstrap library.
All other tools should like to QtCore. That me
Yes, verdigris is awesome. Olivier rocks:)
I’m uncertain that it will be proposed as replacement for Qt 6 though.
I think it makes total sense side by side to the moc, in any case.
Simon
On 30. May 2019, at 21:00, NIkolai Marchenko
mailto:enmarantis...@gmail.com>> wrote:
> So far nobody has s
> So far nobody has stepped up to attempt to replace the mo
https://github.com/woboq/verdigris not quite true
On Thu, May 30, 2019 at 9:59 PM Simon Hausmann wrote:
> So far nobody has stepped up to attempt to replace the moc, so I doubt
> that it will be replaced in Qt 6.
>
> Simon
>
> > On 30
Hi,
On 30/05/2019 20:20, Thiago Macieira wrote:
I like that idea. Maintains our API and semantics while removing our
implementation.
We may not even need CoW for those. Something to be benchmarked to see how
well we do. If we skip the CoW, we gain a bit in performance by removing a
level of ind
So far nobody has stepped up to attempt to replace the moc, so I doubt that it
will be replaced in Qt 6.
Simon
> On 30. May 2019, at 20:46, Konstantin Tokarev wrote:
>
>
>
> 30.05.2019, 21:18, "Thiago Macieira" :
>> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
>>
Hi,
If the Qt project decides to go with cmake, then I think that while bootstrap
will remain for the moc and rcc, I think that we may be able to remove qregexp
(Or QRegularExpression) from it. I doubt that either of them need it.
The cmake port fwiw is progressing very well and I hope that we
30.05.2019, 21:18, "Thiago Macieira" :
> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> wrote:
>> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
>> regarding to that in Qt 6.
>
> Bootstrap needs to go away in Qt 6.
Does it mean that moc will
On Wednesday, 29 May 2019 08:13:51 PDT Olivier Goffart wrote:
> I think we could get rid of QThread and get along with std::thread and
> std::thread::id
> We would have to keep a std::unordered_map,
> but that might be a bit difficult. (What happens if we do
> QObject::moveToThread(std::thread::id)
On Wednesday, 29 May 2019 10:29:37 PDT Vitaly Fanaskov wrote:
> Well, but what about MSVC, for example, or some other compilers/|platforms?
> This is rhetorical question, of course. I just want to say, that we cannot
> guarantee this sort of compatibility for all build configurations. Hence,
> this
On Wednesday, 29 May 2019 08:17:15 PDT Mutz, Marc via Development wrote:
> But of course, that's a fallacy, because as soon as Qt internally uses
> said inline functions, every use of them by the user with a different
> STL is an ODR violation and therefore UB. So, again AFAICT, the decision
> was
On Wednesday, 29 May 2019 08:22:28 PDT Allan Sandfeld Jensen wrote:
> On Mittwoch, 29. Mai 2019 15:33:23 CEST Giuseppe D'Angelo via Development
>
> wrote:
> > Il 29/05/19 12:53, Mutz, Marc via Development ha scritto:
> > > == QSet / QHash -> std::unordered_set/map ==
> > >
> > > I'd really like t
On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
wrote:
> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
> regarding to that in Qt 6.
Bootstrap needs to go away in Qt 6.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - I
On Wednesday, 29 May 2019 05:22:45 PDT Jean-Michaël Celerier wrote:
> Wasn't it said at the world summit that Qt 6 would base itself on c++17 ?
> https://blog.qt.io/blog/2018/06/13/qt-contributors-summit-2018-wrap/
We want to, but it remains to be seen at time of actual work to see if it's a
reas
On Wednesday, 29 May 2019 02:26:57 PDT Lars Knoll wrote:
> > On 28 May 2019, at 17:17, Thiago Macieira
> > wrote:
> > On Monday, 27 May 2019 04:51:35 PDT Eike Ziller wrote:
> >
> >>> * QVector for Qt 6 will most likely be updated with the changes Thiago
> >>> has
> >>> waiting since quite some
Until QList will be finally renamed=)
> 30 мая 2019 г., в 17:34, Giuseppe D'Angelo via Development
> написал(а):
>
> Hi,
>
> On 30/05/2019 10:23, Alberto Mardegan wrote:
>> I bet it's unused because everyone is using QList. But once we deprecate
>> QList, people will start asking for a CoW ver
Hi,
On 30/05/2019 10:23, Alberto Mardegan wrote:
I bet it's unused because everyone is using QList. But once we deprecate
QList, people will start asking for a CoW version of std::list.
QList has nothing to do with std::list!
(Except a very similar name.)
How many times does this need to be
On 30/05/19 11:40, Mutz, Marc wrote:
> On 2019-05-30 10:23, Alberto Mardegan wrote:
>> It's not clear to me why splice() cannot be implemented: it would just
>> mean that the list data would detach as in all other non-const methods.
>> Or am I missing something?
>
> You're passing two iterators. I
> So, yes, this is borne out of frustration with the lack of maintenance
> of QtCore plumbing. I don't see that changing and I acknowledge and
> understand that the focus of development has shifted towards QML.
This exactly is the core problem. There are many things I could say about this.
Allo
On 2019-05-30 10:23, Alberto Mardegan wrote:
It's not clear to me why splice() cannot be implemented: it would just
mean that the list data would detach as in all other non-const methods.
Or am I missing something?
You're passing two iterators. In order to implement slice(), you'd need
to iter
On 29/05/19 13:53, Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place. It's _because_ they are public that we have two of
> them, and soon a third one (properly non
On 5/29/19, Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place.
>
I disagree (unless there's some replacement you forgot to mention?).
Being able to create implici
29 matches
Mail list logo
