> 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 Monday, 25 November 2019 13:59:28 PST Arnaud Clère wrote:
> Hi Thiago,
>
> Regarding the last part:
> - 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 s
-Original Message-
From: Thiago Macieira
>
> My point is that I can see the value in providing a single method whereby our
> and users' types
> can provide a descriptive format for their serialisation, regardless what the
> serialisation backend is.
> That way, a single method could be u
On 21/11/2019 09:17, Ulf Hermann wrote:
> Context properties
> --
>
> These are remarkably evil and actually unnecessary. You can readily
> replace them with singletons or object properties (possibly required
> ones) already in 5.15. We can deprecate context properties. See also
Having followed the evolution and first announcement of Qml/Quick QML3
seems like an admission of guilt.
I remember when a lot of people complained about the use of Javascript as a
scripting language and further
more on the lack of a public C++ API. Now it seems like some of the QML
problems are go
On Sunday, 24 November 2019 13:02:32 PST Olivier Goffart wrote:
> > OMG, are you really sure about these massive changes?
>
> Not 100% sure, no.
> What specific changes are you worried about?
> In this case, I believe the changes should lead to only small behavior
> changes which are in fact fixes
On Sunday, 24 November 2019 09:57:56 PST Olivier Goffart wrote:
> Adding a cast function does not sound like a bad idea? But should it be
> done in Qt5.15 or Qt6. And should it return T or optional (in case the
> conversion did not work) or have a bool*ok=nullptr parameter?
The problem with std:
On Monday, 25 November 2019 06:35:53 PST Giuseppe D'Angelo via Development
wrote:
> Il 24/11/19 18:57, Olivier Goffart ha scritto:
> > The issue is that there is lots of use of these (esp. the most common ones
> > like toString and toInt.) Removing all uses be a huge work for no obvious
> > reason
On Monday, 25 November 2019 11:23:55 PST Jason H wrote:
> If Qt removes QFTP, could Qt provide a "scp" implementation? Maybe
> regardless of QFTP, scp would still be a "Good Thing(tm)".
Very unlikely. I truly don't see anyone working on it. It might be rejected
even if it was supplied in a contr
@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 refer
> - 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
On Sun, Nov 24, 2019 at 09:48:46PM -0800, Thiago Macieira wrote:
> On Sunday, 24 November 2019 00:50:14 PST André Pönitz wrote:
> > Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
> > _is_ there in general for some of the proposed porting strategies, but not
> > for the
On 25/11/2019 12:35, Ulf Hermann wrote:
Add one of the "b" to QSomething and the user code silently stops working.
It's an unfortunate consequence of shadowing; this is considered bad
practice (e.g. ES.12). Would it help to have a warn-on-shadowing pragma?
Thanks,
--
Giuseppe D'Angelo | gius
On Mon, Nov 25, 2019, at 4:55 PM, Robin Burchell wrote:
> The situation for QML3 seems to be much less clear cut
(This got sent a bit too early (hotkey mixup). Pretend this was at the bottom
of my last mail.)
I can't really comment on all of this stuff individually, because I'd be
writing an e
On 11/25/19 4:55 PM, 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
>> reusa
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
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 wit
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 constr
> 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
On 25-11-19 12:31, 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 th
Il 24/11/19 18:57, Olivier Goffart ha scritto:
The issue is that there is lots of use of these (esp. the most common ones like
toString and toInt.) Removing all uses be a huge work for no obvious reasons.
(And i was told they are now recommended by clazy)
The reason was avoiding the template bl
> Il 25/11/19 10:25, Eike Ziller ha scritto:
>>> ?
>> Similar things can happen in C++ with method names.
>> C++ got the ‘override’ keyword to make these breakages detectable by
>> tooling.
>> It looks to me like the case id==propertyname would also be detectable
>> by tooling?
>
> What do you m
> 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: D
> On 25. Nov 2019, at 11:03, Giuseppe D'Angelo via Development
> wrote:
>
> Il 25/11/19 10:25, Eike Ziller ha scritto:
>>> ?
>> Similar things can happen in C++ with method names.
>> C++ got the ‘override’ keyword to make these breakages detectable by tooling.
>> It looks to me like the case i
On Mon, Nov 25, 2019, at 10:43 AM, Ulf Hermann wrote:
> Indeed we need to deal with this somehow. Maybe we do need to retain
> versioning on a module level. For example, the qmldir file could specify
> what versions of which other modules it expects. Or we define that it's
> not a problem ...
I
> -Original Message-
> From: Development On Behalf Of
> André Hartmann
> Sent: Saturday, 23 November 2019 2:02 PM
> To: Christian Ehrlicher ; development@qt-
> project.org
> Subject: Re: [Development] Notes from "Releasing" session in QtCon19
>
> Hi all,
>
> > The script creating the cha
Il 25/11/19 10:25, Eike Ziller ha scritto:
?
Similar things can happen in C++ with method names.
C++ got the ‘override’ keyword to make these breakages detectable by tooling.
It looks to me like the case id==propertyname would also be detectable by
tooling?
What do you mean? Can you make an e
> On 24. Nov 2019, at 18:57, Olivier Goffart wrote:
>
> On 24.11.19 12:36, Lars Knoll wrote:
>> Hi Olivier,
>> Thanks for looking through this and coming up with a proposal. I like the
>> direction.
>>> On 22 Nov 2019, at 14:32, Olivier Goffart wrote:
>>>
>>> Hi,
>>>
>>> This is a follow-up
>> 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
> On 22. Nov 2019, at 11:52, 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
Here are the notes from the session
https://wiki.qt.io/Qt_Contributors_Summit_2019_-_moc_and_QMetaObject
Summary:
We discuss if we should rewrite moc using libclang.
moc currently hasn't still fully be ported to support C++11 yet. Features such
as raw literals, trailing returns and other will
31 matches
Mail list logo
