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 == Qt::DisplayRole
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 you
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 Qt5,
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 p
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,
>
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 co
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 suc
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: u
> 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
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 are
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
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,
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.
>
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 &t) { return t
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
_
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 thi
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 th
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 being
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
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
(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 fo
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 als
> 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 no
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
mai
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. Mo
> 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 Fri,
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 "dr
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 nurt
>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,
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 compan
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 abili
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 environm
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 #if
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 this
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 th
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 takeFirst(
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
> 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 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
>>> mecha
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.
> 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 QQu
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 tec
> 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
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 not
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, start
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
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 &t) { return t.size(); }
auto d1 = getSize(std::vector()); // ok
auto d2 = getSize(QStr
48 matches
Mail list logo
