Debugging QML?

DigitalArtifex

Why is QML so ambiguous with errors? Like if you accidentally assign the same property twice you just get a build failure with no indicators.

Same with other parsing errors. I either made an error or a random keystroke in my component and my only indication is that QML claims my property aliases don't exist.

Other than line by line and commenting out entire portions of code to isolate it ..how do I actually debug QML issues? Is there a tool I'm overlooking?

Edit: I'm using QtCreator 16.02 with 6.9.0

DigitalArtifex

For clarification: I am talking specifically about a situation where I have a component that must have an error because it's claiming properties and aliases don't exist when they do. Absolutely no information to indicate what I actually did to throw off the parsing.

There is no "Issues" output.
There is no erroneous compile output.

Just a red squiggle, and a crash at runtime.

DigitalArtifex

turns out MapRectangle was already a type and being new to QML, I didn't know this. And it worked up until I included QtPositioning/Location in my Main.qml to access the map type. Is there anyway to find these types of conflicts besides already knowing all the types in the library you're including?

ankou29666

you can check whether the type already exists by watching the list of all QML types in documentation.

You can resolve conflicts by

import MyModule as M
import QtModule as Q

M.CommonName {}
Q.CommonName {}

I'm unsure about the need of the as statements, but this works.

DigitalArtifex

@ankou29666 thank you for the tip on how to resolve the conflicts, that will be very useful.

The bit about using the documentation to check for conflicts isn't a viable solution for systems as large as Qt. I am a fan of RTFM but at a certain point it's no longer feasible. I'm supposed to learn all aspects of Qt, before I start coding Qt...in order to learn Qt?

That doesn't make any sense.

If there were at least a warning of the conflict (like all other modern languages do) the user would know what they have to read in the FM.

ekkescorner

@DigitalArtifex said in Debugging QML?:

Why is QML so ambiguous with errors? Like if you accidentally assign the same property twice you just get a build failure with no indicators.

you should get the warning on property twice immediately while typing:

probably your qmlls isn't configured ?

DigitalArtifex

@ekkescorner when declaring two properties like that it is highlighted. When assigning the same property twice, it does not. There is just a colorless error in compile output.

But honestly the biggest issue is silently ignoring naming conflicts. That alone cost me over a days worth of work for what every other language warns you about.

ekkescorner

@DigitalArtifex said in Debugging QML?:

When assigning the same property twice, it does not. There is just a colorless error in compile output.

you should create an issue at Qt Bugs

ekkescorner

@DigitalArtifex said in Debugging QML?:

But honestly the biggest issue is silently ignoring naming conflicts. That alone cost me over a days worth of work for what every other language warns you about.

when I'm creating QML Types - and it's not a very custom specific name - I look at AllQMLTypes to verify

J.Hilk

@DigitalArtifex said in Debugging QML?:

When assigning the same property twice, it does not. There is just a colorless error in compile output.

thats simply not true:

DigitalArtifex

@J.Hilk it may be a bug then but its not "simply not true". My first screenshot is from assigning a property twice, and someone in the discord was able to reproduce it. For me the only thing it says is 'ninja build subcommand failed".

What QtCreator version and OS are you on that its working? It would be helpful for the bug report

Edit: my apologies. I included that screenshot in discord but not the forum post. I will post a new one when I'm back to my computer

ekkescorner

I'm using macOS, Qt 6.9.1, QtC 16.0.2
qmlls settings:

semantic highlighting is checked because my QML types are organized in nested folders

DigitalArtifex

@ekkescorner thank you! For some reason this is all disabled by default on Linux. I now have all the warnings and errors I would expect, and a whole lot more

Is this something that has to be enabled and I overlooked in the documentation, or should it have been on? Some of the stuff it enables is bog standard for development.

And even more curious as to why as community champion is providing clearer and more concise support than the official moderation team who decided to take the "You're a liar" stance

ekkescorner

it's always a good idea to read documentation, per ex. from QML Tooling - QMLLS or from QtCreator
you ask, why it's not already enabled ? there are many devs out there not using QML and then it's better disabled

BTW: from my POV the moderator team does a great job

DigitalArtifex

@ekkescorner yes its a good idea to read the documentation (and I do), but we also have to play the new user role to make sure the flow of discovery of information is correct. I do not see where I would have discovered that information, without encountering an error that I had to seek help for.

In the Qt Quick article (that would be the entry point for many people starting QML) there is no mention of this page. It is only in the navigation, and burried under another article called Qt QML. Not only that, but on the Qt Quick page, there is a link to an article describing debugging (which makes no mention of the QML Tooling page) and a link to a "Qt Quick Tools And Utilities" page, which is completely different and makes no mention of QMLLS.