Get the original string source in a QML file from an url property

[feldifux]

Hi,

is there a way to retrieve the string entered in a qml file for an url property?

Assume I have the following source:
@Image { source: "testImage.png" }@

How can I retrieve "testImage.png" from the source property, without the absolute file path to it?

When I call object.property("source").toUrl(), the file:// scheme is added. Something like this for example: @file:///C:/TestApp/qml/img/testImage.png@

However, I would like to let the user change the source property at runtime, and then store the new source as a string to a file. This file including the custom source should then be readable from another machine as well, which will have a different file path.

In the above case one would assume that the solution is simple, because you might just cut everything except the file name and ending. But what if the image source contains a relative path, e.g. "img/anotherImage.png" or "../../otherFolder/image.png" - in that case I would like to get exactly these strings and not the full path.

I can imagine a solution when I would get the path to the QML file where a QDeclarativeItem (in that case the Image), because then I could generate the string manually. But I'm not aware of any method to find out in which QML file source a QDeclarativeItem resides.

I would appreciate any hints on this topic..

Cheers,
Chris

[andre]

My approach would be to not use the source property of the Image element directly. Instead, you create a new property in your own item, that you make persistent and that you initialize to your testImage.png by default. Then, you bind the Image::source property to this custom property.

[feldifux]

Thanks Andre!

However, then all users would need to replace the Image element with a custom overwritten Image element that adds this string property - can you think of another way to achieve the same result without changing APIs or introducing new string properties for every url property I would like to store?

[andre]

Perhaps I misunderstand what you mean by a user. Are your users programmers using your API, or end-users manipulating a QML application?

[feldifux]

Users are programmers using our APIs, and since we use the normal Image element for non-animated images, it would be tedious for them to change the source property to any other non-familiar one.

However, the question is not specific to our APIs, but rather a general QUrl-related one I guess.

[tzander]

The QUrl follows the rfc standard. Which means it is required to have a prefix like file:// (or http:// or ftp://). This is called the 'scheme'.
Check the QUrl API docs for lots of info about the different parts and how to get the stuff out you want :)

[feldifux]

Hi Thomas,
I did check the QUrl APIs, but this is rather a QML- & QUrl-related issue. The QUrl API is good, but for the use-case as shown above (extract the string part the developer entered in the QML file) it does not provide a solution. That's why I asked the question here :)

Cheers,
Chris

[tzander]

Ok, I must misunderstand, if you remove the schema, isn't what you get what the user typed?

[feldifux]

Nope, as I have written above:

bq. In the above case one would assume that the solution is simple, because you might just cut everything except the file name and ending. But what if the image source contains a relative path, e.g. “img/anotherImage.png” or “../../otherFolder/image.png” – in that case I would like to get exactly these strings and not the full path.

[tzander]

Sorry for being slow, but as far as I know things like "../foo" do not get resolved, they show up in the url as such. Do you mean you see them resolved?

Maybe you mean you want to remove the prefix, the basepath. For that see the declaritive engine, it has a getter for that.

[feldifux]

Hi,
we fixed this issue by querying the baseUrl of the context for the object with @QDeclarativeEngine::contextForObject()@ (which returns the qml file where the QObject resides) and then resolving the path to it relative from there. The disadvantage is, that you need to provide the pointer to the root element in your qml file to a C++ function, but that is a valid tradeoff. Maybe that helps someone. Thanks for your hints!

Cheers,
Chris