[Development] Farewell

[Sona Kurazyan]

Dear Qt Collogues,

As many of you already know, I am leaving The Qt Company to pursue some new 
challenges, and today is my last working day.

I am really grateful for the opportunity to join the amazing Qt family and 
contribute to Qt project, work with so many nice people and great professionals.
Working at The Qt Company was a unique experience for me, I’ve learned a lot 
during the past (almost) 4 years and grew professionally.
Special thanks to my colleagues from my past (Qt for Automation) and present 
(Core) teams and my managers (Alex and Cristián), it was a pleasure working 
with you all!

In case you’re interested in staying connected, you can reach me via 
Linkedin, or personal 
e-mail.

I wish you all the best, and who knows, we might still cross paths in future 

Best regards,
Sona
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released

[Sona Kurazyan]

I've created a revert commit for 5.15, see 
https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/431686.

Best regards,
Sona

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Thursday, September 8, 2022 11:23 PM
> To: development@qt-project.org
> Subject: Re: [Development] Binary incompatible change in QtConcurrent -
> was - Re: Qt 5.15.6 Opensource released
> 
> On Thursday, 8 September 2022 14:06:24 PDT Albert Astals Cid wrote:
> > Should we restore those symbols or just accept that Qt 6 broke BC a
> > year ago and no one realized so why bring the symbols back?
> 
> The commit message says
> 
> Remove the dead code for blocking methods from QtConcurrent
> 
> After 79fd1cb2c631b6084bf10874205d27f5b53c907a the methods for
> running
> QtConcurrent algorithms in the blocking mode aren't used anymore. Since
> ThreadEngineBase and ThreadEngineStarter classes aren't meant to be
> used
> externally, it should be fine to remove startBlocking() methods now.
> 
> ThreadEngineBase is used only by ThreadEngine, plus its static
> ThreadEngineBase::threadPool is used by
> IterateKernel::forThreadFunction().
> But ThreadEngine is a template class deriving from ThreadEngineBase, and
> IterateKernel is a template class deriving from ThreadEngine and that is in
> turn a base class for a lot of other classes.
> 
> Therefore, ThreadEngineBase is used by user code, only indirectly.
> 
> So the question is whether the removed function was ever callable in
> QtConcurrent from 6.0 to 6.3. The commit this commit refers to landed in 6.0.
> So if the commit message is correct, then there's no problem in Qt 6, because
> if something still called this function, it would have broken in this commit.
> 
> According to the Git log, 1bf75f2a661c05c7f1126187310d7df3f9704af5 is the
> only commit since Git tag v6.0.0 that touches a line that mentions
> "startBlocking".
> Therefore, there is no BC problem in Qt 6.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Cloud Software Architect - Intel DCAI Cloud Engineering
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt UDL operators

[Sona Kurazyan]

Hi,

> From: Giuseppe D'Angelo 
> 
> Hi,
> 
> Il 04/04/22 15:53, Sona Kurazyan ha scritto:
> > I see two main issues with keeping both:
> >
> > - If we want to add UDLs with same names for different domains in future,
> adding the "q"-prefixed counterparts will be problematic. For example, let's
> say we want to add Qt::inline Literals::inline OtherDomain::_s, what should
> be the "q"-prefixed version of it? We can name it to something like _qXs,
> where X is some domain specific letter, but it will require even more typing,
> and make the name inconsistent with Qt::inline Literals::inline
> OtherDomain::_s.
> 
> I'm not sure how this work: unless the new _s takes another kind input
> (e.g. number literals), you can't add it no matter what, as users under
> "using namespace Qt;" would then get a conflict...?
> 

Right, it will work only if the types of the literals with the same name 
differ, so we can add e.g. _s for seconds (or something else) in future.

> 
> >
> > - We will have multiple ways of doing the same thing, and I assume, it might
> be confusing for users.
> 
> Sure thing, that's why I'm OK at deprecating one of the two.
> 
> Thanks,
> 

I'll wait a bit more, to make sure that there are no more concerns/objections 
against deprecating _qX and adding their counterparts to Qt::StringLiterals, 
and merge https://codereview.qt-project.org/c/qt/qtbase/+/401308/ and 
https://codereview.qt-project.org/c/qt/qtbase/+/401604/.

Best regards,
Sona

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt UDL operators

[Sona Kurazyan]

I see two main issues with keeping both:

- If we want to add UDLs with same names for different domains in future, 
adding the "q"-prefixed counterparts will be problematic. For example, let's 
say we want to add Qt::inline Literals::inline OtherDomain::_s, what should be 
the "q"-prefixed version of it? We can name it to something like _qXs, where X 
is some domain specific letter, but it will require even more typing, and make 
the name inconsistent with Qt::inline Literals::inline OtherDomain::_s.

- We will have multiple ways of doing the same thing, and I assume, it might be 
confusing for users.

Best regards,
Sona 
> -Original Message-
> From: Development  On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: Monday, April 4, 2022 3:22 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt UDL operators
> 
> Il 30/03/22 15:44, Sona Kurazyan ha scritto:
> > # keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add
> > Qt::StringLiterals::{_s, _ba}
> > (https://codereview.qt-project.org/c/qt/qtbase/+/402948
> > <https://codereview.qt-project.org/c/qt/qtbase/+/402948> +
> > https://codereview.qt-project.org/c/qt/qtbase/+/401308
> > <https://codereview.qt-project.org/c/qt/qtbase/+/401308>)
> 
> I'd personally vote for this option -- whatever users use, they have the full
> set. It'd be super-annoying to have to mix and match (codebase already
> using _qba now has to import the others...)
> 
> I'm not also too sold on the argument that _qs ought to be deprecated.
> Qt de-facto has always reserved every single name starting in q (or Q) in the
> global namespace. Whether polluting the global namespace (and/or living
> "without a namespace") is a good idea or not, that's a sailed ship
> unfortunately. That just carries over to these UDLs. This is to say, I'm not
> opposing their deprecation and subsequent removal, and I'm much in favour
> of actual deprecation rather than hiding behind yet another
> QT_NO_GLOBAL_UDLS or similar, I'm just saying that "name pollution" isn't a
> very much convincing argument (for the good and the bad)...
> 
> My 2 c,
> 
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software
> Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt UDL operators

[Sona Kurazyan]

Following Thiago's advice, updated 
https://codereview.qt-project.org/c/qt/qtbase/+/401604/ to enable the warning 
only after N+4 minor release of Qt (i.e. 6.8). That should give more time for 
updating the existing code.

Best regards,
Sona

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Sunday, April 3, 2022 4:05 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt UDL operators
> 
> On Saturday, 2 April 2022 07:46:33 PDT Kai Köhne wrote:
> > If you use the "Qt Quick Application" wizard in any recent Qt Creator,
> > and selected a Qt 6 version as minimally required version, the
> > generated main.cpp code will contain code like
> >
> >   const QUrl url(u"qrc:/myproject/main.qml"_qs);
> >
> > Deprecating the u""_qs will mean that we break the most basic user
> > 'hello world' projects utilizing this wizard. I therefore think it's
> > too late to deprecate u""_qs any time soon.
> 
> It'll have to be a multi-year process then.
> 
> Step 1) stop generating this for new code
> 
> Step 2) 2 years later, add the warning of deprecation (the actual code change
> can be done now, with the warning enabled for the N+4 minor release of Qt)
> 
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt UDL operators

[Sona Kurazyan]

e 
fixed.
  3.  UDLs should be short at the use site, because we want people to use them. 
If not for their brevity, they carry no value over traditional constructor 
syntax: "meep"_L1 vs. QLatin1StringView("meep"). There is absolutely no sense 
in long UDLs like "meep"_qlatin1stringview, and even _qs vs. _s matters in that 
respect (it's a 50% increase in the identifier name!)
  4.  Any project should be able to decide for itself how to handle UDLs. Some 
may choose to require using declarations in every function or every scope a UDL 
is used, some may require it at namespace scope of every implementation file, 
some may add it to some central header (which is ok for an app, but not for a 
library, cf. SF.7 
(https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#Rs-using-directive)).
 The point is: we need to allow users to make their own choice. By adding our 
UDLs to ::inline QtLiterals, we deprive them of that choice, and we potentially 
break their code in unfixable ways. We even allow users to switch off 'signals' 
and 'slots' macros, but users wouldn't be able to switch off our UDLs.
This is why they need to be in Qt::inline Literals::inline StringLiterals. 
Anchoring the inline namespaces (which here are just for convenience, so you 
can alternatively say "using Qt::Literals" or "using Qt::StringLiterals" or 
"using Qt::Literals::StringLiterals") in the non-inline Qt namespace makes it 
possible for API consumers to switch them off.

In addition to the above the nested StringLiterals namespace gives us the 
flexibility to add (short!) UDLs for non-string domains, later, without 
conflict. E.g. std has s for seconds as well as for std::string. We should just 
copy what works instead of inventing creative ways to break users.

Thanks,
Marc



From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Sona Kurazyan mailto:sona.kuraz...@qt.io>>
Sent: Friday, March 11, 2022 5:26 PM
To: Macieira, Thiago 
mailto:thiago.macie...@intel.com>>; 
development@qt-project.org<mailto:development@qt-project.org> 
mailto:development@qt-project.org>>
Subject: Re: [Development] Renaming QLatin1String to QLatin1StringView

> BTW, shouldn't this one also have a "v" somewhere, like _qsv?

If there's a chance of adding an owning class for Latin-1 in future, it might 
make sense to reserve _L1 for it and add "v" for QLatin1StringView literal.
On the other hand, we can call the literal operator for the owning class _L1s, 
and save some typing for the QLatin1StringView users (which, I guess, would be 
more common to use).

Best regards,
Sona

> -Original Message-
> From: Development 
> mailto:development-boun...@qt-project.org>>
>  On Behalf Of
> Thiago Macieira
> Sent: Friday, March 11, 2022 4:39 PM
> To: development@qt-project.org<mailto:development@qt-project.org>
> Subject: Re: [Development] Renaming QLatin1String to QLatin1StringView
>
> On Friday, 11 March 2022 00:46:16 PST Sona Kurazyan wrote:
> > s. In Qt 7, QLatin1StringView will become "the real" class for Latin-1
> > string view, and QLatin1String will be kept as alias to it.
>
> I'd like to say I support this, at least as far as 7.0 with just the alias.
>
> When or if ever we drop the QLatin1String name and even if we ever add a
> new class is a subject for much later and doesn't have to be taken now. But
> unless we do the change Sona is proposing now, we that option wouldn't be
> on the table.
>
> > Note that Qt 6.4 introduces a literal operator""_L1 for constructing
> > Latin-1 string literals, to minimize the porting effort from
> > QLatin1String to QLatin1StringView.
>
> BTW, shouldn't this one also have a "v" somewhere, like _qsv?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> Development mailing list
> Development@qt-project.org<mailto:Development@qt-project.org>
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Renaming QLatin1String to QLatin1StringView

[Sona Kurazyan]

> BTW, shouldn't this one also have a "v" somewhere, like _qsv?

If there's a chance of adding an owning class for Latin-1 in future, it might 
make sense to reserve _L1 for it and add "v" for QLatin1StringView literal.
On the other hand, we can call the literal operator for the owning class _L1s, 
and save some typing for the QLatin1StringView users (which, I guess, would be 
more common to use). 

Best regards,
Sona

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Friday, March 11, 2022 4:39 PM
> To: development@qt-project.org
> Subject: Re: [Development] Renaming QLatin1String to QLatin1StringView
> 
> On Friday, 11 March 2022 00:46:16 PST Sona Kurazyan wrote:
> > s. In Qt 7, QLatin1StringView will become "the real" class for Latin-1
> > string view, and QLatin1String will be kept as alias to it.
> 
> I'd like to say I support this, at least as far as 7.0 with just the alias.
> 
> When or if ever we drop the QLatin1String name and even if we ever add a
> new class is a subject for much later and doesn't have to be taken now. But
> unless we do the change Sona is proposing now, we that option wouldn't be
> on the table.
> 
> > Note that Qt 6.4 introduces a literal operator""_L1 for constructing
> > Latin-1 string literals, to minimize the porting effort from
> > QLatin1String to QLatin1StringView.
> 
> BTW, shouldn't this one also have a "v" somewhere, like _qsv?
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Renaming QLatin1String to QLatin1StringView

[Sona Kurazyan]

Hi All,

I'd like to inform you that I'm working on a series of changes (originally 
started by Marc Mutz) for introducing QLatin1StringView as an alias to 
QLatin1String https://codereview.qt-project.org/c/qt/qtbase/+/400032 and 
gradually switching to using it in our codebase and docs 
https://codereview.qt-project.org/c/qt/qtbase/+/399872. The motivation is 
keeping API consistency: QLatin1String is not an owning container, but a view 
and should be named like other Qt string view classes. In Qt 7, 
QLatin1StringView will become "the real" class for Latin-1 string view, and 
QLatin1String will be kept as alias to it.

Note that Qt 6.4 introduces a literal operator""_L1 for constructing Latin-1 
string literals, to minimize the porting effort from QLatin1String to 
QLatin1StringView.

You can also check https://bugreports.qt.io/browse/QTBUG-98434 for more details.

Please let me know, if there are any opinions or concerns that should be 
considered before proceeding and merging the changes.

Thanks,
Sona
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

[Sona Kurazyan]

Thanks everyone!

Best regards,
Sona

> -Original Message-
> From: Development  On Behalf Of
> Cristián Maureira-Fredes
> Sent: Thursday, February 17, 2022 3:25 PM
> To: development@qt-project.org
> Subject: Re: [Development] Nominating Sona Kurazyan as maintainer of
> qt5compat
> 
> Hello,
> 
> Forgot to wrap up this discussion :P
> but thanks for your comments,
> and congratulations Sona for being the
> new maintainer of Qt5Compat.
> 
> Cheers
> 
> On 1/18/22 15:10, Cristián Maureira-Fredes wrote:
> > Hello,
> >
> > I would like to nominate Sona as maintainer [1] for the qt5compat
> > module, which at the moment doesn't have one. Even if it's a special
> > module we have around only for Qt6, we need a responsible person in
> > charge of it.
> >
> > She has been working mainly in qtbase in the last years and took care
> > of many tasks when the module was created [2].
> >
> > Due to her contributions in qtbase and other modules [3], I firmly
> > believe she will manage to maintain it.
> >
> > Cheers
> >
> >
> > [1] https://wiki.qt.io/Maintainers#Qt_Maintainers
> > [2]
> > https://codereview.qt-
> project.org/q/owner:sona.kurazyan%2540qt.io+repo
> > :qt/qt5compat+status:merged
> >
> > [3]
> > https://codereview.qt-
> project.org/q/owner:sona.kurazyan%2540qt.io+stat
> > us:merged
> >
> >
> 
> --
> Dr. Cristián Maureira-Fredes
> R Manager
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ivan Solovev as approver

[Sona Kurazyan]

+1!

Disclaimer: we work in the same team.

> -Original Message-
> From: Development  On Behalf Of
> Alex Blasche
> Sent: Tuesday, June 15, 2021 1:18 PM
> To: development@qt-project.org
> Subject: [Development] Nominating Ivan Solovev as approver
> 
> Hi,
> 
> I'd like to nominate Ivan Solovev as an approver for the Qt Project.
> 
> Ivan has been working on various parts of the Qt6 port and has regularly
> contributed to QtBase  modules, QtPositioning, QtNfc & other modules.
> Personally, I am particularly thankful for his help in furthering the Qt 
> Bindings
> support in QtPositioning and his review of countless other patches in the
> same domain.
> 
> He has authored the following patches:
> https://codereview.qt-project.org/q/owner:ivan.solovev%2540qt.io,100
> and reviewed the following:
> https://codereview.qt-project.org/q/reviewer:ivan.solovev%2540qt.io,100
> 
> Since  both our office rooms share one wall I am also thankful for many
> technical discussions who broke the enforced solitude of the corona days :)
> 
> --
> Alex
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QMetaType support for QFuture

[Sona Kurazyan]

I was suggesting QtPrivate::, since QFutureInterface/QFutureInterfaceBase 
aren’t public and access to QFuture’s d-ptr is not something we would want to 
recommend generally, I don’t think the average user will need it.
But, of course, the exact API can be discussed.

Best regards,
Sona

From: Konstantin Ritt 
Sent: Saturday, May 8, 2021 6:26 PM
To: Sona Kurazyan 
Cc: Arno Rehn ; Qt development mailing list 

Subject: Re: [Development] QMetaType support for QFuture

Can't we simply `QFutureInterface(const QFuture )` to get that 
future's QFutureInterface, w/o any QtPrivate:: ugliness?


Regards,
Konstantin


сб, 8 мая 2021 г. в 11:30, Sona Kurazyan 
mailto:sona.kuraz...@qt.io>>:
Hi Konstantin,

QFuture has a constructor for QFuture from QFuture,  see 
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread/qfuture.h#n82, so 
you don’t even need to use the broken qToVoidFuture() method. I’ll probably 
remove it, since it was always broken and couldn’t be ever used.
I can see that in some special use-cases having access to QFuture’s internals 
might be useful, but this is not something we would recommend to do to all 
users. That’s why, I think, adding an API that gives access to QFuture’s d-ptr 
(as it was suggested earlier) might be an option.

Best regards,
Sona

From: Konstantin Ritt mailto:ritt...@gmail.com>>
Sent: Saturday, May 8, 2021 2:29 AM
To: Arno Rehn mailto:a.r...@menlosystems.com>>
Cc: Sona Kurazyan mailto:sona.kuraz...@qt.io>>; Qt 
development mailing list 
mailto:development@qt-project.org>>
Subject: Re: [Development] QMetaType support for QFuture

I was implementing a similar feature few years ago and had the same problem 
with QFuture internals -- https://codereview.qt-project.org/c/qt/qtbase/+/210243
As there was no interest in making those better, I had to hack it in a way I 
won't promote here ;p
But since QFuture took a new life with QPromise, it becomes even more useful 
than before and deserves some improvements IMO.
Maybe we could add a public accessor to future's d via QFutureInterfaceBase? 
Will that be acceptable?

Regards,
Konstantin


пт, 7 мая 2021 г. в 19:28, Arno Rehn 
mailto:a.r...@menlosystems.com>>:
Hi Sona,

On 07.05.21 17:11, Sona Kurazyan wrote:
> You could use the QFutureInterfaceBase (non-templated) class directly
> to build a type-erased future, that's basically what QFuture is using
> underneath. Although it's internal (not documented and is considered
> to be private), but it's declared in a public header
> (qfutureinterface.h) and you can still use it. QFutureInterfaceBase's
> methods for accessing its internals are public (with a few exceptions
> that you probably won't need to use). I hope that helps.

Yep, that's what I thought as well. But I cannot get it from an existing
QFuture because it's a private member. We could add some private API to
extract the QFutureInterfaceBase, however.

Anyway, I think I'll have to add some QMetaType magic anyway for this to
work. In QtWebChannel, we get the method return value wrapped in a
QVariant, so the QFuture is wrapped in a QVariant. From there, I
cannot extract the QFutureInterfaceBase in any way.

I *could* just memcpy from QVariant's data pointer to a
QFutureInterfaceBase*, but I'm pretty sure that this is UB.

Any pointer where to start?

Regards,
Arno

--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.r...@menlosystems.com<mailto:a.r...@menlosystems.com>
www.menlosystems.com<http://www.menlosystems.com>

Menlo Systems GmbH
Bunsenstrasse 5, D-82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QMetaType support for QFuture

[Sona Kurazyan]

Hi Konstantin,

QFuture has a constructor for QFuture from QFuture,  see 
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread/qfuture.h#n82, so 
you don’t even need to use the broken qToVoidFuture() method. I’ll probably 
remove it, since it was always broken and couldn’t be ever used.
I can see that in some special use-cases having access to QFuture’s internals 
might be useful, but this is not something we would recommend to do to all 
users. That’s why, I think, adding an API that gives access to QFuture’s d-ptr 
(as it was suggested earlier) might be an option.

Best regards,
Sona

From: Konstantin Ritt 
Sent: Saturday, May 8, 2021 2:29 AM
To: Arno Rehn 
Cc: Sona Kurazyan ; Qt development mailing list 

Subject: Re: [Development] QMetaType support for QFuture

I was implementing a similar feature few years ago and had the same problem 
with QFuture internals -- https://codereview.qt-project.org/c/qt/qtbase/+/210243
As there was no interest in making those better, I had to hack it in a way I 
won't promote here ;p
But since QFuture took a new life with QPromise, it becomes even more useful 
than before and deserves some improvements IMO.
Maybe we could add a public accessor to future's d via QFutureInterfaceBase? 
Will that be acceptable?

Regards,
Konstantin


пт, 7 мая 2021 г. в 19:28, Arno Rehn 
mailto:a.r...@menlosystems.com>>:
Hi Sona,

On 07.05.21 17:11, Sona Kurazyan wrote:
> You could use the QFutureInterfaceBase (non-templated) class directly
> to build a type-erased future, that's basically what QFuture is using
> underneath. Although it's internal (not documented and is considered
> to be private), but it's declared in a public header
> (qfutureinterface.h) and you can still use it. QFutureInterfaceBase's
> methods for accessing its internals are public (with a few exceptions
> that you probably won't need to use). I hope that helps.

Yep, that's what I thought as well. But I cannot get it from an existing
QFuture because it's a private member. We could add some private API to
extract the QFutureInterfaceBase, however.

Anyway, I think I'll have to add some QMetaType magic anyway for this to
work. In QtWebChannel, we get the method return value wrapped in a
QVariant, so the QFuture is wrapped in a QVariant. From there, I
cannot extract the QFutureInterfaceBase in any way.

I *could* just memcpy from QVariant's data pointer to a
QFutureInterfaceBase*, but I'm pretty sure that this is UB.

Any pointer where to start?

Regards,
Arno

--
Arno Rehn
Tel +49 89 189 166 0
Fax +49 89 189 166 111
a.r...@menlosystems.com<mailto:a.r...@menlosystems.com>
www.menlosystems.com<http://www.menlosystems.com>

Menlo Systems GmbH
Bunsenstrasse 5, D-82152 Martinsried, Germany
Amtsgericht München HRB 138145
Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
USt.-IdNr. DE217772017, St.-Nr. 14316170324
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QMetaType support for QFuture

[Sona Kurazyan]

I see the problem.
I guess adding an internal API in QtCore (likely in QtPrivate namespace), which 
is a friend to QFuture and gives access to its d-ptr is the only option then. 
At least I cannot think of a better way.

Best regards,
Sona

> -Original Message-
> From: Arno Rehn 
> Sent: Friday, May 7, 2021 6:28 PM
> To: Sona Kurazyan ; Qt development mailing list
> 
> Subject: Re: [Development] QMetaType support for QFuture
> 
> Hi Sona,
> 
> On 07.05.21 17:11, Sona Kurazyan wrote:
> > You could use the QFutureInterfaceBase (non-templated) class directly
> > to build a type-erased future, that's basically what QFuture is using
> > underneath. Although it's internal (not documented and is considered
> > to be private), but it's declared in a public header
> > (qfutureinterface.h) and you can still use it. QFutureInterfaceBase's
> > methods for accessing its internals are public (with a few exceptions
> > that you probably won't need to use). I hope that helps.
> 
> Yep, that's what I thought as well. But I cannot get it from an existing 
> QFuture
> because it's a private member. We could add some private API to extract the
> QFutureInterfaceBase, however.
> 
> Anyway, I think I'll have to add some QMetaType magic anyway for this to
> work. In QtWebChannel, we get the method return value wrapped in a
> QVariant, so the QFuture is wrapped in a QVariant. From there, I cannot
> extract the QFutureInterfaceBase in any way.
> 
> I *could* just memcpy from QVariant's data pointer to a
> QFutureInterfaceBase*, but I'm pretty sure that this is UB.
> 
> Any pointer where to start?
> 
> Regards,
> Arno
> 
> --
> Arno Rehn
> Tel +49 89 189 166 0
> Fax +49 89 189 166 111
> a.r...@menlosystems.com
> www.menlosystems.com
> 
> Menlo Systems GmbH
> Bunsenstrasse 5, D-82152 Martinsried, Germany Amtsgericht München HRB
> 138145
> Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr.
> DE217772017, St.-Nr. 14316170324
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QMetaType support for QFuture

[Sona Kurazyan]

Hi Arno, 

You could use the QFutureInterfaceBase (non-templated) class directly to build 
a type-erased future, that's basically what QFuture is using underneath. 
Although it's internal (not documented and is considered to be private), but 
it's declared in a public header (qfutureinterface.h) and you can still use it. 
QFutureInterfaceBase's methods for accessing its internals are public (with a 
few exceptions that you probably won't need to use). 
I hope that helps.

Best regards,
Sona

> -Original Message-
> From: Development  On Behalf Of
> Arno Rehn
> Sent: Friday, May 7, 2021 4:07 PM
> To: Qt development mailing list 
> Subject: [Development] QMetaType support for QFuture
> 
> Hey everyone,
> 
> I'm currently working on making QFuture return types work transparently in
> QtWebChannel. For remote clients, method return values are received
> asynchronously via callbacks anyway.
> 
> However, QFuture introspection is not supported by the meta-type (yet) and
> there's no other way to register a generic QVariant-based continuation for
> "any" QFuture. All implementation details are private or protected and only
> some friend classes have access.
> 
> I was wondering if I should add a local "workaround" to QWebChannel only
> (like QWebChannel::registerFutureType() to support QFuture) or
> if I should push something more general to QtCore. Maybe just some
> additional private API that supports the necessary private member access?
> 
> Looking forward to some feedback.
> 
> Regards,
> Arno
> 
> --
> Arno Rehn
> Tel +49 89 189 166 0
> Fax +49 89 189 166 111
> a.r...@menlosystems.com
> www.menlosystems.com
> 
> Menlo Systems GmbH
> Bunsenstrasse 5, D-82152 Martinsried, Germany Amtsgericht München HRB
> 138145
> Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr.
> DE217772017, St.-Nr. 14316170324
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Andreas Buhr as approver

[Sona Kurazyan]

+1!

From: Development  on behalf of Timur 
Pocheptsov 
Sent: Friday, April 30, 2021 2:24 PM
To: Topi Reiniö ; development 
Subject: Re: [Development] Nominating Andreas Buhr as approver

+1, yes.

Best regards,
Timur.

From: Development  on behalf of Topi Reiniö 

Sent: Thursday, April 29, 2021 11:26 AM
To: development 
Subject: Re: [Development] Nominating Andreas Buhr as approver

+1!

From: Development  on behalf of Paul 
Wicking 
Sent: Thursday, April 29, 2021 8:20 AM
To: development 
Subject: [Development] Nominating Andreas Buhr as approver

Hi all,


I’d like to nominate Andreas Buhr as approver for the Qt Project.

Andreas has been working with Qt since he joined the Qt Company as a full-time 
employee in Germany about a year ago. I believe his patches [0] spesk for 
themselves. He has also participated actively in reviewing others’ work [1]. My 
impression is that Andreas holds quality in high regard in production code, 
tests, and in documentation, and that he tirelessly works to further our 
quality in all these areas.

I trust he'll use the approver rights responsibly.

[0] - https://codereview.qt-project.org/q/owner:andreas.buhr%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:andreas.buhr%2540qt.io

//! Paul
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a module for Qt5 classes that won't be maintained in Qt6

[Sona Kurazyan]

Hi All,

I just wanted to remind everyone, that the Qt5Compat submodule is created and 
added to the list of submodules of qt5.git on dev branch. If you have something 
that you think should be moved there, you can create a task for it and already 
start moving it there.

Right now Qt5Compat has one module called "Core5Compat" for the stuff moved 
form Qt Core. For the rest of Qt 5 modules a similar naming can be used (e.g. 
Gui5Compat,Widgets5Compat, etc.).

To clone Qt5Compat, use:

  *   git://code.qt.io/qt/qt5compat.git or
  *   https://code.qt.io/qt/qt5compat.git

Best regards,
Sona

From: Development  On Behalf Of Sona 
Kurazyan
Sent: Friday, January 24, 2020 10:30 AM
To: development@qt-project.org
Subject: [Development] Requesting a module for Qt5 classes that won't be 
maintained in Qt6

Hi,

Previously there were discussions that we need to have a new module in Qt 6 for 
the Qt 5 classes that will be no longer maintained in Qt 6.

Here are some candidates to be moved there in Qt 6 (see 
https://bugreports.qt.io/browse/QTBUG-80312):

  *   QLinkedList
  *   QRegExp
  *   QStateMachine
  *   QStringRef
  *   QList
  *   QJsonDocument::fromBinaryData()
The list is not complete or final, feel free to suggest more items that you 
think will fit there.

So, I would like to request a new module and repository for this.

Name of the repository: qt/qt5compat.git
Description: The module contains unsupported Qt 5 APIs
Responsible person: Sona Kurazyan
Gerrit user/email: sona.kuraz...@qt.io<mailto:sona.kuraz...@qt.io>

Thanks,
Sona

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

It seems like everyone agrees that we need to keep and improve the asynchronous 
APIs in Qt 6.
Since there are already tasks for each of proposed changes, let’s move more 
detailed discussions about each item to the relevant task. They are all linked 
to https://bugreports.qt.io/browse/QTBUG-80908.
Feel free to make comments if you are interested.

Best regards,
Sona


From: Development  On Behalf Of Sona 
Kurazyan
Sent: Friday, 31 January 2020 17:24
To: development@qt-project.org
Subject: Re: [Development] Make a decision for asynchronous APIs

Hi everyone,

It's been a while since we've started discussions on this topic. I would like 
to summarize the outcome of these discussions and propose improvements to our 
asynchronous APIs based on the feedback we've received so far.

First of all, there was a question weather we should keep QtConcurrent and 
QFuture (and related classes) at all, and the answer seems to be "yes", because 
the corresponding STL alternatives are still lacking a lot of features: 
std::future still doesn't support continuations, its API is not finalized yet, 
no executors are supported for parallel algorithms in C++17, etc. Additionally, 
Qt's asynchronous APIs have extensions like cancelling, pausing, resuming and 
progress reporting (although not everyone agrees that these extensions fit with 
a typical future, but they can be useful in Qt-specific use-cases, for example 
GUI applications).

On the other hand, there are couple of improvements to be applied to 
QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. 
Here's the list of suggestions I've collected:

QFuture (and related classes)

  1.  Officially document QFutureInterface and rename it to QPromise 
(https://bugreports.qt.io/browse/QTBUG-81586)
  2.  Add support for continuations​ to QFuture 
(https://bugreports.qt.io/browse/QTBUG-81587)
  3.  Provide a way of integrating QFuture with signals 
(https://bugreports.qt.io/browse/QTBUG-81589)
  4.  Improve the error reporting of QFuture 
(https://bugreports.qt.io/browse/QTBUG-81588)

QtConcurrent

  1.  Rename QtConcurrent::run to qAsync() and modernize it 
(https://bugreports.qt.io/browse/QTBUG-81590)
  2.  Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to 
avoid exhausting all system threads.
  3.  Fix the algorithms which do not work with lambdas 
(https://bugreports.qt.io/browse/QTBUG-33735)
  4.  Add initial values to map/filter reduce 
(https://bugreports.qt.io/browse/QTBUG-73240)

It would be nice to hear some opinions, to see whether this is a right 
direction to go, and if it makes sense to put our effort on these improvements. 
Is there anything important I’m missing in the list? Or maybe some of these 
items do not add much value?

Additionally, there are some discussions about QFuture being a mix between a 
“Task” and a “Future”. One of the options of improving this situation is to 
make a QTask (or QJob) out of the current QFuture. But then the question is: 
should we also support a “classic” QFuture? Is there a value in having it, when 
there are already some very advanced implementations of a future?

Please share your thoughts!

Thanks,
Sona


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Karsten Heimrich 
mailto:karsten.heimr...@qt.io>>
Sent: Thursday, December 19, 2019 2:12 PM
To: development@qt-project.org<mailto:development@qt-project.org> 
mailto:development@qt-project.org>>
Subject: [Development] Make a decision for asynchronous APIs


Hi,

we are planning to continue some work on the QFuture, QtConcurrent APIs, either 
improve up on the existing implementation or deprecate and remove them 
completely for Qt6. We’ve created a user story in Jira and  like to gather some 
feedback here. So if this topic is of interest for you, I would like to point 
you to https://bugreports.qt.io/browse/QTBUG-80908 to place some comments there.



BR, Karsten


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Sona Kurazyan]

> Anyway, how are we on Qt 6.0 future-compat features? Are they in 5.15?
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products

I've started moving things (QLinkedList for now) to Qt5Compat in dev branch, 
5.15 is not affected.

Best regards,
Sona
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

Sorry, that was a typo, I should have written “resumability” , i.e. 
pause/resume.


Can you also elaborate what do you mean by «reusability»? Ability to do 
something like future.restart(); ?


1 февр. 2020 г., в 14:44, Sona Kurazyan 
mailto:sona.kuraz...@qt.io>> написал(а):

In my understanding a future represents a single result of a computation which 
will be available sometime in future, it doesn’t assume reusability, progress 
reporting, etc. If you take a look to other implementations of a future (like 
boost::future, folly::future or std::experimental::future), none of them has 
this “extra” functionality similar to QFuture, none of them represents a set of 
results as QFuture does. This may be confusing for people who are expecting 
QFuture to be a typical future they are used to, and I actually saw some 
complains about that.

Best regards,
Sona


From: Иван Комиссаров mailto:abba...@gmail.com>>
Sent: Saturday, February 1, 2020 1:56 PM
To: Sona Kurazyan mailto:sona.kuraz...@qt.io>>
Cc: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Make a decision for asynchronous APIs

Can you please elaborate the difference?



31 янв. 2020 г., в 17:24, Sona Kurazyan 
mailto:sona.kuraz...@qt.io>> написал(а):

Additionally, there are some discussions about QFuture being a mix between a 
“Task” and a “Future”. One of the options of improving this situation is to 
make a QTask (or QJob) out of the current QFuture. But then the question is: 
should we also support a “classic” QFuture? Is there a value in having it, when 
there are already some very advanced implementations of a future?

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

> -Original Message-
> From: Elvis Stansvik 
> Sent: Friday, January 31, 2020 7:20 PM
> To: Sona Kurazyan 
> Cc: development@qt-project.org
> Subject: Re: [Development] Make a decision for asynchronous APIs
> 
> >
> > Additionally, there are some discussions about QFuture being a mix
> between a “Task” and a “Future”. One of the options of improving this
> situation is to make a QTask (or QJob) out of the current QFuture. But then
> the question is: should we also support a “classic” QFuture? Is there a value
> in having it, when there are already some very advanced implementations of
> a future?
> 
> I don't have too much to comment on this. Would the alternative to QFuture
> in this scenario be a future class from somewhere else (std::future, ...)? And
> the Qt goodies like cancel/pause/resume/progress API would be on QTask?

Yes, that would be my preference as well. 

Best regards,
Sona
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

In my understanding a future represents a single result of a computation which 
will be available sometime in future, it doesn’t assume reusability, progress 
reporting, etc. If you take a look to other implementations of a future (like 
boost::future, folly::future or std::experimental::future), none of them has 
this “extra” functionality similar to QFuture, none of them represents a set of 
results as QFuture does. This may be confusing for people who are expecting 
QFuture to be a typical future they are used to, and I actually saw some 
complains about that.

Best regards,
Sona


From: Иван Комиссаров 
Sent: Saturday, February 1, 2020 1:56 PM
To: Sona Kurazyan 
Cc: development@qt-project.org
Subject: Re: [Development] Make a decision for asynchronous APIs

Can you please elaborate the difference?


31 янв. 2020 г., в 17:24, Sona Kurazyan 
mailto:sona.kuraz...@qt.io>> написал(а):

Additionally, there are some discussions about QFuture being a mix between a 
“Task” and a “Future”. One of the options of improving this situation is to 
make a QTask (or QJob) out of the current QFuture. But then the question is: 
should we also support a “classic” QFuture? Is there a value in having it, when 
there are already some very advanced implementations of a future?


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

So what you are suggesting, is basically the current QFuture (combined with 
QFutureWtacher), but with "trimmed" runtime controls?
And if we do that, we also need to have QTask for the cases where the runtime 
controls are needed (for example QtConcurrent, qtcreator). 

Best regards,
Sona

> -Original Message-
> From: Allan Sandfeld Jensen 
> Sent: Friday, January 31, 2020 7:40 PM
> To: development@qt-project.org
> Cc: Sona Kurazyan 
> Subject: Re: [Development] Make a decision for asynchronous APIs
> 
> On Freitag, 31. Januar 2020 17:24:20 CET Sona Kurazyan wrote:
> > Additionally, there are some discussions about QFuture being a mix
> > between a “Task” and a “Future”. One of the options of improving this
> > situation is to make a QTask (or QJob) out of the current QFuture. But
> > then the question
> > is: should we also support a “classic” QFuture? Is there a value in
> > having it, when there are already some very advanced implementations of
> a future?
> >
> As I have expressed earlier I would love the simplified QFuture, just a
> something that can hold the result of an async function, but no runtime
> controls. Just ways to test if the result is ready and to be notified when it 
> is,
> like with a waitForResult blocking method and a signal emitter of some kind.
> 
> I think there are many cases where such an API would be useful.
> 
> Best regards
> 'Allan
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Sona Kurazyan]

Hi everyone,

It's been a while since we've started discussions on this topic. I would like 
to summarize the outcome of these discussions and propose improvements to our 
asynchronous APIs based on the feedback we've received so far.

First of all, there was a question weather we should keep QtConcurrent and 
QFuture (and related classes) at all, and the answer seems to be "yes", because 
the corresponding STL alternatives are still lacking a lot of features: 
std::future still doesn't support continuations, its API is not finalized yet, 
no executors are supported for parallel algorithms in C++17, etc. Additionally, 
Qt's asynchronous APIs have extensions like cancelling, pausing, resuming and 
progress reporting (although not everyone agrees that these extensions fit with 
a typical future, but they can be useful in Qt-specific use-cases, for example 
GUI applications).

On the other hand, there are couple of improvements to be applied to 
QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. 
Here's the list of suggestions I've collected:

QFuture (and related classes)

  1.  Officially document QFutureInterface and rename it to QPromise 
(https://bugreports.qt.io/browse/QTBUG-81586)
  2.  Add support for continuations​ to QFuture 
(https://bugreports.qt.io/browse/QTBUG-81587)
  3.  Provide a way of integrating QFuture with signals 
(https://bugreports.qt.io/browse/QTBUG-81589)
  4.  Improve the error reporting of QFuture 
(https://bugreports.qt.io/browse/QTBUG-81588)

QtConcurrent

  1.  Rename QtConcurrent::run to qAsync() and modernize it 
(https://bugreports.qt.io/browse/QTBUG-81590)
  2.  Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to 
avoid exhausting all system threads.
  3.  Fix the algorithms which do not work with lambdas 
(https://bugreports.qt.io/browse/QTBUG-33735)
  4.  Add initial values to map/filter reduce 
(https://bugreports.qt.io/browse/QTBUG-73240)

It would be nice to hear some opinions, to see whether this is a right 
direction to go, and if it makes sense to put our effort on these improvements. 
Is there anything important I’m missing in the list? Or maybe some of these 
items do not add much value?

Additionally, there are some discussions about QFuture being a mix between a 
“Task” and a “Future”. One of the options of improving this situation is to 
make a QTask (or QJob) out of the current QFuture. But then the question is: 
should we also support a “classic” QFuture? Is there a value in having it, when 
there are already some very advanced implementations of a future?

Please share your thoughts!

Thanks,
Sona


From: Development  on behalf of Karsten 
Heimrich 
Sent: Thursday, December 19, 2019 2:12 PM
To: development@qt-project.org 
Subject: [Development] Make a decision for asynchronous APIs


Hi,

we are planning to continue some work on the QFuture, QtConcurrent APIs, either 
improve up on the existing implementation or deprecate and remove them 
completely for Qt6. We’ve created a user story in Jira and  like to gather some 
feedback here. So if this topic is of interest for you, I would like to point 
you to https://bugreports.qt.io/browse/QTBUG-80908 to place some comments there.



BR, Karsten


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a module for Qt5 classes that won't be maintained in Qt6

[Sona Kurazyan]

Hi,

Kevin Kofler wrote:
> Can we have the XML SAX API in that module too? AIUI, Qt 6 will only include
> the XML stream API and the XML DOM API (the latter being ported from SAX
> to streams as the underlying implementation).

That's right, in Qt 6 we won't use the SAX APIs internally anymore. As far as I 
know, the plan was to remove them in Qt 6, since QXmlStreamReader is a better 
alternative. But if you really need the SAX APIs, I would suggest to create a 
ticket, maybe we can consider keeping them if there's enough interest.

Best regards,
Sona
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a module for Qt5 classes that won't be maintained in Qt6

[Sona Kurazyan]

Are you a Maintainer [QUIP 2] ?
Do we require a module's responsible person to be a Maintainer ?
If yes to the former or no to the latter, I'm fine with the proposed details.
I'm not sure about the maintainer part. At least here 
https://wiki.qt.io/Requesting_New_Repositories is mentioned "Responsible 
persons" (plural), so one can be a responsible person, without being a 
maintainer. Probably a lot of other people will be moving stuff there, and I 
was assuming they will also become "responsible persons". I've putted my name 
there more as a placeholder, because I'm the one who is requesting.

Best regards,
Sona


From: Edward Welbourne 
Sent: Friday, January 24, 2020 4:32 PM
To: Sona Kurazyan 
Cc: development@qt-project.org 
Subject: Re: [Development] Requesting a module for Qt5 classes that won't be 
maintained in Qt6

Sona Kurazyan (24 January 2020 10:29)
> Previously there were discussions that we need to have a new module in Qt 6 
> for the Qt 5 classes that will be no longer maintained in Qt 6.
>
> Here are some candidates to be moved there in Qt 6 (see 
> https://bugreports.qt.io/browse/QTBUG-80312):
>
>  *   QLinkedList
>  *   QRegExp
>  *   QStateMachine
>  *   QStringRef
>  *   QList
>  *   QJsonDocument::fromBinaryData()
>
> The list is not complete or final, feel free to suggest more items that you 
> think will fit there.
>
> So, I would like to request a new module and repository for this.

+1 for the repository.

> Name of the repository: qt/qt5compat.git
> Description: The module contains unsupported Qt 5 APIs
> Responsible person: Sona Kurazyan
> Gerrit user/email: sona.kuraz...@qt.io

Are you a Maintainer [QUIP 2] ?
Do we require a module's responsible person to be a Maintainer ?
If yes to the former or no to the latter, I'm fine with the proposed details.

[QUIP 2] http://quips-qt-io.herokuapp.com/quip-0002.html#maintainers

(Full disclosure: I'm in the same scrum team as Sona;
and I'm not a Maintainer.)

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Requesting a module for Qt5 classes that won't be maintained in Qt6

[Sona Kurazyan]

Hi,

Previously there were discussions that we need to have a new module in Qt 6 for 
the Qt 5 classes that will be no longer maintained in Qt 6.

Here are some candidates to be moved there in Qt 6 (see 
https://bugreports.qt.io/browse/QTBUG-80312):

  *   QLinkedList
  *   QRegExp
  *   QStateMachine
  *   QStringRef
  *   QList
  *   QJsonDocument::fromBinaryData()

The list is not complete or final, feel free to suggest more items that you 
think will fit there.

So, I would like to request a new module and repository for this.

Name of the repository: qt/qt5compat.git
Description: The module contains unsupported Qt 5 APIs
Responsible person: Sona Kurazyan
Gerrit user/email: sona.kuraz...@qt.io

Thanks,
Sona

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] HEADS-UP: Deprecating SAX classes in Qt XML

[Sona Kurazyan]

I'd like to inform everyone that the SAX classes for reading and writing XML 
files are about to be deprecated in Qt 5.15, and 
QXmlStreamReader/QXmlStreamWriter should be used instead.

As a consequence QDomDocument has been re-implemented using QXmlStreamReader, 
and Qt 6 will switch to the new implementation as soon as 
this change propagates 
to dev (5.15 will still use the old implementation).

Please note that the old SAX-based implementation was not following the XML 
spec very strictly, whereas the new implementation does. Because of that after 
switching to the new QXmlStreamReader-based implementation in Qt 6, there will 
be slight changes of QDomDocument behavior. In particular:

- Attribute values will be normalized. 
For example  will be equivalent to 
- Identical qualified attribute names won't be 
allowed anymore, i.e. attributes of an 
element must have unique names.
- Undeclared namespace prefixes won't be 
allowed anymore.

If you are relying on any of these, please consider updating your code/xml 
files accordingly.

Best regards,
Sona
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development