Re: [Development] FW: QtCS19 Serialization session

[Arnaud Clère]

-Original Message-
From: Thiago Macieira 

> > value.meta(qmColumns,"key,value").bind(map.iterator())
>
> I really, REALLY do not like this line.

I was going to explain all meta(...) were never required, but well,
you have pretty well summarized your arguments so I will just stop
wasting our time.

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

[Development] Qt 5.15 schedule proposal

[Jani Heikkinen]

Hi!

Qt 5.14.0 is in its final steps and it is time to start thinking Qt 5.15 
release schedule.  I don't see any reason/evidence how we could cut the time so 
my proposal is based on previous releases:


Qt 5.15 initial schedule proposal:
- All new modules must be in qt5 latest a week before FF. That way we in the 
release team should have enough time to adjust packaging etc for new modules 
before alpha release (== Soft FF  )
- Qt 5.15 Feature Freeze 31st January 2020
- Qt 5.15 Alpha release immediately after FF. 
- Qt 5.15 Beta1 release 25th February
- Qt 5.15.0 RC 30th April 2020
- Qt 5.15.0 release 15th May 2020

Any comments or objections?

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

Re: [Development] QTCS2019 Notes from QtQml session

[Giuseppe D'Angelo via Development]

Il 21/11/19 09:17, Ulf Hermann ha scritto:

Typed Model Data


We brainstormed a bit about how a model could declare its items' data
type in QML, so that we could statically check model against delegate
types. We will need this when compiling QML 3 to C++. We didn't come up
with anything really great, though. This needs more work.


Just something specifically related to models and delegates: having a

  required property var model

on the delegate, then using model.foo (just like today), is supposed to 
be a fully supported measure throughout QML2/3 or just a 
deprecated-on-birth porting solution towards explicit required 
properties on the delegate?


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

[Arno Rehn]

On 26/11/2019 08:56, Ulf Hermann wrote:
>> We have some code that evaluates JS in custom QQmlContexts with certain
>> "magic" context properties set (sort of like the "index" or "modelData"
>> context properties in delegates like Repeater.delegate).
>> Will something similar still be possible?
> 
> You should rephrase that as required properties on actual objects. Then 
> the magic won't work anymore and you'll have to look up the properties 
> by ID of the object, but that is a good thing. It will improve 
> re-usability of your components.
Right, that would work in this case. Thanks!

Anyway, how would I idiomatically register a bunch of dynamically
created C++ objects with QML then? As an example, we're automatically
detecting hardware stuff and creating interface objects based on that.
These interface objects are then passed to QML which we use to implement
state machines.

Pseudo-code example:

  QObjectList objects = detectAndCreateObjects();
  QVariantMap qmlObjects;
  for (auto object : objects) {
  qmlObjects[object->objectName()] = object;
  }
  engine->rootContext()->setContextProperty("Objects", qmlObjects);

Now I see two (maybe more) "workarounds" for that:
1. Register every object as a singleton. That's bad design, because
these objects don't really match the singleton pattern.
2. Register a single accessor singleton instance which holds the
qmlObjects. That's a lot more to type, though:

  import QtQml.StateMachine 1.0 as DSM
  import Utils 0.1  // provides "ObjectProvider"

  DSM.State {
onEntered: ObjectProvider.objects.foobar.frizzle()
// In QML 2:
// onEntered: Objects.foobar.frizzle()
// or even just:
// onEntered: foobar.frizzle()
// if we leave out the QVariantMap above
  }

I realize that this makes things more "well defined". But I think it'll
make usage of QML as a domain-specific language (like for implementing
state machine logic) a little more cumbersome.

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
Am Klopferspitz 19a, 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] 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

Re: [Development] FW: QtCS19 Serialization session

[Thiago Macieira]

On Tuesday, 26 November 2019 06:50:28 PST Arnaud Clère wrote:
> value.meta(qmColumns,"key,value").bind(map.iterator())

I really, REALLY do not like this line.

-- 
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] FW: QtCS19 Serialization session

[Arnaud Clère]

Now, this is the discussion I was hoping for at QtCS :-)

> -Original Message-
> From: Thiago Macieira 
>
> > - it is frequent to have to save/load our types and then send/receive
> > them to some server/device using, say QSettings/QJsonDocument for the
> > first and JSON/CBOR for the latter
>
> How many do so interchangeably. I'm not asking about whether we should
> support different serialisations. I am asking how many types would benefit
> from a single, standardised mechanism for multiple backends?

The details of the serialization are usually far less important than
being able to
comply with the environment requirements :
- my company has developed a comprehensive XML toolset : whatever XML will do
(possibly with XSLT in the middle)
- my device need to exchange data : I want CBOR format but I am free to define
whatever payload suits my use case
- my desktop application has to load/save user data : whatever
QSettings flavor will do

> For example, a Rectangle in CBOR might be stored as (x1,y1,x2,y2) whereas the
> QSettings format might have been XxY+W+H, which means a generic solution
> will not work.

Truly, this kind of questions can become a standardization nightmare.
But as with all
standardization efforts, the value is not so much in the final
solution chosen than in providing
users with a common, well, "standard". Your example shows Qt evolved
in different directions wrt
serialization. Let us improve this in the future!

"@QPoint(10,20,100,150)" is a necessary facility to handle legacy but
a more explicit and principled
API and data format would be better.

Apart from a few basic types (int...) that should use the format
mandated by the targeted data format
or another standardized textual representation when there is none
(say, QUuid::toRfc4122 for JSON),
I argue that all data types should be "record/object/struct" with
meaningful property names.

Indeed, the QML types already look like a very nice and useful
de-facto standard for exchanging data
on top of JSON/CBOR :

https://doc.qt.io/qt-5/qmltypes.html
https://doc.qt.io/qt-5/qml-rect.html

According to this approach, no need to enter wasteful bikeshedding :

QRect::zap(...)  {
  return value.record("rect")
.item("x",x1)
.item("x",y1)
.item("width", x2-x1)
.item("height",y2-y1); // TODO use setHeight() if (value->mode()==Read)
}

> > There are not much alternatives
> > in how to serialize QList and the ones in CBOR are covered
> > (definite/indefinite). QPoint::zap or, say, QColor::zap may not fit
> > all use cases but the API allows to easily define another serialization.
>
> I do not agree. Please back up that statement with data: how many types would 
> benefit from a standardised serialisation?

What kind of data? I think all of the QML types above would benefit
from a standard way
to serialize to/from other data formats. Are you asking which ones
would work in read/write
using the fluent interface only?

> And why are you including item models in this, what do they have to do with 
> serialisation?

The proposed API handles serialization as simply iterating over
structured data with
some Reader/Writer. The proof-of-concept demonstrates having a
standard API for this
would make many use-cases become a simple one-liner like:

// Fill the table view with the CSV file content
QCsvReader().read(QItemModelWriter<>().value());

That is the kind of simplicity, or absence thereof, that makes people
move away from C++
to Python (cf list comprehensions).

> > hey, I used to understand assembly and now it looks strange to me!
>
> Ok, that's actually a good point: assembly is very different from Qt-style
> C++, but it's not usually mixed with C++. What you're proposing is a C++very,
> very different API style that matches nothing in Qt and is meant to be used 
> alongside Qt-style C++.
>
> There is no example of fluent-like API in Qt. The closest we'll see of it in
> C++ is the ranges API with operator|, which are meant to imitate a shell
> pipeline anyway.

C++ has evolved from inline assembly to ranges. I do not think Qt
should stop in the middle.
QDataStream streaming interface is a fluent interface hidden behind a
cryptic operator.
Yet, most people find it convenient and some are even happy to not have
to understand the trick of passing along the QDataStream&.

> As I said, I don't like it and I fear a very different API could be confusing.
> I understand what it's meant to do. I am saying I don't like that it does all 
> it does.

Ok, but then how can we make it easier to read some CBOR into C++ types?
Build a QCborValue in memory, and then iterate over it to copy the
data to our own C++ types?
That will always be possible but my API would require much less work,
be safer and far more efficient.

> It's also advising people to write inefficient code. For example, de-
> serialising a record requires repeated iterations and is either O(n log n) for
> sorted records (like JSON) or O(n²) for unsorted ones like CBOR. In
>   

Re: [Development] QtCS2019 Notes from "Branch Policy" discussion

[Volker Hilsheimer]

Hi,

On 21 Nov 2019, at 13:52, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:

On Thu, Nov 21, 2019 at 08:50:10AM +, Volker Hilsheimer wrote:
== Discussed and Agreed Proposal ==

We start with Qt 5.15/14/12 (ie 5.15 is “dev” in the Qt 5 series), and continue 
to merge 5.15 into dev until 5.15 has reached feature freeze.

this has NOT been agreed upon. what actually happened is that lars interrupted 
me, summarily dismissed my concerns (thereby implicitly rejecting the previous 
conclusion about mixing merges and cherry-picks), and didn't provide as much as 
a rationale for this other than a vague assertion that this would be somehow 
easier.


Since nobody contradicts your objection, I’m happy to correct the minutes from 
the discussion with something else, but I’d need a practical proposal to 
replace it with. Do I understand correctly that you’d rather go “all in”, i.e 
once we are ready, flip all branches to “cherry-pick only”?

The rationale for the above was (IIRC):

* Merging 5.15 into dev is status quo anyway
* 5.12 is cherry-pick already; 5.13 is frozen
* Switching 5.14 into cherry-picking mode is not a significant change to 
existing way of working; it’s just making the change earlier (or at all, when 
5.14 typically would just become frozen around the time 5.15.0 is released)

So, starting with the new process within the Qt 5.x family of branches gives us 
a phased approach with multiple, smaller, accumulating changes rather than the 
“big bang” that several heavyweights at Google would have an opinion about.


=== Tooling ===

* automation triggered by commit message footer

it was strongly suggested by alex that having the automation already in place 
should be a hard precondition for changing the process, and i agree.


I’ve written down the flow that we’d need to implement here:

https://bugreports.qt.io/browse/QTQAINFRA-3382

Let’s start with agreeing on the spec.


=== Exceptions ===

* Changes file updates are done in the relevant release branch; the files are 
then carried forward to dev, and cherry-picked down from there as usual

the second part actually makes no sense, because it makes tracking the original 
sha1 even harder. it's better to pick from a single point (at least logically, 
that is, what sha1 the pick source footer names; in reality, forward-picking 
picks might be easier due to avoiding repeated conflict resolution, but that 
has been explicitly rejected as a "front-end process" (by the same people!) 
because it slows down the integration process).


If I understood and remember the discussion, then the proposed flow would be:

* we make changes to e.g changes-5.12.7 in the 5.12 branch
* once 5.12.7 is released, release team copies the file into dev, and makes a 
separate commit
* that commit gets cherry-picked from dev down into 5.15 and 5.14 using the 
standard process

The rationale is that we have only a single such "forward-porting" commit for 
each release, and to the largest extend follow the standard process. The 
disadvantage is that the changes-5.12.7 file in dev will have a different 
history than the same file in 5.12.

If I understand your proposal, the process would be:

* changes files are updated directly in the release branch, e.g. 5.12 (assuming 
that 5.12.7 is only for the release team anyway)
* we cherry-pick each commit from there forward through 5.14, 5.15, dev

The advantage here is that we can track each commit, and have the same history 
for those files. The disadvantage is that it’s a bigger departure from standard 
process, with more room for error and overhead.

So I understand you correctly?


* In exceptional cases, and to unblock a release, changes might go first into a 
release branch and cherry-picked forward into dev

there are whole talks from heavyweights like google how that is a silly idea, 
but i suppose it can still work on the precondition that the tooling _reliably_ 
forward-picks everything applicable, even if both the owner and their reviewers 
failed to notice the omission.
and no, considering missing picks acceptable "because it will eventually get 
fixed anyway" is not a position to be taken seriously.


I do agree with you and those other heavyweights; we should focus on making the 
correct process work efficiently and reliably enough to not require “hotfix 
shortcuts”.

However, those same heavyweights agree that complex systems don’t become 
resilient by design, but by the ability of their human operators to deal with 
exceptional situations. See Sidney Dekker [1] or John Allspaw [2].

[1] 
http://sidneydekker.com/wp-content/uploads/2013/01/Huberal_2009_Learning-from-organizational-incidents-resilience-engineering-for-high-risk-process-environments.pdf
[2] https://www.infoq.com/news/2019/04/allspaw-resilience-engineering/


** another exception is fixes in stable branches that are not relevant for dev

yes, that should require an explicit tag, say "Pick-to: none" (the footer 
suggested in the discussion 

Re: [Development] QTCS2019 Notes from QtQml session

[Uwe Rathmann]

On 11/26/19 12:35 PM, Olivier Goffart wrote:


"QML Strict is as subset of QML which is more maintainable and
performs better"


Isn't it that way:

QML is for convenience but expensive. C++ is often less convenient but
with better performance and lower memory footprint. QML Strict is a
compromise - something in between.

Then people can make a conscious decision, what is the right choice for
their situation.

IMHO being honest about what is what makes more sense, than how it was
f.e. done with QC2. That was sold as something specific for embedded but
actually it was about replacing QML by C++ code to get around
performance issues.

My 2 cents,
Uwe





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

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Mårten Nordheim]

On 26.11.2019 14:16, Konstantin Tokarev wrote:
> 
> 
> 26.11.2019, 16:11, "Mårten Nordheim" :
>> On 26.11.2019 13:54, Konstantin Tokarev wrote:
>>>   What about an elephant in the room, i.e. HTTP/3? Will it be implemented 
>>> anytime soon?
>>
>> Given the size and requirements of QUIC (and http3) we plan to wait for
>> it to stabilize and get closer to release, then we can consider
>> 3rd-party libraries to implement an internal (at least for QUIC v1 IMO)
>> "QQuicSocket" of sorts (glorious name). Then HTTP/3 would be on-top of
>> that or through a library as well.
>> If we cannot find a suitable library we'll have to make one ourselves.
>> So no plans for an implementation "soon", it will depend on the outside
>> world. I would rather we be a little late to the game than have a flawed
>> API for the lifetime of Qt 6 :)
> 
> Does last sentence imply that HTTP/3 will not be supported in QNAM 
> transparently
> and will use entirely new public API?
> 

No, shouldn't be something entirely new (hopefully not) for QUIC 
v1/HTTP/3. But we'll likely add similar options to what HTTP/22 has 
(with allowed attributes and so on). So HTTP/3 we could likely add 
without committing ourselves to a potentially soon-to-be-broken API. I 
would still prefer it to be closer to leave the draft stage (and library 
support before putting in too much effort though).

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

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Konstantin Tokarev]

26.11.2019, 16:11, "Mårten Nordheim" :
> On 26.11.2019 13:54, Konstantin Tokarev wrote:
>>  What about an elephant in the room, i.e. HTTP/3? Will it be implemented 
>> anytime soon?
>
> Given the size and requirements of QUIC (and http3) we plan to wait for
> it to stabilize and get closer to release, then we can consider
> 3rd-party libraries to implement an internal (at least for QUIC v1 IMO)
> "QQuicSocket" of sorts (glorious name). Then HTTP/3 would be on-top of
> that or through a library as well.
> If we cannot find a suitable library we'll have to make one ourselves.
> So no plans for an implementation "soon", it will depend on the outside
> world. I would rather we be a little late to the game than have a flawed
> API for the lifetime of Qt 6 :)

Does last sentence imply that HTTP/3 will not be supported in QNAM transparently
and will use entirely new public API?

-- 
Regards,
Konstantin

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

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Mårten Nordheim]

On 26.11.2019 13:54, Konstantin Tokarev wrote:
> What about an elephant in the room, i.e. HTTP/3? Will it be implemented 
> anytime soon?
> 

Given the size and requirements of QUIC (and http3) we plan to wait for 
it to stabilize and get closer to release, then we can consider 
3rd-party libraries to implement an internal (at least for QUIC v1 IMO) 
"QQuicSocket" of sorts (glorious name). Then HTTP/3 would be on-top of 
that or through a library as well.
If we cannot find a suitable library we'll have to make one ourselves. 
So no plans for an implementation "soon", it will depend on the outside 
world. I would rather we be a little late to the game than have a flawed 
API for the lifetime of Qt 6 :)

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

Re: [Development] QtCS19 Notes: Qt 6 Network Overview

[Konstantin Tokarev]

What about an elephant in the room, i.e. HTTP/3? Will it be implemented anytime 
soon?

21.11.2019, 10:55, "Maurice Kalinowski" :
> 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

-- 
Regards,
Konstantin

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

[Development] Qt Design Studio 1.3.1 is released

[Thomas Hartmann]

Hi all,

We released Qt Design Studio 1.3.1 today, see 
https://www.qt.io/blog/qt-design-studio-1.3.1-released

Big thanks to everyone involved!

Best Regards,
Thomas Hartmann

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

Re: [Development] Nominating André Hartmann for maintainer for QCanBus API

[Denis Shienkov]

+1

BR,
Denis

вт, 26 нояб. 2019 г. в 13:35, Sze Howe Koh :

> On Tue, 26 Nov 2019 at 17:07, Samuel Gaist  wrote:
> >
> >
> >
> > > On 26 Nov 2019, at 09:36, Alex Blasche 
> wrote:
> > >
> > > Hi,
> > >
> > > The QCanbus API is part of the QtSerialBus module. Since its first
> release it has come a long way. In particular, André Hartmann & Denis
> Shienkov made big contributions over time. For that I am very grateful.
> Thank you.
> > >
> > > As the current maintainer of the QCanBus API I would like to hand the
> maintainer baton over to André.
> > >
> > > He has done a very good job of fixing the day-to-day issues popping up
> on a regular base. Unrelated to QtSerialBus, he contributed to Qt Creator
> and other parts in QtBase.
> > >
> > > --
> > > Alex
> > > ___
> > > Development mailing list
> > > Development@qt-project.org
> > > https://lists.qt-project.org/listinfo/development
> >
> > +1
> >
> > --
> > Samuel Gaist
> > Research And Development Engineer
> > Idiap Research Institute,
> > Centre du Parc,
> > CP 592,
> > CH-1920 Martigny
> > http://www.idiap.ch/
>
> +1
>
>
> Regards,
> Sze-Howe
> ___
> 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] HEADS-UP: Branching from '5.14' to '5.14.0' done

[Jani Heikkinen]

Hi all,

Branching from '5.14' '5.14.0' is done (actually already at the end of last 
week). Staging in '5.14.0' is now restricted to release team only.
So from now on only fixes for Qt 5.14.0 blockers in '5.14.0'; we are trying to 
get RC out during this week and so on we need to minimize new changes there.

br,
Jani

From: Development  on behalf of Jani 
Heikkinen 
Sent: Thursday, November 14, 2019 10:15 AM
To: development@qt-project.org
Subject: [Development] HEADS-UP: Branching from '5.14' to '5.14.0' started

Hi,

We have soft branched '5.14.0' from '5.14' now. So all new changes targeted to 
Qt 5.14.0 release must be done in '5.14.0' branch.

Final downmerge (and branching finalization) from '5.14' to '5.14.0' will 
happen Wed 20th November.

br,
Jani Heikkinen
Release Manager



___
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

[Ulf Hermann]

> Lookup by ID? You mean set the object name like you did in your example 
> in your talk at QtWS? I protested then, and I will protest now again. 
> Don't. Really: don't. If you are talking about re-usability and 
> maintainability of your code elsewhere, then advocating this practice is 
> really wrong. You need to layer your QML on top of an API provided by 
> C++, not poke into your QML from C++.

Maybe that example in the slides was not so great. However, consider:


// main.qml
Item {
required property string title
}

// somewhere.cpp
QQmlComponent component(, ":/main.qml");
QObject *obj = component.createWithInitialProperties(
QVariantMap { {"title", "Hello World"} });


This declares the property in QML and requires you to set it when 
instantiating the component. The object won't be created if you fail to 
set the property. We may improve on this in the future. QQmlComponent 
already has a separate setInitialProperties() function, and we might add 
another one to check if all required properties are set.

I had to introduce the replacements for context properties in some 
order, and, apparently, introducing required properties first would have 
been better. Sorry for the confusion.

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

Re: [Development] QTCS2019 Notes from QtQml session

[Olivier Goffart]

On 25.11.19 16:36, André Somers wrote:


On 25-11-19 15:53, Ulf Hermann wrote:

Yeah, that's going to make using QML in actual applications a whole lot
harder. For instance, sometimes access to some root node is needed even
from deep leaf files. Removing that capability is quite a drastic measure.

Yes, but the problems with this construct are the same as with generic
context properties: Your QML component requires some context that it
doesn't declare. Therefore your code is not reusable and brittle wrt
addition of properties in other places.

Mind that all those dynamic lookups will still live on in QML 2, and we
will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.


"It will still work in QML 2" is not a great one if you want people to port 
over to QML 3. And you will need to support something like this anyway.


So far, the feeling I'm getting is that you're quite rigorously axing things 
from QML 2 in QML 3 in order to clean up because it is "broken" in QML 2. But 
without careful consideration what should replace it, that will just lead to 
the same issues again or a less usable QML for real world applications.


I'm a bit concerned.


Maybe the marketing isn't quite right.
Perhaps it shouldn't be named "QML 3"  but "QML strict"
QML3 tell peolpe
"This is the new version, you should port your code, the old version is going 
to be deprecated at some point"
While maybe true, I understand people's frustration. And since you will need to 
maintain both QML2 and QML3 at the same time, it might be better to rename it 
to something like "QML Strict" which convey the meaning:

"QML Strict is as subset of QML which is more maintainable and performs better"

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

Re: [Development] QTCS2019 Notes from QtQml session

[Simon Hausmann]

On 26.11.19 11:48, André Somers wrote:
>
> On 26/11/2019 08:56, Ulf Hermann wrote:
>>> We have some code that evaluates JS in custom QQmlContexts with certain
>>> "magic" context properties set (sort of like the "index" or "modelData"
>>> context properties in delegates like Repeater.delegate).
>>> Will something similar still be possible?
>> You should rephrase that as required properties on actual objects. Then
>> the magic won't work anymore and you'll have to look up the properties
>> by ID of the object, but that is a good thing. It will improve
>> re-usability of your components.
> Lookup by ID? You mean set the object name like you did in your 
> example in your talk at QtWS? I protested then, and I will protest now 
> again. Don't. Really: don't. If you are talking about re-usability and 
> maintainability of your code elsewhere, then advocating this practice 
> is really wrong. You need to layer your QML on top of an API provided 
> by C++, not poke into your QML from C++.


We're drastically improving the ability to layer QML on top of an API 
provided by C++. It means that we need to know what that C++ API looks 
like when looking at the .qml file without running it, for example when 
linting. This is why we're moving to the model of declarative C++ type 
registration and extraction of the "moc visible" API (slots, properties, 
etc.) at build time. That way we can give you feedback that perhaps 
you've accidentally used the wrong name of a C++ backed property at 
build (or editing time), instead of through "returning undefined" at 
run-time when accessing it.


>>
>> We're also changing the way views and delegate work. If you want to use
>> the "index" in a Repeater's delegate you'll have to declare that in QML
>> 3, using a required property:
>>
>> Repeater {
>>   model: 10
>>
>>   Text {
>>   required property int index
>>   text: "item " + index
>>   }
>> }
>
> I really, really dislike this change. It looks even more like magic 
> than what we have today. By all means deprecate/get rid off looking up 
> without using `model.` in front of index, but what you write there 
> really looks like magic. It is totally unclear who is setting a 
> property (required or not) if you just declare it. This introduces 
> more magic instead of less, and would IMO lead to more knowledge 
> required in on the C++ side about the QML side of the application, 
> where I just argued above that that leads to bad practice.
>
You say that it's unclear who is setting a (required) property. The 
analogy that we've used is that required properties are like declaring 
function parameters - you expect the caller to provide them, but you 
don't really care where the caller provided them from. Think of the 
above text delegate like a factory function (except that the parameters 
are live bindings):

(pseudo code)

     function createDelegate(index: int) {

     return new Text("item " + index);

     }


That doesn't feel like magic to me.


Simon

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

Re: [Development] QTCS2019 Notes from QtQml session

[André Somers]

On 26/11/2019 08:56, Ulf Hermann wrote:

We have some code that evaluates JS in custom QQmlContexts with certain
"magic" context properties set (sort of like the "index" or "modelData"
context properties in delegates like Repeater.delegate).
Will something similar still be possible?

You should rephrase that as required properties on actual objects. Then
the magic won't work anymore and you'll have to look up the properties
by ID of the object, but that is a good thing. It will improve
re-usability of your components.
Lookup by ID? You mean set the object name like you did in your example 
in your talk at QtWS? I protested then, and I will protest now again. 
Don't. Really: don't. If you are talking about re-usability and 
maintainability of your code elsewhere, then advocating this practice is 
really wrong. You need to layer your QML on top of an API provided by 
C++, not poke into your QML from C++.


We're also changing the way views and delegate work. If you want to use
the "index" in a Repeater's delegate you'll have to declare that in QML
3, using a required property:

Repeater {
  model: 10

  Text {
  required property int index
  text: "item " + index
  }
}


I really, really dislike this change. It looks even more like magic than 
what we have today. By all means deprecate/get rid off looking up 
without using `model.` in front of index, but what you write there 
really looks like magic. It is totally unclear who is setting a property 
(required or not) if you just declare it. This introduces more magic 
instead of less, and would IMO lead to more knowledge required in on the 
C++ side about the QML side of the application, where I just argued 
above that that leads to bad practice.



André




___
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

[Simon Hausmann]

On 25.11.19 16:55, Robin Burchell wrote:
> On Mon, Nov 25, 2019, at 3:53 PM, Ulf Hermann wrote:
>> Yes, but the problems with this construct are the same as with generic
>> context properties: Your QML component requires some context that it
>> doesn't declare. Therefore your code is not reusable and brittle wrt
>> addition of properties in other places.
> Which is why I also provided a possible solution - by providing declaration 
> of that context.
>
> I'm not sure whether you just stopped reading once I started talking about 
> the problem, but I'd be interested to hear about whether or not something 
> like that approach was considered.


I think the approach that you described is semantically almost identical 
with required properties. Instantiation of such a component requires 
providing context and at the same time it's possible to keep 
dependencies within the boundaries of a component.

>
>> Mind that all those dynamic lookups will still live on in QML 2, and we
>> will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.
> It's good to hear that QML 2 won't disappear overnight, but let's not pretend 
> that this would be a sustainable, good situation to be in. One day, QML 2 
> will disappear. At least, given the lower version number, you would hope it 
> will disappear. But every piece of pain that makes porting harder will help 
> to ensure that it stays around longer.
>
> And even if there wasn't going to be pain in porting - there is going to be a 
> lot of residual friction in transitioning. All of the documentation, all of 
> the examples, all of the tribal knowledge will suddenly become irrelevant.
>
> And for what? Why?
>
>
> Yes, there are problems with some features. That doesn't necessarily mean 
> they are unsolvable problems (perhaps they are; without having a proper 
> discussion about it - how do we know?)
>
> By the sounds of it, QML2 to QML3 will not be an easy transition. I was 
> already a little worried when I saw changes removing versioning, and a WIP 
> change deprecating context properties back in April or so, but reading your 
> mail makes me very concerned for the future.
>
> For reference, QML1 to QML2 was a _relatively_ easy port for example, despite 
> a different JavaScript engine, a new item set, and a completely rewritten 
> graphical presentation. My personal opinion is that this was very good, 
> because it gave you a pretty big no-brainer: spend a small moderate amount of 
> effort to port and validate/test, and in return, you gain much better 
> performance.
>
> The situation for QML3 seems to be much less clear cut

Often we do transitions in Qt API to improve performance or perhaps 
interoperability. Take the discussion about the return type of size() 
for example, or whether QList should alias QVector or not.

I sincerely hope that this transition will be different - at least today 
it looks already different to me and we're well into it in 5.15. The 
objective is to improve the maintainability of the user's code. We have 
added significant functionality to the linter and there is more to come. 
We're in the process of always applying it at build time to our own 
code. The work there is the foundation for the future tooling around the 
entire language, from a new compilation to C++ as well as better IDE 
integration. The current IDE integration is at its very limits (with 
cool hacks like scanning the C++ code for qmlRegisterType calls). Most 
of it boils down to the ability to make sense out of what's in the QML 
file without running the entire program.

Dynamic scoping and context properties make it hard (sometimes 
impossible) to reason without running - I anticipate agreement on this :-)

The application of singletons as well as required properties in our own 
examples has significantly improved the readability of code - that gives 
me the confidence that we're on the right track. Those may not be the 
two solutions that solve everything - however I find the evidence 
compelling. And by applying this step by step today, we're not making 
our examples and documentation irrelevant, we're transitioning and 
learning from it.


Simon

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

Re: [Development] QTCS2019 Notes from QtQml session

[Simon Hausmann]

On 25.11.19 12:15, Robin Burchell wrote:
>> We could detect this in qmllint by just continuing the search for IDs
>> even if we've found a property.
> We could, but if I may gently suggest, I think I can count most of the people 
> who use qmllint on a regular, useful basis on one hand ;-).

You're soon going to run out of fingers ;-)


> (One possible improvement to this could be to not _just_ have it as a 
> separate tool: maybe debug builds should _also_ run qmllint - or at least a 
> subset of its checks - on the code that the engine is loading? Alternatively, 
> perhaps as an engine flag to at least allow it to be turned on once, and 
> happen for everyone on a team in a unified zero-effort way)

Yes, we're working on integrating the application of the linter into the 
build system, so that it is always run. The objective is to look at the 
qml code as early as possible in the development cycle. Right now it's a 
run-time, maaybe a little at compile time with CONFIG += 
qtquickcompiler. The linter is taking a much closer look at the qml file 
(beyond the code in binding expressions) and that's feedback to be given 
after pressing the shortcut for "Build". We'd like to take the same code 
and place it into a language server, so that the feedback can be given 
right after typing - before choosing the apply the build step.


>> Mind that adding a method to a base class in C++ will shadow unrelated
>> other classes and functions even if it's not virtual or overridden. Why
>> did we actually decide that we can live with this effect in C++ but not
>> in QML? - Maybe because in C++ it's more likely to result in a compile
>> error due to mismatched signatures?
> I think one of the biggest problems is that ID resolution crosses file 
> boundaries. This essentially means that the ids chosen can very easily become 
> part of the "API" of a component unless you are very vigilant to not allow 
> that to happen.


Yes, implicit ID resolution across file boundaries is something that 
needs replacing with an explicit _interface_ declaration. I think that 
we may agree on that goal?


> Essentially this means that identifiers - and a child redefining an 
> identifier that the parent happened to use - suffer from the same problem 
> that you point out class members can suffer from.
>
> This is a contrived example, but I have seen similar things to this cause 
> bugs in production.
>
> Picture a SettingsButton.qml with this sort of contents:
>  Button { MouseArea { onClicked: console.log("clicked"); } }
>
> Looks nice and innocent, right? But I notice that the MouseArea doesn't work 
> because it has no geometry. I want to refer to it elsewhere in this 
> component, too, so let's give it a name.
>
>  Button { MouseArea { id: someFoo; width: parent.width; onClicked: 
> console.log("clicked"); } }
>
> In sensible code, this would work just fine, and have no complications.
> Unfortunately, what you didn't know was that Button.qml is:
>
>  Rectangle {
>  width: someFoo.width
>  height: 10
>  }
>
> The use of someFoo here was previously referring to a parent id. Now, it 
> finds that id in the child instead, with a very different geometry to what 
> was expected - just the same as if this was a property on the root item.
>
> This is not an easy problem I think. For sure, you can't just take the "easy 
> way" out and warn about duplicate ids during lookup, because while 
> _sometimes_ this inheritance is decidedly wrong and not what you want, a lot 
> of the time, id scoping is "private" and just fundamentally how code is 
> written. In the C++ world, this would seem pretty silly:
>
>  class Base { private: int m_myImplementationDetail; }
>  class Base : Derived { private: int m_myImplementationDetail; } // 
> warning: duplicate variable "m_myImplementationDetail" found in class Base
>
> Yes, they do indeed have the same name, but that's also unambiguous and fine.
>
> If we do consider them to be part of the API *sometimes* though, perhaps the 
> right thing to do is to allow that to happen explicitly: specify what ids can 
> be "exported/imported" and issue a compile error if those expectations are 
> not met.
>
> One problem though is that this import/export boundary should be checked at 
> the file boundary, _not_ the component boundary, otherwise using things like 
> Loader become a lot more annoying.
>
> So perhaps it could look something like this:
>
> import MyModule ...
> expects Item myFoo; // we want something of type Item, identified as myFoo to 
> be passed in from a containing file somewhere
> provides MouseArea bar; // we provide this ID for children to find
>
> Item {
>  width: myFoo.width
>
>  MouseArea {
>  id: bar // is visible in scoped lookup (via 'provides' at the top)
>  }
> }
>
> I guess you might also be able to use this for context properties - which 
> suffer from many of the same unclear scoping issues rather than just outright 
> 

Re: [Development] QTCS2019 Notes from QtQml session

[André Somers]

On 26/11/2019 09:34, Chris Adams wrote:

On Mon, Nov 25, 2019 at 9:34 PM Ulf Hermann  wrote:

I think one of the biggest problems is that ID resolution crosses
file boundaries. This essentially means that the ids chosen can very
easily become part of the "API" of a component unless you are very
vigilant to not allow that to happen.

Well, yes, and there is an easy way to fix this: Deprecate id lookup
across file scope. id lookup is actually the same as context property
lookup right now. That's what you're seeing there. We cannot get rid of
IDs, obviously, but we can restrict their use to the file context and
not search the whole context hierarchy.

Could I suggest also changing the id syntax to clarify that id is not
an object attribute?

e.g.:

Button id: btn { }

or

Button is btn { }

or

Button as btn { }

are IMO better syntax than:

Button { id: btn }

as for the former they are clearer that the ids are attributes of the
component scope rather than attributes of the object per-se, which is
what is suggested by the latter.


I'd tend to agree with that one. Perhaps it could just be

Button btn { }

No "id:" "is" or "as" needed?

Still: huge change again going to affect lots of existing code...

André


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

Re: [Development] Nominating André Hartmann for maintainer for QCanBus API

[Sze Howe Koh]

On Tue, 26 Nov 2019 at 17:07, Samuel Gaist  wrote:
>
>
>
> > On 26 Nov 2019, at 09:36, Alex Blasche  wrote:
> >
> > Hi,
> >
> > The QCanbus API is part of the QtSerialBus module. Since its first release 
> > it has come a long way. In particular, André Hartmann & Denis Shienkov made 
> > big contributions over time. For that I am very grateful. Thank you.
> >
> > As the current maintainer of the QCanBus API I would like to hand the 
> > maintainer baton over to André.
> >
> > He has done a very good job of fixing the day-to-day issues popping up on a 
> > regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and 
> > other parts in QtBase.
> >
> > --
> > Alex
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> +1
>
> --
> Samuel Gaist
> Research And Development Engineer
> Idiap Research Institute,
> Centre du Parc,
> CP 592,
> CH-1920 Martigny
> http://www.idiap.ch/

+1


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

Re: [Development] Nominating André Hartmann for maintainer for QCanBus API

[Karsten Heimrich]

+1

--Karsten

-Original Message-
From: Development  On Behalf Of Andy Shaw
Sent: Dienstag, 26. November 2019 10:35 Uhr
To: Alex Blasche ; development@qt-project.org
Subject: Re: [Development] Nominating André Hartmann for maintainer for QCanBus 
API

+1

Andy

-Opprinnelig melding-
Fra: Development  på vegne av Alex Blasche 

Dato: tirsdag 26. november 2019 09:39
Til: "development@qt-project.org" 
Emne: [Development] Nominating André Hartmann for maintainer for QCanBus API

Hi,

The QCanbus API is part of the QtSerialBus module. Since its first release 
it has come a long way. In particular, André Hartmann & Denis Shienkov made big 
contributions over time. For that I am very grateful. Thank you.

As the current maintainer of the QCanBus API I would like to hand the 
maintainer baton over to André. 

He has done a very good job of fixing the day-to-day issues popping up on a 
regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and other 
parts in QtBase.

--
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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating André Hartmann for maintainer for QCanBus API

[Andy Shaw]

+1

Andy

-Opprinnelig melding-
Fra: Development  på vegne av Alex Blasche 

Dato: tirsdag 26. november 2019 09:39
Til: "development@qt-project.org" 
Emne: [Development] Nominating André Hartmann for maintainer for QCanBus API

Hi,

The QCanbus API is part of the QtSerialBus module. Since its first release 
it has come a long way. In particular, André Hartmann & Denis Shienkov made big 
contributions over time. For that I am very grateful. Thank you.

As the current maintainer of the QCanBus API I would like to hand the 
maintainer baton over to André. 

He has done a very good job of fixing the day-to-day issues popping up on a 
regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and other 
parts in QtBase.

--
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] Nominating André Hartmann for maintainer for QCanBus API

[Samuel Gaist]

> On 26 Nov 2019, at 09:36, Alex Blasche  wrote:
> 
> Hi,
> 
> The QCanbus API is part of the QtSerialBus module. Since its first release it 
> has come a long way. In particular, André Hartmann & Denis Shienkov made big 
> contributions over time. For that I am very grateful. Thank you.
> 
> As the current maintainer of the QCanBus API I would like to hand the 
> maintainer baton over to André. 
> 
> He has done a very good job of fixing the day-to-day issues popping up on a 
> regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and 
> other parts in QtBase.
> 
> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

+1

-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

Re: [Development] QTCS2019 Notes from QtQml session

[ekke]

thanks Elvis, Filippo, Ulf,

now I know what to do the next months to make my apps QML3 - ready ;-)

yes - then my code will be better re-usable and cleaner as now

will blog about all those refactorings

ciao

ekke

Am 26.11.19 um 09:20 schrieb Elvis Stansvik:
> Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
> :
>> @Ekke
>> I think you should redesign your qml the other way around. For your problem 
>> there're multiple solutions
>> 1) Use some sort of StackView.view attached property. This is *usually* 
>> implemented with a simple upward hierarchy lookup of the first instance of a 
>> StackView.
>> In this way you get the reference of the StackView from leaf nodes.
>> 2) Pass a StackView reference  to the Page at the point of instantiation
>> Page1 {
>>id: page1
>>view: stackView // used inside Page implementation
>> }
>> 3) JUST DO THE RIGHT THING. Your page qml should not have code that directly 
>> calls the the StackView (This couples the Page to know that there's a 
>> StackView).
>> Instead your page should just expose signals or items. The wiring between 
>> these signals and view is done outside.
>> For example instead of:
>>
>> // Page1,qml
>> Item {
>>   Button { onClicked: stackView.doSomething() }  // Reference StackView by 
>> id..magically...awful!!
>> }
>>
>> Do like this
>> // Page1.qml
>> Item {
>>   property alias loginButton: button
>>   Button { id: button }
>> }
>>
>> // Somewhere.qml
>>
>> Page1 {
>>loginButton.onClicked: stackview.doSomething() // Logic outside view
>> }
> I agree. An analog to this in Qt/C++ land would be doing something like
>
> auto foo = static_cast(parent());
> // Use foo
>
> in a child widget, which is certainly a code smell (making assumptions
> about the context).
>
> The changes suggested would hurt our code base a little, because I
> know we're guilty of this transgression in some places of our QML as
> well. But I think it's worth it and the changes needed would improve
> our code.
>
> Just my 2 cents.
>
> Elvis
>
>> This solution allows Page1 to be just a view (like an old .ui file).
>> In other words Page1 interface implies that there's a button or  a clicked 
>> signal but you're free to connect its
>> clicked signal to a StackView or SwipeView since wiring is done outside it.
>>
>> A even better solution is to delegate this to a FSM
>>
>> Page1 {
>>   loginButton.onClicked: fsm.login()
>> }
>>
>> And then use a state of the FSM for handling the current page of the 
>> StackView
>>
>> StackView {
>>   currentPageComponent: {
>>   if (fsm.loginState.active) {
>>return loginPageComponent
>>   } else if (fsm.connectedState.active) {
>>   return connectedState.Compononent
>>  }
>>   }
>> }
>>
>> Best regards,
>>
>> Filippo
>>
>>
>> Il giorno lun 25 nov 2019 alle ore 16:54 ekke  ha 
>> scritto:
>>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
> Yeah, that's going to make using QML in actual applications a whole lot
> harder. For instance, sometimes access to some root node is needed even
> from deep leaf files. Removing that capability is quite a drastic measure.
 Yes, but the problems with this construct are the same as with generic
 context properties: Your QML component requires some context that it
 doesn't declare. Therefore your code is not reusable and brittle wrt
 addition of properties in other places.
>>> h :(
>>>
>>> because of my own project rules my code is re-usable through all my projects
>>>
>>> from discussions here I learned to use SingletonInstance which can
>>> replace the properties I set in my root (main.qml)
>>>
>>> but there are many other situations where I thinkl this won't help
>>>
>>> per ex
>>>
>>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>>
>>> from main there are some StackViews (+ Pages) switchedby Drawer
>>>
>>> Page1 or Page2 can be used on top of different StackViews
>>>
>>> there are some properties and functions from StackView used by Pages or
>>> Popup. Can access them via id because all my StackViews have same id
>>>
>>> any idea how this should be refactored for QML 3 without loosing all the
>>> cool flexibility ?
>>>
 Mind that all those dynamic lookups will still live on in QML 2, and we
 will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.
>>> of course my goal is to go to QML 3
>>>
>>> ekke
>>>
 Ulf
 ___
 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
>>
>>
>> --
>> Filippo Cucchetto
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development

___
Development 

[Development] Nominating André Hartmann for maintainer for QCanBus API

[Alex Blasche]

Hi,

The QCanbus API is part of the QtSerialBus module. Since its first release it 
has come a long way. In particular, André Hartmann & Denis Shienkov made big 
contributions over time. For that I am very grateful. Thank you.

As the current maintainer of the QCanBus API I would like to hand the 
maintainer baton over to André. 

He has done a very good job of fixing the day-to-day issues popping up on a 
regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and other 
parts in QtBase.

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

Re: [Development] QTCS2019 Notes from QtQml session

[Chris Adams]

On Mon, Nov 25, 2019 at 9:34 PM Ulf Hermann  wrote:
>
> > I think one of the biggest problems is that ID resolution crosses
> > file boundaries. This essentially means that the ids chosen can very
> > easily become part of the "API" of a component unless you are very
> > vigilant to not allow that to happen.
>
> Well, yes, and there is an easy way to fix this: Deprecate id lookup
> across file scope. id lookup is actually the same as context property
> lookup right now. That's what you're seeing there. We cannot get rid of
> IDs, obviously, but we can restrict their use to the file context and
> not search the whole context hierarchy.

Could I suggest also changing the id syntax to clarify that id is not
an object attribute?

e.g.:

Button id: btn { }

or

Button is btn { }

or

Button as btn { }

are IMO better syntax than:

Button { id: btn }

as for the former they are clearer that the ids are attributes of the
component scope rather than attributes of the object per-se, which is
what is suggested by the latter.

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

Re: [Development] QTCS2019 Notes from QtQml session

[Elvis Stansvik]

Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
:
>
> @Ekke
> I think you should redesign your qml the other way around. For your problem 
> there're multiple solutions
> 1) Use some sort of StackView.view attached property. This is *usually* 
> implemented with a simple upward hierarchy lookup of the first instance of a 
> StackView.
> In this way you get the reference of the StackView from leaf nodes.
> 2) Pass a StackView reference  to the Page at the point of instantiation
> Page1 {
>id: page1
>view: stackView // used inside Page implementation
> }
> 3) JUST DO THE RIGHT THING. Your page qml should not have code that directly 
> calls the the StackView (This couples the Page to know that there's a 
> StackView).
> Instead your page should just expose signals or items. The wiring between 
> these signals and view is done outside.
> For example instead of:
>
> // Page1,qml
> Item {
>   Button { onClicked: stackView.doSomething() }  // Reference StackView by 
> id..magically...awful!!
> }
>
> Do like this
> // Page1.qml
> Item {
>   property alias loginButton: button
>   Button { id: button }
> }
>
> // Somewhere.qml
>
> Page1 {
>loginButton.onClicked: stackview.doSomething() // Logic outside view
> }

I agree. An analog to this in Qt/C++ land would be doing something like

auto foo = static_cast(parent());
// Use foo

in a child widget, which is certainly a code smell (making assumptions
about the context).

The changes suggested would hurt our code base a little, because I
know we're guilty of this transgression in some places of our QML as
well. But I think it's worth it and the changes needed would improve
our code.

Just my 2 cents.

Elvis

>
> This solution allows Page1 to be just a view (like an old .ui file).
> In other words Page1 interface implies that there's a button or  a clicked 
> signal but you're free to connect its
> clicked signal to a StackView or SwipeView since wiring is done outside it.
>
> A even better solution is to delegate this to a FSM
>
> Page1 {
>   loginButton.onClicked: fsm.login()
> }
>
> And then use a state of the FSM for handling the current page of the StackView
>
> StackView {
>   currentPageComponent: {
>   if (fsm.loginState.active) {
>return loginPageComponent
>   } else if (fsm.connectedState.active) {
>   return connectedState.Compononent
>  }
>   }
> }
>
> Best regards,
>
> Filippo
>
>
> Il giorno lun 25 nov 2019 alle ore 16:54 ekke  ha 
> scritto:
>>
>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
>> >> Yeah, that's going to make using QML in actual applications a whole lot
>> >> harder. For instance, sometimes access to some root node is needed even
>> >> from deep leaf files. Removing that capability is quite a drastic measure.
>> > Yes, but the problems with this construct are the same as with generic
>> > context properties: Your QML component requires some context that it
>> > doesn't declare. Therefore your code is not reusable and brittle wrt
>> > addition of properties in other places.
>>
>> h :(
>>
>> because of my own project rules my code is re-usable through all my projects
>>
>> from discussions here I learned to use SingletonInstance which can
>> replace the properties I set in my root (main.qml)
>>
>> but there are many other situations where I thinkl this won't help
>>
>> per ex
>>
>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>
>> from main there are some StackViews (+ Pages) switchedby Drawer
>>
>> Page1 or Page2 can be used on top of different StackViews
>>
>> there are some properties and functions from StackView used by Pages or
>> Popup. Can access them via id because all my StackViews have same id
>>
>> any idea how this should be refactored for QML 3 without loosing all the
>> cool flexibility ?
>>
>> >
>> > Mind that all those dynamic lookups will still live on in QML 2, and we
>> > will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.
>>
>> of course my goal is to go to QML 3
>>
>> ekke
>>
>> >
>> > Ulf
>> > ___
>> > 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
>
>
>
> --
> Filippo Cucchetto
> ___
> 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