Hi Marco!
On Fri, 24 May 2019 at 18:34, Marco Bubke wrote:
>
> Maybe flatpak is the way to go? There could be two runtimes. Personally I use
> more and more flatpaks because I get up-to-date packages provided by the
> developers.
With my maintainer hat on: no, flatpak is not the way to go for
Il 24/05/19 18:16, Uwe Rathmann ha scritto:
We're talking about code that users should_stop_ using anyhow,
and port away from it, right?
Please also consider the situation of 3rd party libraries ( like Qwt ),
that have to support Qt5/Qt6 from the same code base - probably for many
years after Q
Maybe flatpak is the way to go? There could be two runtimes. Personally I use
more and more flatpaks because I get up-to-date packages provided by the
developers.
On May 24, 2019 19:59:52 Lisandro Damián Nicanor Pérez Meyer
wrote:
> Hi!
>
> On Mon, 20 May 2019 at 10:53, Lars Knoll wrote:
> [
Hi!
On Mon, 20 May 2019 at 10:53, Lars Knoll wrote:
[snip]
> I’m not proposing to make QList inherit QVector. Actually, I’m making it an
> alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 .
>
> With that, one option could be to make the alias dependent on a compile ti
On 5/24/19 2:30 PM, Giuseppe D'Angelo via Development wrote:
We're talking about code that users should _stop_ using anyhow,
and port away from it, right?
Please also consider the situation of 3rd party libraries ( like Qwt ),
that have to support Qt5/Qt6 from the same code base - probably fo
Hi,
Il 24/05/19 15:24, Simon Hausmann ha scritto:
Hi,
I don't think our users should have to use a build of Qt that has its
internal Q_ASSERTs enabled. IMHO Q_ASSERT should be used by developers
in Qt to express invariants that, if violated, represent a bug in Qt
that needs fixing. I don't
Hi,
I don't think our users should have to use a build of Qt that has its internal
Q_ASSERTs enabled. IMHO Q_ASSERT should be used by developers in Qt to express
invariants that, if violated, represent a bug in Qt that needs fixing. I don't
think we should use Q_ASSERT to communicate anything
Il 24/05/19 14:09, Mutz, Marc via Development ha scritto:
2. Keep QList as-is. It cannot be an alias to QVector/QArrayList, nor
can it be implemented in terms of either (only at the d-pointer level)
Is it worth the cost? I don't know.
I'm still in favour at keeping QList as-is and paying the c
Il 23/05/19 09:36, Simon Hausmann ha scritto:
I think a well-formed state is more likely to enable our users to have a
productive time. Operating - by accident - on a partially-formed object
and either
(1) seeing a back-trace that points into Qt, not my application code
(2) spending
> On 24 May 2019, at 14:09, Mutz, Marc via Development
> wrote:
>
> On 2019-05-24 11:03, Lars Knoll wrote:
> [...]
>> You conveniently didn’t quote the first part of my answer. I didn’t
>> say that. I said I really want to ensure that we get a zero copy
>> conversion between QList and QVector w
On 2019-05-24 11:03, Lars Knoll wrote:
[...]
You conveniently didn’t quote the first part of my answer. I didn’t
say that. I said I really want to ensure that we get a zero copy
conversion between QList and QVector where this doesn’t imply
(possible) incorrectness in the code. That’s the case for
24.05.2019, 10:07, "Jukka Jokiniva" :
> About contribution to Gerrit,
>
> Our Gerrit customization has two parts:
> * Most of the logic is in a qt specific plugin which is hosted at
> https://codereview.qt-project.org/gitweb?p=qtqa/gerrit-plugin-qt-workflow.git
> * Then we have some forks on
24.05.2019, 14:27, "Konstantin Tokarev" :
> Actually, clazy provides related checks "inefficient-qlist". I think
> following plan can work:
>
> 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy
> which finds QList
> where sizeof(T) <= sizeof(void*) and T is movable, and
One change that is relatively painless but will set things for the later
reintroduction of QList as a proper class would be with Qt6 force rename
QList instances to Qt5SupportList.
Note that if it's done at the same time as removal of QList from Qt
interfaces entirely, then it's a simple pass of ba
24.05.2019, 13:32, "Konstantin Tokarev" :
> 24.05.2019, 13:06, "NIkolai Marchenko" :
>> All of the back and forth on this issue recently and over the years really
>> make want to ask this question:
>>
>> Is the promise of SC worth all the potenital pitfalls? There seems to be no
>> end to the
NIkolai Marchenko (24 May 2019 12:03) asked
> Is the gordian knot of full SC really possible to unravel or is it time to
> axe it?
Or at least, for this one case, recognise that a SC break is better than
the alternatives and, since this is the Qt6 transition where we don't
promise not to make SC
24.05.2019, 13:06, "NIkolai Marchenko" :
> All of the back and forth on this issue recently and over the years really
> make want to ask this question:
>
> Is the promise of SC worth all the potenital pitfalls? There seems to be no
> end to the discussion with every solution requiriring hair ri
All of the back and forth on this issue recently and over the years really
make want to ask this question:
Is the promise of SC worth all the potenital pitfalls? There seems to be no
end to the discussion with every solution requiriring hair rising
compromises.
Is it _really_ that impossible to ju
24.05.2019, 12:44, "Kai Köhne" :
>> -Original Message-
>> From: Development On Behalf Of
>> Bernhard Lindner
>> Subject: Re: [Development] Qt XML and Qt Xml Patterns
>>
>> > It's good that Bernhard has received an official statement.
>>
>> I agree! Thank you!
>
> Indeed, thanks for
> -Original Message-
> From: Development On Behalf Of
> Bernhard Lindner
> Subject: Re: [Development] Qt XML and Qt Xml Patterns
>
> > It's good that Bernhard has received an official statement.
>
> I agree! Thank you!
Indeed, thanks for bringing this up here! We quite obviously should
> On 24 May 2019, at 10:19, Mutz, Marc via Development
> wrote:
>
> On 2019-05-24 09:35, Lars Knoll wrote:
>>> On 23 May 2019, at 13:26, Mutz, Marc via Development
>>> wrote:
> [...]
>>> You said that QList should vanish from Qt API. So we don't care. We'll have
>>> that switch to make QList
On 2019-05-24 09:35, Lars Knoll wrote:
On 23 May 2019, at 13:26, Mutz, Marc via Development
wrote:
[...]
You said that QList should vanish from Qt API. So we don't care. We'll
have that switch to make QList _be_ QVector for ese of porting, but as
a template alias. There's your zero-copy conve
> On 23 May 2019, at 13:26, Mutz, Marc via Development
> wrote:
>
> On 2019-05-23 10:40, Lars Knoll wrote:
> [...]
4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between
About contribution to Gerrit,
Our Gerrit customization has two parts:
* Most of the logic is in a qt specific plugin which is hosted at
https://codereview.qt-project.org/gitweb?p=qtqa/gerrit-plugin-qt-workflow.git
* Then we have some forks on top of the official Gerrit release
https://codere
24 matches
Mail list logo
