Am 25.11.2019 um 15:39 schrieb André Somers:
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
> On 25 Nov 2019, at 22:18, Filippo Cucchetto
> wrote:
>
> 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 la
On 26 Nov 2019, at 12:35, Olivier Goffart
mailto:oliv...@woboq.com>> wrote:
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
On 27/11/2019 11:39, Milian Wolff wrote:
Personally, I hope the answer is that this will remain supported. The only
disadvantage is the runtime type introspection, which should/could be solved
via Ulf's idea of something like an inline interface/trait component. Such
that eventually we can do som
On Tue, Nov 26, 2019, at 8:56 AM, Ulf Hermann wrote:
> 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 {
> req
On Mittwoch, 27. November 2019 10:35:23 CET Giuseppe D'Angelo via Development
wrote:
> Il 27/11/19 09:52, Ulf Hermann ha scritto:
> > That depends on how we do the model/delegate matching mentioned above.
> > As stated above, I don't have a solution, yet. If you have an idea, let
> > us know. I ca
On Dienstag, 26. November 2019 20:32:20 CET Arno Rehn 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
Il 27/11/19 09:52, Ulf Hermann ha scritto:
That depends on how we do the model/delegate matching mentioned above.
As stated above, I don't have a solution, yet. If you have an idea, let
us know. I can imagine generating some C++ from such code that does the
model/delegate matching at run-time via
>> 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 somethi
> 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 mac
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 an
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?
>
>
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
> 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
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.
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).
>>
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 r
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
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'r
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
v
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
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
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 look
> 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 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
@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
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 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
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
>> 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
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
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
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
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 li
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
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_engi
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
Hi Ulf,
thanks for clarifying. You're absolutely right, no other language supports
importing different versions of dependencies but I think it is a great
feature of QML that helps a lot in maintaining the old code. Would be sad
to see it gone in QML 3.
Cheers
PS I'm forwarding this email to the
Hi,
these are the notes on the QtQml session:
Grouped properties
--
Grouped properties are incredibly buggy and basically unusable for
anything but font and anchors right now. The language would be better
off without the concept, allowing only the replacement of the full
objec
51 matches
Mail list logo
