Re: [Development] QtCS2019 Notes: QtCore
On Friday, 22 November 2019 20:01:30 CET Giuseppe D'Angelo via Development wrote: > Il 22/11/19 18:49, Thiago Macieira ha scritto: > > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment > > where you can't use qsizetype in Qt 6. We'll deal with conflicts. > > Sorry, what do you mean by "conflicts"? I mean that there's countless > code today that uses "int s = foo.size()" (or indexOf, or similar); such > code will now trigger narrowing warnings. Fix it in Qt 6. If you write new code in Qt 5 that you know will cause Qt 6 warnings, leave the ### comment so that you or someone else can fix it for that branch after it merges. > > There's always QVector::size_type, QByteArray::size_type and > > QString::size_type if you really need to be explicit and that's fine > > today. > > The chance that non-generic code uses this is practically 0 and we know > it. Yes, "auto" will work, but still has anyone actually did the > exercise on a big codebase (Creator, KDE, ...) and checked how many > warnings are we talking about? No, no one has checked how many warnings it'll produce. I don't see how that's relevant though: we will change the size types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate
Am 22.11.19 um 17:03 schrieb Kai Köhne:
From: Development On Behalf Of
Joerg Bornemann
On 11/22/19 7:21 AM, Kai Pastor, DG0YT wrote:
Given the Qt Creator example, would it be feasible to make explicit
declaration of a file's context mandatory, at least for the existing
("fast") parser? If not mandatory, an explicit declaration could at
least disable all automatic detection for the rest of the file, making
it possible to use modern C++ without surprises.
That's certainly a possibility. With an explicit context declaration (that's
easy
to detect) on file level we can use an even simpler parser/extractor that
doesn't have to know much C++ at all.
Keep in mind that you need this context available both at runtime and
at lupdate time. That is, the only setup how this IMO would reliably work
is if we make the context a part of the tr() call - effectively calling
QCoreApplication::translate(context, string). This is already possible right
now.
I admit I didn't think about the runtime perspective. But
QCoreApplication::translate("Context", string)
is much more verbose then
Context::tr(string)
or, with a declared and defined Context for the translation unit, just
tr(string)
I wonder if an anonymous namespace couldn't be used to safely implement
the latter for the proposed explicit declaration per translation unit.
Kai.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
Il 22/11/19 18:49, Thiago Macieira ha scritto: We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment where you can't use qsizetype in Qt 6. We'll deal with conflicts. Sorry, what do you mean by "conflicts"? I mean that there's countless code today that uses "int s = foo.size()" (or indexOf, or similar); such code will now trigger narrowing warnings. There's always QVector::size_type, QByteArray::size_type and QString::size_type if you really need to be explicit and that's fine today. The chance that non-generic code uses this is practically 0 and we know it. Yes, "auto" will work, but still has anyone actually did the exercise on a big codebase (Creator, KDE, ...) and checked how many warnings are we talking about? Thanks, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS19 Notes: Qt 6 Network Overview
Am 22.11.2019 um 15:18 schrieb Timur Pocheptsov: Before moving to QtNetwork it needs to be significantly refactored Can we maybe create a sub-task for this to elaborate what's meant with 'significantly refactored'? Thx, Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from the Qt 6 Changes / Migration session
On Fri, Nov 22, 2019 at 03:01:25PM +0100, Uwe Rathmann wrote: > On 11/22/19 11:01 AM, Friedemann Kleint wrote: > > > https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration > > Maybe one aspect I would like to add: there is a lot of software, that has > to be compilable with Qt 5 and Qt 6. Especially when your product is library > you can't decide which version of Qt is going to be used in the application. > > It would be good if this does not end up in a total mess of ifdefs. Since Qt Creator intents to stay compilable "for a while" with probably 5.14 (extrapolating from the usual "latest LTS minus one minor", or in this special situation possibly 5.15) and 6.0 I guess there will be some noise if this starts requiring _a lot_ of #ifdefs. Right now the situation is that Qt dev (a.k.a. Qt 6 in spe) "works" with a Creator codebase that's not far from being 5.11 compatible. This has required quite some work already to port away from "near death" constructs (there are few helper functions toSet/toList, and there's a handful of unavoidable #ifdefs due to the collapsing of QList and QVector, some changes around the Qt namespace, QDataStream, etc) but overall I am fairly optmistic that the envisioned scenario that porting a codebase piece-by-piece to 5.15 that's then 6.0 compatible is somewhat realistic. > My experience from the past is, that it takes years until the majority of > the applications has upgraded to the next major Qt version - and probably > only few applications will seriously try out Qt x.0 versions. That matches my experience from the past. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session
On Fri, Nov 22, 2019 at 04:19:21PM +, Kai Koehne wrote: Anyhow, QCommandLineParser processes command line arguments from the outside. These command line arguments might come from other tools, output ... so it should be really robust in handling these. "from the outside" is not the qualifier - "untrusted" is. and any application that passes on untrusted (not pre-validated) input to another one is beyond hope. QTranslator: The API is unfortunate in that the default directory were translations are looked up is QDir::currentPath()... uhm, that requires a more fundamental fix then - you certainly can see how displaying arbitrary messages might be a security risk in itself, irrespective of whether the .qm reader is safe or not. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session
Il 21/11/19 13:13, Robert Loehning ha scritto: >> ** [https://doc.qt.io/qt-5/qregularexpression.html QRegularExpression] Giuseppe D'Angelo (22 November 2019 18:17) replied: > This should mostly be fuzzing libpcre itself... ... which Google is probably already doing. > Note that users should NEVER use / accept untrusted regular expressions. > While we shouldn't crash or exhaust memory, PCREs will happily exhibit > exponential backtracking behaviour, thus exposing applications to DOS > attacks. There's nothing we can do about that. ... and filtering out the halting problem isn't even amenable to any dumb heuristics (like the for/while/... crippling of the JS evaluator fuzzer). Probably best to concentrate our efforts elsewhere ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On Friday, 22 November 2019 18:04:22 CET Giuseppe D'Angelo via Development wrote: > So the mandatory question is: how many warnings is this going to cause, > and how to port code whilst maintaining Qt 5 compatibility? We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment where you can't use qsizetype in Qt 6. We'll deal with conflicts. There's always QVector::size_type, QByteArray::size_type and QString::size_type if you really need to be explicit and that's fine today. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hello Giuseppe,
>> qmlRegisterSingletonInstance("Utils", 3, 14, "Obj", obj);
>In 5.14 the solution is something along the lines of
Exactly what I was looking for.
>In pre-5.14 the same is achieved by using qmlRegisterSingletonType with
>a callback (that returns the object + sets the ownership of the object
>to C++; definitely not as convenient). Usage from QML is identical.
I was using context properties and were not that in-depth with the singletons.
I did read the great Qt documentation on them, maybe I have missed that.
Thanks for pointing it out.
On Fri, Nov 22, 2019 at 7:14 PM Giuseppe D'Angelo via Development
wrote:
>
> Il 22/11/19 16:49, Damian Ivanov ha scritto:
> > I don't see this anywhere documented how this could be done using a
> > singleton.
>
> In 5.14 the solution is something along the lines of
>
> > qmlRegisterSingletonInstance("Utils", 3, 14, "Obj", obj);
>
> then in QML
>
> > import Utils 3.14
> > // use "Obj" instead of "obj"
>
> In pre-5.14 the same is achieved by using qmlRegisterSingletonType with
> a callback (that returns the object + sets the ownership of the object
> to C++; definitely not as convenient). Usage from QML is identical.
>
>
> > If I register it as singleton the application_engine doesn't find it
> > findChild->
>
> Could you please elaborate on this point?
>
>
> Thanks,
> --
> 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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session
Il 21/11/19 13:13, Robert Loehning ha scritto: ** [https://doc.qt.io/qt-5/qregularexpression.html QRegularExpression] This should mostly be fuzzing libpcre itself... Note that users should NEVER use / accept untrusted regular expressions. While we shouldn't crash or exhaust memory, PCREs will happily exhibit exponential backtracking behaviour, thus exposing applications to DOS attacks. There's nothing we can do about that. Thanks, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Il 22/11/19 16:49, Damian Ivanov ha scritto:
I don't see this anywhere documented how this could be done using a singleton.
In 5.14 the solution is something along the lines of
qmlRegisterSingletonInstance("Utils", 3, 14, "Obj", obj);
then in QML
import Utils 3.14
// use "Obj" instead of "obj"
In pre-5.14 the same is achieved by using qmlRegisterSingletonType with
a callback (that returns the object + sets the ownership of the object
to C++; definitely not as convenient). Usage from QML is identical.
If I register it as singleton the application_engine doesn't find it
findChild->
Could you please elaborate on this point?
Thanks,
--
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
smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Additionally
https://forum.qt.io/topic/54353/solved-access-qml-singleton-object-from-c-code/4
seems also like a viable solution
though a syntax where qmlRegisterSingletonType return value is a
QObject would be very ease to read / write.
On Fri, Nov 22, 2019 at 6:33 PM Damian Ivanov wrote:
>
> Hi Dmitriy,
>
> Well I can't seem to find an easy example but an easy example:
> Instantiating a .qml with QQmlComponent::create which is of Window (I
> do this for others as well) type
> from c++ than I set obj->properties from c++ based on various events.
> Creating a singleton class seems like adding 30 lines of code per
> object in contrast to setContextProperty()
> Something like this would be nice if possible:
> QQmlComponent* m_component = new
> QQmlComponent(application_engine, "qrc:/Component.qml");
> QObject* m_obj ;
> qmlRegisterSingletonType("Component", 1, 0, "Identifier",
> [=]
> {
> m_obj = m_component->create();
> return m_obj;
> });
>
> On Fri, Nov 22, 2019 at 6:22 PM Dmitriy Purgin wrote:
> >
> > Hi Damian,
> >
> > that seems to be an interesting case. Could you provide an example of why
> > would you need such a pattern?
> >
> > Why the other way round -- creating a C++ singleton and exposing it to QML
> > -- doesn't work for you? That should be easier and more transparent.
> >
> > Cheers
> > Dmitriy
> >
> > On Fri, Nov 22, 2019 at 4:50 PM Damian Ivanov
> > wrote:
> >>
> >> How would .qml files that are singletons and instantiated from c++ be used
> >> currently I do this and am able to access it from qml and c++
> >> QQmlComponent* component = new QQmlComponent(application_engine,
> >> "qrc:/Component.qml");
> >> QObject* obj = component->create();
> >> obj->setParent(this);
> >> application_engine->rootContext()->setContextProperty("obj", obj);
> >>
> >> I don't see this anywhere documented how this could be done using a
> >> singleton.
> >> If I register it as singleton the application_engine doesn't find it
> >> findChild->
> >> Using component->create would create it again since it is already
> >> registered as a singleton.
> >>
> >> Any suggestions?
> >>
> >>
> >> ;
> >>
> >> On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > > these are the notes on the QtQml session:
> >> >
> >> > > Versioning
> >> > > --
> >> > >
> >> > > Once we get rid of unqualified lookups we don't need any QML
> >> > versioning
> >> > > anymore. At least the minor version will become optional already in
> >> > 5.15
> >> > > for well-behaved QML documents. In QML 3 it won't be allowed.
> >> >
> >> > While I agree with this overall, there's still one caveat which I
> >> > haven't seen discussed yet:
> >> >
> >> > Imagine I have the following code:
> >> >
> >> > Item {
> >> > id: foo
> >> > property color prettyColor: "#f0f"
> >> >
> >> > Rectangle {
> >> > color: foo.prettyColor
> >> > }
> >> > }
> >> >
> >> > Right now "foo" refers to the Item. What if in a future update,
> >> > Rectangle gains a new property "foo". Unless you want to force everyone
> >> > to be explicit by using "this" (e.g. width: this.height) everywhere,
> >> > which would be annoying, I don't see how this can be made future-proof
> >> > without some form of versioning or some other magic solution?
> >> >
> >> > Cheers
> >> > Kai Uwe
> >> > ___
> >> > 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
Il 22/11/19 18:00, Thiago Macieira ha scritto: We didn't discuss because it's a given that we will do that. :-) So the mandatory question is: how many warnings is this going to cause, and how to port code whilst maintaining Qt 5 compatibility? Thanks, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On Friday, 22 November 2019 16:43:16 CET Giuseppe D'Angelo via Development wrote: > Spawning a subthread since we didn't discuss this at all... > > Are the plans still to make the containers' size_type qsizetype? We didn't discuss because it's a given that we will do that. :-) Lars's patchset already includes such a change, for QVector at least: https://codereview.qt-project.org/c/qt/qtbase/+/281597/6 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi Dmitriy,
Well I can't seem to find an easy example but an easy example:
Instantiating a .qml with QQmlComponent::create which is of Window (I
do this for others as well) type
from c++ than I set obj->properties from c++ based on various events.
Creating a singleton class seems like adding 30 lines of code per
object in contrast to setContextProperty()
Something like this would be nice if possible:
QQmlComponent* m_component = new
QQmlComponent(application_engine, "qrc:/Component.qml");
QObject* m_obj ;
qmlRegisterSingletonType("Component", 1, 0, "Identifier", [=]
{
m_obj = m_component->create();
return m_obj;
});
On Fri, Nov 22, 2019 at 6:22 PM Dmitriy Purgin wrote:
>
> Hi Damian,
>
> that seems to be an interesting case. Could you provide an example of why
> would you need such a pattern?
>
> Why the other way round -- creating a C++ singleton and exposing it to QML --
> doesn't work for you? That should be easier and more transparent.
>
> Cheers
> Dmitriy
>
> On Fri, Nov 22, 2019 at 4:50 PM Damian Ivanov wrote:
>>
>> How would .qml files that are singletons and instantiated from c++ be used
>> currently I do this and am able to access it from qml and c++
>> QQmlComponent* component = new QQmlComponent(application_engine,
>> "qrc:/Component.qml");
>> QObject* obj = component->create();
>> obj->setParent(this);
>> application_engine->rootContext()->setContextProperty("obj", obj);
>>
>> I don't see this anywhere documented how this could be done using a
>> singleton.
>> If I register it as singleton the application_engine doesn't find it
>> findChild->
>> Using component->create would create it again since it is already
>> registered as a singleton.
>>
>> Any suggestions?
>>
>>
>> ;
>>
>> On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik
>> wrote:
>> >
>> > Hi,
>> >
>> > > these are the notes on the QtQml session:
>> >
>> > > Versioning
>> > > --
>> > >
>> > > Once we get rid of unqualified lookups we don't need any QML versioning
>> > > anymore. At least the minor version will become optional already in 5.15
>> > > for well-behaved QML documents. In QML 3 it won't be allowed.
>> >
>> > While I agree with this overall, there's still one caveat which I
>> > haven't seen discussed yet:
>> >
>> > Imagine I have the following code:
>> >
>> > Item {
>> > id: foo
>> > property color prettyColor: "#f0f"
>> >
>> > Rectangle {
>> > color: foo.prettyColor
>> > }
>> > }
>> >
>> > Right now "foo" refers to the Item. What if in a future update,
>> > Rectangle gains a new property "foo". Unless you want to force everyone
>> > to be explicit by using "this" (e.g. width: this.height) everywhere,
>> > which would be annoying, I don't see how this can be made future-proof
>> > without some form of versioning or some other magic solution?
>> >
>> > Cheers
>> > Kai Uwe
>> > ___
>> > 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi Damian,
that seems to be an interesting case. Could you provide an example of why
would you need such a pattern?
Why the other way round -- creating a C++ singleton and exposing it to QML
-- doesn't work for you? That should be easier and more transparent.
Cheers
Dmitriy
On Fri, Nov 22, 2019 at 4:50 PM Damian Ivanov
wrote:
> How would .qml files that are singletons and instantiated from c++ be used
> currently I do this and am able to access it from qml and c++
> QQmlComponent* component = new QQmlComponent(application_engine,
> "qrc:/Component.qml");
> QObject* obj = component->create();
> obj->setParent(this);
> application_engine->rootContext()->setContextProperty("obj", obj);
>
> I don't see this anywhere documented how this could be done using a
> singleton.
> If I register it as singleton the application_engine doesn't find it
> findChild->
> Using component->create would create it again since it is already
> registered as a singleton.
>
> Any suggestions?
>
>
> ;
>
> On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik
> wrote:
> >
> > Hi,
> >
> > > these are the notes on the QtQml session:
> >
> > > Versioning
> > > --
> > >
> > > Once we get rid of unqualified lookups we don't need any QML
> versioning
> > > anymore. At least the minor version will become optional already in
> 5.15
> > > for well-behaved QML documents. In QML 3 it won't be allowed.
> >
> > While I agree with this overall, there's still one caveat which I
> > haven't seen discussed yet:
> >
> > Imagine I have the following code:
> >
> > Item {
> > id: foo
> > property color prettyColor: "#f0f"
> >
> > Rectangle {
> > color: foo.prettyColor
> > }
> > }
> >
> > Right now "foo" refers to the Item. What if in a future update,
> > Rectangle gains a new property "foo". Unless you want to force everyone
> > to be explicit by using "this" (e.g. width: this.height) everywhere,
> > which would be annoying, I don't see how this can be made future-proof
> > without some form of versioning or some other magic solution?
> >
> > Cheers
> > Kai Uwe
> > ___
> > 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session
> -Original Message- > From: Development On Behalf Of > Oswald Buddenhagen > Sent: Thursday, November 21, 2019 2:41 PM > To: development@qt-project.org > Subject: Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session > > On Thu, Nov 21, 2019 at 12:13:55PM +, Robert Loehning wrote: > >=== Which code needs fuzz testing the most? === Agreed criteria: Code > >that operates on possibly untrusted data > > > >Proposals from the audience: > >* Classes > >** [https://doc.qt.io/qt-5/qcommandlineparser.html QCommandLineParser] > >** [https://doc.qt.io/qt-5/qtranslator.html QTranslator] > > > how do these make any sense here? We were just brainstorming there. Anyhow, QCommandLineParser processes command line arguments from the outside. These command line arguments might come from other tools, output ... so it should be really robust in handling these. QTranslator: The API is unfortunate in that the default directory were translations are looked up is QDir::currentPath()... Regards Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate
> -Original Message-
> From: Development On Behalf Of
> Joerg Bornemann
> Sent: Friday, November 22, 2019 1:25 PM
> To: Kai Pastor, DG0YT ; development@qt-project.org
> Subject: Re: [Development] QtCS2019 Notes: Clang-based cpp parser for
> lupdate
>
> On 11/22/19 7:21 AM, Kai Pastor, DG0YT wrote:
> > Am 21.11.19 um 20:23 schrieb André Pönitz:
> >> On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
> >>> a more radical and much simpler approach would be switching to
> >>> gettext
> >> The most prominent difference is the (usually) per-class automatic
> >> context which I always found too clever to be sensible, and that's
> >> effectively also the only reason to need a C++ parser.
> >
> > Indeed, while 'context' is a useful concept, the (implementation)
> > class name often isn't the best 'context' from a more general point of
> > view (features, human translators, screenshots). And if a class does
> > not inherit from QObject, the context already needs to be declared
> explicitly.
> >
> > Given the Qt Creator example, would it be feasible to make explicit
> > declaration of a file's context mandatory, at least for the existing
> > ("fast") parser? If not mandatory, an explicit declaration could at
> > least disable all automatic detection for the rest of the file, making
> > it possible to use modern C++ without surprises.
> >
> > Maybe this could be complemented by a lconvert feature to rename a
> > context in an existing ts-file, for those who want to move away from
> > class names as contexts.
>
> That's certainly a possibility. With an explicit context declaration (that's
> easy
> to detect) on file level we can use an even simpler parser/extractor that
> doesn't have to know much C++ at all.
Keep in mind that you need this context available both at runtime and
at lupdate time. That is, the only setup how this IMO would reliably work
is if we make the context a part of the tr() call - effectively calling
QCoreApplication::translate(context, string). This is already possible right
now.
> On the topic of switching to gettext:
>
> It would be cool to know where this was discussed before. My searches
> yielded nothing.
I remember having a meeting about that in the Trolltech office 2008,
weren't you there? 😉
> It's tempting to switch to an established solution.
> Of course we must make sure that gettext is properly supported on all target
> platforms. It seems to be available via vcpkg on Windows at least.
>
> There needs to be a migration path if we want to use gettext as the
> recommended i18n solution for Qt users (and maybe deprecate the
> lupdate/lrelease). We could provide a migration tool, based on lupdate's
> current parser, that transforms tr("foo") calls to _("foo"). Of course, that
> gets
> more complicated due to the mentioned context differences.
> And Linguist should probably be able to edit .po files.
Well, if people want to use gettext they can already do so now. But switching
to
gettext is a source incompatible change, so even with 'porting' tooling I don't
think
we can remove lupdate / tr() any time soon.
Regards
kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Session notes for "Code Review: Sharing the load" and follow-up session
Andre Hartmann (20 November 2019 13:30) wrote: > I have two additions: > > * Reactivate the QDoc bot to sanity check the docs > * Improve the output of sanity bot, especially for new users: > https://bugreports.qt.io/browse/QTQAINFRA-1478 Added: Nils's write-up has now become https://wiki.qt.io/Code_Review:_Sharing_the_load I have added it - and all the other session write-ups I could find - to Category: QtCS2019 Note, for anyone adding or aware of more such pages: just add [[Category:QtCS2019]] anywhere in the page (I usually make it the first line) to add a page to this category. Using Wiki pages to relevant categories makes them easier to find ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
How would .qml files that are singletons and instantiated from c++ be used
currently I do this and am able to access it from qml and c++
QQmlComponent* component = new QQmlComponent(application_engine,
"qrc:/Component.qml");
QObject* obj = component->create();
obj->setParent(this);
application_engine->rootContext()->setContextProperty("obj", obj);
I don't see this anywhere documented how this could be done using a singleton.
If I register it as singleton the application_engine doesn't find it
findChild->
Using component->create would create it again since it is already
registered as a singleton.
Any suggestions?
;
On Fri, Nov 22, 2019 at 12:53 PM Kai Uwe Broulik wrote:
>
> Hi,
>
> > these are the notes on the QtQml session:
>
> > Versioning
> > --
> >
> > Once we get rid of unqualified lookups we don't need any QML versioning
> > anymore. At least the minor version will become optional already in 5.15
> > for well-behaved QML documents. In QML 3 it won't be allowed.
>
> While I agree with this overall, there's still one caveat which I
> haven't seen discussed yet:
>
> Imagine I have the following code:
>
> Item {
> id: foo
> property color prettyColor: "#f0f"
>
> Rectangle {
> color: foo.prettyColor
> }
> }
>
> Right now "foo" refers to the Item. What if in a future update,
> Rectangle gains a new property "foo". Unless you want to force everyone
> to be explicit by using "this" (e.g. width: this.height) everywhere,
> which would be annoying, I don't see how this can be made future-proof
> without some form of versioning or some other magic solution?
>
> Cheers
> Kai Uwe
> ___
> 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] QtCS2019 Notes: QtCore
Il 21/11/19 19:48, Giuseppe D'Angelo via Development ha scritto: Written here: https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtCore Spawning a subthread since we didn't discuss this at all... Are the plans still to make the containers' size_type qsizetype? Thanks, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Session notes for "Code Review: Sharing the load" and follow-up session
> these are my notes for "Code Review: Sharing the load" session, extended > by "Improve the contributor experience of the Qt project" Thanks for that - duly wikified at https://wiki.qt.io/Code_Review:_Sharing_the_load Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS19 Notes: Qt 6 Network Overview
I'll update wiki using this on Monday, thanks. Best regards, Timur. From: Development on behalf of Maurice Kalinowski Sent: Thursday, November 21, 2019 8:52 AM To: development@qt-project.org Subject: [Development] QtCS19 Notes: Qt 6 Network Overview Hi, Following the notes taken on the Networking session: - What to do in Networking for Qt 6 ○ https://bugreports.qt.io/browse/QTBUG-75638 is the parent item to track - Get rid of stale backend ○ OpenSSL 1.1 and following supported ○ SSL2/3 - Additional TLS ○ mbedTLS contribution exists, will get it in but requires work - QNetworkAccessmanager ○ Default policies - Removing bearer management ○ There has been complaints about it ○ Radio interfaces as bearer are not best option ○ Legacy from S60 ○ Let's just get rid of it and move on ○ Webkit used bearer management to just identify whether you're online or not ○ However, system services exist § We should have something similar in Qt § WIP: Connection Monitoring ○ Proposal: § Remove it § Add requested features afterwards □ Which socket is a connection using □ Set preferred connection - We want to avoid temporary buffers, especially in TLS case - QSSLsocket need to change ○ Going through tcp socket is complicated ○ Lots of effort, might be too big for Qt 6 ○ Similar to QDTLS, which does not go through QUDPSocket - (Connection loss) ○ Problem not 100% clear ○ We have connection caching ○ Should not be exposed to user - Move WebSocket to QtNetwork? ○ Not sure why this is needed in network itself ○ Currently not actively maintained ○ Before moving to QtNetwork it needs to be significantly refactored - Removing QFTP ○ This is about QFTP backend in QNetworkAccessManager ○ There are still public users, but how many? ○ Proposal: Disable it in 6.0 and check for amount of complaints § If limited (as expected) remove in 6.2 completely - What about adding backends to QNetworkAccessManager? ○ Right now you can only exchange it ○ AP: Create research user story on JIRA ○ Help request - What about using libcurl as a backend? ○ Not only ftp, but everything? ○ It's not the best API, but provides a lot ○ We'd have to different underlying architectures, impossible to use libcurl with our own stuff ○ Libcurl also has its own secure transport implementation, etc… ○ Windows provides native API, what about that? § Mac probably as well - More and more projects need to do certificate management etc ○ KNX, OpcUA, CoAP, … ○ Can we find an abstraction? Potentially move that into a separate module and have Qt Network use it? ○ QTBUG-76499, QTBUG-76876 ○ It's a lot of work, but might be better than duplicating less work again and again - QUIC / HTTP3 ○ Rather wait for it to stabilize, but on the radar - QIODevice and zero copy ○ Needs to move to QtCS core session as no time left - How to test ○ Current testserver is probably not the best option ○ Use docker images ○ Windows is not ready for nested virtualization ○ However, might be worth considering run the network test containers on one machine and then have the Windows VMs connect to this one. ___ 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] QtCS2019 Notes: QtCore
On Thursday, 21 November 2019 19:48:03 CET Giuseppe D'Angelo via Development
wrote:
> Written here:
> > https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtCore
>
> Thanks,
Thanks Peppe
* What does Qt assume on locale on UNIX systems?
** What happens if you haven't set anything?
*** Thiago: assume it is C.UTF-8
*** Peppe: crash/warning
** What happens if you have set an encoding we would support (via QtTextCodecs
or whatever), but not UTF-8?
*** Warning and override with UTF-8
** Special case: C (that we would support anyhow), but not C.UTF-8?
*** Thiago: assume it is C.UTF-8
*** Warning? 7 bit is perfectly compatible
** What happens if you have set an encoding we do NOT support?
*** Andre: override the user; assume it is UTF-8
Peppe: at a minimum: every time we override, print a warning!
** What happens to child processes?
*** No -- there was a warning for the user
Implementation: https://codereview.qt-project.org/c/qt/qtbase/+/282359
Wordsmithing accepted, but please propose full sentences.
I tested like this:
$ bin/uic --version
uic 5.14.0
$ LC_ALL=C.UTF-8 bin/uic --version
uic 5.14.0
$ env -i LANG=en_US LC_CTYPE=C.UTF-8 bin/uic --version
uic 5.14.0
$ env -i LANG=uz_UZ@cyrillic bin/uic --version
uic 5.14.0
$ env -i bin/uic --version
Detected system locale encoding (ANSI_X3.4-1968, locale "C") is not UTF-8
Your environment is probably mis-configured. See locale(1) manual for
more information. Qt will continue as UTF-8 ("C.UTF-8").
uic 5.14.0
$ env -i LC_ALL=C bin/uic --version
Detected system locale encoding (ANSI_X3.4-1968, locale "C") is not UTF-8
Your environment is probably mis-configured. See locale(1) manual for
more information. Qt will continue as UTF-8 ("C.UTF-8").
uic 5.14.0
$ env -i LANG=de_DE bin/uic --version
Detected system locale encoding (ISO-8859-1, locale "de_DE") is not UTF-8
Your environment is probably mis-configured. See locale(1) manual for
more information. Qt will continue as UTF-8 ("de_DE.UTF-8").
uic 5.14.0
$ env -i LANG=sv_FI@euro bin/uic --version
Detected system locale encoding (ISO-8859-15, locale "sv_FI@euro") is not
UTF-8
Your environment is probably mis-configured. See locale(1) manual for
more information. Qt will continue as UTF-8 ("sv_FI.UTF-8").
uic 5.14.0
$ env -i LANG=foobar bin/uic --version
Detected system locale encoding (ANSI_X3.4-1968, locale "") is not UTF-8
Your environment is probably mis-configured. See locale(1) manual for
more information. Qt will continue as UTF-8 ("C.UTF-8").
uic 5.14.0
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from the Qt 6 Changes / Migration session
Hi, Il 22/11/19 11:01, Friedemann Kleint ha scritto: at https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration I think a clarification is in order: many of the things listed in those notes have also been discussed in other ad-hoc sessions (QtCore, QMetaType, etc.), and the resolutions in those sessions do not match what's listed in these notes. Most notably: * QList=QVector impact is yet to be evaluated in big codebases * QString/QStringView/QLatin1String/u"" has no resultion, or better, it was agreed that has YET to be discussed * QAny was proposed and rejected, instead the idea was to fix QVariant itself somehow * returning std::optional for toInt() is just plain *wrong* and thus won't be done that way; it's at a minimum an expected type and really something even more complex (à la std::from_chars); and anyhow "how to port" is still a question 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from the Qt 6 Changes / Migration session
On 11/22/19 11:01 AM, Friedemann Kleint wrote: https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration Maybe one aspect I would like to add: there is a lot of software, that has to be compilable with Qt 5 and Qt 6. Especially when your product is library you can't decide which version of Qt is going to be used in the application. It would be good if this does not end up in a total mess of ifdefs. My experience from the past is, that it takes years until the majority of the applications has upgraded to the next major Qt version - and probably only few applications will seriously try out Qt x.0 versions. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Maintainers, your action needed: Qt 5.14.0 Changes files
Jani, Could you please ensure that those change log reviews have proper reviewers added? Those reviewers should be the devs who we expect the change file to fill with content. -- Alex From: Development on behalf of Jani Heikkinen Sent: Tuesday, 19 November 2019 07:53 To: development@qt-project.org Subject: [Development] Maintainers, your action needed: Qt 5.14.0 Changes files Hi all, initial ones here: https://codereview.qt-project.org/q/message:%2522Add+changes+file+for+Qt+5.14.0%2522 Please do needed modification & get approval immediately; we need to get these in as soon as possible br, Jani ___ 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] RFC: QVariant changes in Qt6
Hi,
This is a follow-up on what was discussed in the (second part of the) QtCore
session in the QtCS.
Lars and others have been mentioning that they dislike implicit conversions
within QVariant. Creating a new class (QAny) has been suggested, that would be
like QVariant but without the conversions.
I am personally not in favor of this change because we are using QVariant all
over the place in our API and so we cannot really deprecate QVariant. It will
cause much confusion to user to have two similar classes. And the difference is
not big enough to force a new class.
So here is what I suggest we do in Qt6. None of this is implemented yet, it is
only proposed on this list for feedback.
1. operator==
In Qt6, QVariant::operator==() will no longer do any conversions.
If two QVariant does not have exactly the same, they will no longer be
considered equal.
Also, in Qt6, QMetatype will gain ability to register the operator==, and
therefore it will work for any type (and not only for builtin type as currently).
So right now,
QVariant(QByteArray("Hello")) == QVariant(QString("Hello"))
is true, but in Qt6 it will be false.
This is a behavior change, but I believe this is something we can afford to do.
I do not have data on how much code will break with this change, but i feel
most use of operator== are there for optimisations: i.e: setFoo(const
QVariant &foo) { if (m_foo == foo) return; ... }
Maybe we'll have more data once we actually implement the change and see if too
many things breaks.
2. operator< and other comparison operator
Deprecate in Qt 5.15, remove in Qt 6
It is not possible to implement it correctly with a total order.
I could not find direct use of the operator in the code indexed on
https://code.woboq.org/qt5 (only in QmlDesigner::operator< which is itself not
used)
Sorting on variant does not really make sense. Even code that does, like
QAbstractItemModelPrivate::isVariantLessThan does not use operator<.
Where this is used may be the use of QVariant as a key in a QMap. This is
problematic because the operator< does not implement a total order, so you can
have funny results.
I could not find instances of that in Qt or QtCreator, but Github search for
"QMapI'd still want to deprecate it. User could wrap QVariant in their own
MySortedVariant with their own operators that does what they need for their use
case.
3. conversions in QVariant::value
We would like to avoid having automatic conversion in QVariant::value.
So Qt6 would be
std::optional QVariant::value() const;
And we could deprecate the current one in Qt5.15 in favor of qvariant_cast
which is explicit.
This one is a bit more controversial maybe. Because there are thousands of call
to QVariant::value all over the place. But "value()" is the ideal name for the
non-converting variant.
A clazy script to replace QVariant::value with qvariant_cast will be in order.
4. All the implicit constructors for builtin types.
QVariant has many implicit constructors for all the builtin types.
I suggest to replace them all with a template QVariant(T&&)
constructor. (same as std::any.) So builtin types are no longer special.
5. All the method toXxx (where Xxx is a builtin type)
Leave them as-is?
However some of them are for types that may go outside of QtCore, these should
be deprecated in Qt 5.15 and removed in Qt6
6. QVariant::Type and QMetaType::Type enums
QVariant::Type is already marked as obsolete in the documentation, but not yet
marked as deprecated.
So we can remove it in Qt6, and we should try to mark it as deprecated in Qt
5.15. But that's hard because it is used all over the place.
QMetaType::Type will be marked as deprecated in Qt6, but i'm afraid we cannot
simply remove it.
In general, all the integer id API for QMetaType will be deprecated in Qt6,
one should use QMetaType by value. The integer id will stay in Qt6. This means
that there will still be a central registry of types but it would only be there
for the types for which we ask the id (and for the builtin types)
--
Olivier
Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate
On 11/22/19 7:21 AM, Kai Pastor, DG0YT wrote:
> Am 21.11.19 um 20:23 schrieb André Pönitz:
>> On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
>>> a more radical and much simpler approach would be switching to gettext
>> The most prominent difference is the (usually) per-class automatic
>> context
>> which I always found too clever to be sensible, and that's effectively
>> also the only reason to need a C++ parser.
>
> Indeed, while 'context' is a useful concept, the (implementation) class
> name often isn't the best 'context' from a more general point of view
> (features, human translators, screenshots). And if a class does not
> inherit from QObject, the context already needs to be declared explicitly.
>
> Given the Qt Creator example, would it be feasible to make explicit
> declaration of a file's context mandatory, at least for the existing
> ("fast") parser? If not mandatory, an explicit declaration could at
> least disable all automatic detection for the rest of the file, making
> it possible to use modern C++ without surprises.
>
> Maybe this could be complemented by a lconvert feature to rename a
> context in an existing ts-file, for those who want to move away from
> class names as contexts.
That's certainly a possibility. With an explicit context declaration
(that's easy to detect) on file level we can use an even simpler
parser/extractor that doesn't have to know much C++ at all.
On the topic of switching to gettext:
It would be cool to know where this was discussed before. My searches
yielded nothing.
It's tempting to switch to an established solution.
Of course we must make sure that gettext is properly supported on all
target platforms. It seems to be available via vcpkg on Windows at least.
There needs to be a migration path if we want to use gettext as the
recommended i18n solution for Qt users (and maybe deprecate the
lupdate/lrelease). We could provide a migration tool, based on lupdate's
current parser, that transforms tr("foo") calls to _("foo"). Of course,
that gets more complicated due to the mentioned context differences.
And Linguist should probably be able to edit .po files.
BR,
Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Hi,
> these are the notes on the QtQml session:
> Versioning
> --
>
> Once we get rid of unqualified lookups we don't need any QML versioning
> anymore. At least the minor version will become optional already in 5.15
> for well-behaved QML documents. In QML 3 it won't be allowed.
While I agree with this overall, there's still one caveat which I
haven't seen discussed yet:
Imagine I have the following code:
Item {
id: foo
property color prettyColor: "#f0f"
Rectangle {
color: foo.prettyColor
}
}
Right now "foo" refers to the Item. What if in a future update,
Rectangle gains a new property "foo". Unless you want to force everyone
to be explicit by using "this" (e.g. width: this.height) everywhere,
which would be annoying, I don't see how this can be made future-proof
without some form of versioning or some other magic solution?
Cheers
Kai Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from Qt Solutions session
at https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_Solutions -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from the Qt 6 Changes / Migration session
at https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTCS2019 Notes from the High DPI session
at https://wiki.qt.io/Qt_Contributors_Summit_2019_HighDpi -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
