Il 02/11/18 20:13, Иван Комиссаров ha scritto:
Nice idea to have such a method. But is't it a pessimization to return a vector
which certainly allocates?
Don't throw rocks in me, what about passing std::function that can enumerate
roles?
As I said, we can bikeshed on the signature. How do
Sure. Sorry for std::array_view (it maybe a QSet or QVector or gsl::span
whatever more convinient/faster).
The basic idea is here:
In the model:
void multipleData(QModelIndex index, std::array_view roles,
std::function enumerator)
{
for (auto&& role: roles) {
if (role ==
I vote for 3. The (small) argument is: with qint one cannot write an algorithm
taking std:: class (std::vector) and a Qt class but with size_type it
can.
Something like
template T::size_type * getSize(const T ) { return t.size(); }
auto d1 = getSize(std::vector()); // ok
auto d2 =
Renaming the subthread (it’s got nothing to do with build systems…)
I believe I have a solution to get rid of QList without breaking SC in any
major way. See https://codereview.qt-project.org/#/c/242199/ and the following
changes.
I did some benchmarking (as we were worried about the different
On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote:
> > Depends on usage.
> >
> > See e.g. 551efd91990e07902e5324f720cf5585865c323d
> >
> > QmlProfiler: Use QList for QmlRange container when loading .qtd
> >
> > As we are using this as a queue, with many calls to
On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote:
> What do we do?
>
> Option 1: do nothing, wait for Qt 6 and do the change then
> Option 2: insert #if in our API, starting now
> Option 3: use #if per class, starting now
> Option 4: create a central #if and use this new type,
On Thu, Nov 01, 2018 at 08:45:58PM -0700, Thiago Macieira wrote:
> On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote:
> > Thiago Macieira wrote:
> > > We're studying what to do with QList, but the idea is that the name
> > > "QList" will be completely ok and identical to QVector. The
On 2 Nov 2018, at 09:04, Philippe
mailto:philw...@gmail.com>> wrote:
I did some benchmarking (as we were worried about the different performance
characteristics of QList and QVector) and with the exception of prepending in a
loop pretty much all other operations gets faster with this change.
> On 2 Nov 2018, at 04:45, Thiago Macieira wrote:
>
> On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote:
>> Thiago Macieira wrote:
>>> We're studying what to do with QList, but the idea is that the name
>>> "QList" will be completely ok and identical to QVector. The technical
>>>
On 2 Nov 2018, at 10:10, André Pönitz
mailto:apoen...@t-online.de>> wrote:
On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote:
Depends on usage.
See e.g. 551efd91990e07902e5324f720cf5585865c323d
QmlProfiler: Use QList for QmlRange container when loading .qtd
As we are using
On Thursday, 1 November 2018 20:42:52 PDT Thiago Macieira wrote:
> What do we do?
Example: https://codereview.qt-project.org/25
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
> On 30 Oct 2018, at 22:57, Christian Gagneraud wrote:
>
> Hi Lars,
>
> On Tue, 30 Oct 2018 at 23:42, Lars Knoll wrote:
>>> On 30 Oct 2018, at 05:00, Christian Gagneraud wrote:
>>> On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote:
>>> Then why spend energy/money to fix something that is broken
> Depends on usage.
>
> See e.g. 551efd91990e07902e5324f720cf5585865c323d
>
> QmlProfiler: Use QList for QmlRange container when loading .qtd
>
> As we are using this as a queue, with many calls to takeFirst(), a
> QVector is prohibitively expensive here.
I should have used
On 02.11.18 09:20, Ulf Hermann wrote:
Depends on usage.
See e.g. 551efd91990e07902e5324f720cf5585865c323d
QmlProfiler: Use QList for QmlRange container when loading .qtd
As we are using this as a queue, with many calls to takeFirst(), a
QVector is prohibitively expensive
I did some benchmarking (as we were worried about the different performance
characteristics of QList and QVector) and with the exception of prepending in a
loop pretty much all other operations gets faster with this change.
Another exception is certainly the sorting of large objects that are
> On 2 Nov 2018, at 09:02, André Pönitz wrote:
>
> On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote:
>> What do we do?
>>
>> Option 1: do nothing, wait for Qt 6 and do the change then
>> Option 2: insert #if in our API, starting now
>> Option 3: use #if per class, starting now
>>
On Fri, Nov 02, 2018 at 08:52:07AM +, Lars Knoll wrote:
> > On 2 Nov 2018, at 09:02, André Pönitz wrote:
> >
> > On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote:
> >> What do we do?
> >>
> >> Option 1: do nothing, wait for Qt 6 and do the change then
> >> Option 2: insert
Yes, but you've still broken the promise made in the earlier blog post of
making qbs a replacement for qmake and build system for qt.
Also, there's a high chance that with Chrisitan Kandeler moving away, qbs
will just stagnate and die.
This was somethign that was promised to be developed and
> I was told, there's a qbs.io or something going on?
Wow, kudo to whoever, qbs.io redirects to doc.qt.io/qbs
Chris
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
TQtC has essentially alienated the very people they want to have on their
side for new stuff: early adopters.
People willing to try and help develop stuff for them. I will not feel
inclined to try anything new you guys showcase in teh future.
Have fun devoping technologies without testers.
On
Exactly. We are very pleased if there are people who start to contribute to
Qbs. So far it has been very little by others than employees of The Qt Company.
We will continue maintaining Qbs so that it stays supported until end of 2019
and also release a new version in April 2019 as promised.
On Fri, 2 Nov 2018 at 23:55, Lars Knoll wrote:
>
>
> On 2 Nov 2018, at 11:45, Christian Gagneraud wrote:
>
> On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
> wrote:
>
>
>
> Hi,
> I have to apologise for my behaviour. While I still think Christian
> Gagneraud's attack on the Qt
On 2 Nov 2018, at 13:08, Christian Gagneraud
mailto:chg...@gmail.com>> wrote:
On Fri, 2 Nov 2018 at 23:55, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
On 2 Nov 2018, at 11:45, Christian Gagneraud
mailto:chg...@gmail.com>> wrote:
On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
On 2 Nov 2018, at 11:45, Christian Gagneraud
mailto:chg...@gmail.com>> wrote:
On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
mailto:development@qt-project.org>> wrote:
Hi,
I have to apologise for my behaviour. While I still think Christian Gagneraud's
attack on the Qt company
>You've just dropped Qbs, what's next?
>I don't trust you anymore, nor the company-ies you represent - Nothing
>personal.
>I think that it is time for the qt-project.org domain to be handed
>back to the Qt Project community.
But "dropped Qbs" means The Qt Company won't be developing Qbs anymore,
> But it would not change the facts - it is an impossibly huge task to
replace CMake with Qbs even within the Qt users, let alone outside of Qt.
Yes... then you *should not have encouraged* your customers to switch in
the first place.
Either you are committed to keep you *promises* or you are
Hi Tuukka,
On 02.11.2018 13:44, Tuukka Turunen wrote:
Exactly. We are very pleased if there are people who start to
contribute to Qbs. So far it has been very little by others than
employees of The Qt Company.
We will continue maintaining Qbs so that it stays supported until end
of 2019 and
On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
wrote:
>
>
> Hi,
> I have to apologise for my behaviour. While I still think Christian
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for,
> it's not a justification for my actions.
> Creating an hostile
On Sat, 3 Nov 2018 at 01:15, Martin Smith wrote:
>
> >You've just dropped Qbs, what's next?
> >I don't trust you anymore, nor the company-ies you represent - Nothing
> >personal.
> >I think that it is time for the qt-project.org domain to be handed
> >back to the Qt Project community.
>
> But
Here is what I replied to the mail (when sent to me only):
Hi,
This is absolutely true and we are well aware of this.
We had a bit similar issue earlier when we ramped down engin.io backend:
https://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users/
We try to avoid such
On Friday, 2 November 2018 00:06:12 PDT Иван Комиссаров wrote:
> I vote for 3. The (small) argument is: with qint one cannot write an
> algorithm taking std:: class (std::vector) and a Qt class but with
> size_type it can.
>
> Something like
> template T::size_type * getSize(const T ) { return
On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote:
> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
>
> > We have a lot of API that, for Qt 6, we've already decided to extend to
> > 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit
> > ones.
>
(thiws was originally sent only to Tuukka, resending)
I would also like to point out the mistrust you've created by proxy.
In believing your promises people have migrated projects at their jobs to
qbs.
Now they will be known as too hasty adopters of dead systems.
Not saying it will be the case
On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
> We have a lot of API that, for Qt 6, we've already decided to extend to
> 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit
> ones.
Smells like qreal, with all problems that it causes... We could reconsider
Hi!,
We have soft branched '5.11.3' from '5.11' today. So please start using
'5.11.3' for new changes targeted to Qt 5.11.3 release.
Final downmerge from '5.11' to '5.11.3' will happen Friday 9th November so
there should be enough time to start using '5.11.3'
br,
Jani
Il 02/11/18 14:04, Julius Bullinger ha scritto:
To be honest, that's not at all what the blog post at
http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs/ suggests:
> We have decided to deprecate Qbs and redirect our resources to
> increase support for CMake.
The keyword here
On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote:
What do we do?
Option 1: do nothing, wait for Qt 6 and do the change then
Option 2: insert #if in our API, starting now
Option 3: use #if per class, starting now
Option 4: create a central #if and use
Here is what I replied to the mail (when sent to me only):
Hi,
This is absolutely true and we are well aware of this.
We had a bit similar issue earlier when we ramped down engin.io backend:
https://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users/
We try to avoid such
Tuukka,
On 02.11.2018 13:44, Tuukka Turunen wrote:
>
> Exactly. We are very pleased if there are people who start to contribute
> to Qbs. So far it has been very little by others than employees of The Qt
> Company.
Here are some possible reasons:
- the Qbs core code base is complex
- the code
On Fri, Nov 02, 2018 at 02:36:26PM +, Edward Welbourne wrote:
> On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote:
> What do we do?
>
> Option 1: do nothing, wait for Qt 6 and do the change then
> Option 2: insert #if in our API, starting now
> Option 3:
On Fri, Nov 02, 2018 at 11:59:39AM -0400, Matthew Woehlke wrote:
> On 01/11/2018 08.10, Oswald Buddenhagen wrote:
> > no, instead i told you that your premise of needing a _global_ solver is
> > wrong.
>
> ...but you have failed to explain how dependency resolution will succeed
> in a scenario
Yeah, forget my argument. Go for 4.
Иван Комиссаров
> 2 нояб. 2018 г., в 16:02, Thiago Macieira
> написал(а):
>
>> On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote:
>>> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
>>>
>>> We have a lot of API that, for Qt 6,
Hi,
Il 02/11/18 07:05, Shawn Rutledge ha scritto:
This is reasonable given the tree-of-tables that QAbstractItemModel models;
there's the bigger question of whether the one-API-fits-all is a good way
forward, however I don't see anyone willing to rewrite the model classes for
this. (There
On 01/11/2018 08.10, Oswald Buddenhagen wrote:
> no, instead i told you that your premise of needing a _global_ solver is
> wrong.
...but you have failed to explain how dependency resolution will succeed
in a scenario such as I have outlined.
Actually, I realize now there is a possible answer:
> It seems to differ quite a bit in scale. That blog post has 7 comments.
> Compare it to nearly 150 on "Deprecation of Qbs" in 3 days and countless
> emails here on the mailing list. I seem to wonder if the whole issue
> could be avoided if it was approached a bit more diplomatically from the
> On 31 Oct 2018, at 13:21, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> Il 31/10/18 11:19, Иван Комиссаров ha scritto:
>> 1) QAbstractItemModel. I want to introduce change that adds QModelIndex
>> parameter to headerData(). For now, QHeaderView ignores the rootIndex()
>>
On 11/2/18 10:10 AM, André Pönitz wrote:
> On Fri, Nov 02, 2018 at 08:20:39AM +, Ulf Hermann wrote:
>>> Depends on usage.
>>>
>>> See e.g. 551efd91990e07902e5324f720cf5585865c323d
>>>
>>> QmlProfiler: Use QList for QmlRange container when loading .qtd
>>>
>>> As we are using
Nice idea to have such a method. But is't it a pessimization to return a vector
which certainly allocates?
Don't throw rocks in me, what about passing std::function that can enumerate
roles?
Иван Комиссаров
> 2 нояб. 2018 г., в 17:52, Giuseppe D'Angelo via Development
> написал(а):
>
> Hi,
Hi,
> On 2 Nov 2018, at 16:02, Thiago Macieira wrote:
>
>> On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote:
>>> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
>>>
>>> We have a lot of API that, for Qt 6, we've already decided to extend to
>>> 64-bit on 64-bit
On Friday, 2 November 2018 12:18:56 PDT André Somers wrote:
> > So you want users to know now, in Qt 5, that this particular type in the
> > API will become qsizetype in Qt 6?
>
> Yes. Why not take it one step further and just call it qsizetype too? The
> docs can say that this will be int in
50 matches
Mail list logo
