On Wednesday, 22 July 2020 14:17:26 PDT Bernhard Lindner wrote:
> Hi!
>
> > Breaking BC means subtle errors that are hard do detect and debug.
>
> Couldn't those subtle errors be replaced by some clear and understandable
> error? Like some explicit binary compatibility check?
Such a test does no
Hi!
> Breaking BC means subtle errors that are hard do detect and debug.
Couldn't those subtle errors be replaced by some clear and understandable
error? Like some explicit binary compatibility check?
--
Best Regards,
Bernhard Lindner
___
Developmen
On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote:
> How often do we think people are actively taking advantage of Qt's BC
> promise (and how often do we hold this promise, and how often is this
> relevant as we do not promise to change behaviour while keeping BC)?
That is a good question
On Wed, Jul 22, 2020 at 10:27:14AM +, Lars Knoll wrote:
> > On 22 Jul 2020, at 11:38, Shawn Rutledge wrote:
> >
> >
> >> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
> >>
> >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> >> actually late to the game. If we want
On Wednesday, 22 July 2020 08:52:17 PDT Simon Hausmann wrote:
> > On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote:
> > > That said, this very construct that you're referring to, that is what
> > > has been in user
> > > code since QtDeclarative was been released [1]. Anybody using
> >
On Wednesday, 22 July 2020 08:50:50 PDT Lars Knoll wrote:
> I still don’t understand why you think this should be necessary. All we need
> to do is clearly document that enabling/disabling the support for this
> feature is not binary compatible and make sure users don’t mix by accident.
First, I w
Thiago Macieira schrieb am Mi. 22. Juli 2020 um
17:46:
> On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote:
> > That said, this very construct that you're referring to, that is what
> > has been in user
> > code since QtDeclarative was been released [1]. Anybody using
> > qmlRegisterTy
> On 22 Jul 2020, at 17:30, Thiago Macieira wrote:
>
> On Wednesday, 22 July 2020 03:24:30 PDT Lars Knoll wrote:
>> no_unique_address is coming and making that problem go away. It’s available
>> on all compilers except MSVC today (see
>> https://en.cppreference.com/w/cpp/compiler_support#cpp2a
On Wednesday, 22 July 2020 03:24:30 PDT Lars Knoll wrote:
> no_unique_address is coming and making that problem go away. It’s available
> on all compilers except MSVC today (see
> https://en.cppreference.com/w/cpp/compiler_support#cpp2a).
>
> We want things to work on C++17 and that’s what we have
On 16-07-2020 17:40, Volker Hilsheimer wrote:
We need “text” to be a public member of QAction, otherwise we can’t do
action->text();
That ‘text” member is a struct with a bunch of operators overloaded, so that we
can do either
qDebug() << action->text();
qDebug() << action->text;
and
act
> On 22 Jul 2020, at 11:38, Shawn Rutledge wrote:
>
>
>> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
>>
>> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
>> actually late to the game. If we want Qt to stay relevant, then it needs to
>> offer the same kind of conveni
On 22 Jul 2020, at 00:14, Ville Voutilainen
mailto:ville.voutilai...@gmail.com>> wrote:
On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer
mailto:volker.hilshei...@qt.io>> wrote:
With the current design, notational convenience doesn’t work either:
auto text = qAction->text;
text.left(10); // booh
> On 21 Jul 2020, at 22:51, Ville Voutilainen
> wrote:
>
> On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
> wrote:
>>
>> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira
>> wrote:
>>>
>>> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
A very significant goal of this exerc
> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
>
> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> actually late to the game. If we want Qt to stay relevant, then it needs to
> offer the same kind of convenience and performance that other frameworks
> offer. This wou
14 matches
Mail list logo